Queries proti mutations proti subscriptions v GraphQL?

Question

IT Interview Practice · Accepted Answer

So trije **tipi operacij**, vsak preslikan v korenski tip v shemi:

- **Query** — bere podatke. Polja se izvajajo **vzporedno** in ne smejo imeti stranskih učinkov (kot HTTP GET).
- **Mutation** — piše podatke (create/update/delete). Polja najvišje ravni se izvajajo **zaporedno**, tako da je vrstni red zagotovljen.
- **Subscription** — dolgoživ tok: strežnik potisne nove podatke odjemalcu prek transporta, kot je WebSockets, kadarkoli se sproži dogodek.

```graphql
query GetPost {              # read
  post(id: "1") { title }
}

mutation AddComment {        # write; returns the created object so the client updates its cache
  addComment(postId: "1", text: "Nice!") {
    id
    text
  }
}

subscription OnComment {     # live: fires every time a comment is added
  commentAdded(postId: "1") {
    id
    text
  }
}
```

Mutacije sprejmejo **argumente** (pogosto objekt `input`) in naj **vrnejo prizadete podatke**, da lahko odjemalec osveži stanje brez druge zahteve. Zaporedno pravilo je pomembno: dve mutaciji v enem dokumentu — `deposit`, nato `withdraw` — se vedno izvedeta v tem vrstnem redu, medtem ko se dve polji poizvedbe lahko razrešita sočasno.

## Zakaj je to pomembno

Izpraševalci preverijo, ali veš, da so **poizvedbe vzporedne in brez stranskih učinkov, medtem ko so mutacije zaporedne**, in da subscription potrebuje transport s stanjem (WebSocket/SSE). Vračanje posodobljenih podatkov iz mutacije je praktična podrobnost, ki loči tiste, ki so GraphQL dejansko dostavili, od tistih, ki so o njem le brali.

Zakaj je to pomembno

Povezana vprašanja