Query vs. mutation vs. subscription GraphQL:ssä?

Question

IT Interview Practice · Accepted Answer

Ne ovat kolme **operaatiotyyppiä**, joista kukin on kytketty schemassa olevaan root-tyyppiin:

- **Query** — lukee dataa. Kentät ajautuvat **rinnakkain** eikä niillä saa olla sivuvaikutuksia (kuten HTTP GET).
- **Mutation** — kirjoittaa dataa (create/update/delete). Ylimmän tason kentät ajautuvat **peräkkäin**, joten järjestys on taattu.
- **Subscription** — pitkäikäinen stream: palvelin työntää uutta dataa clientille jonkin transportin, kuten WebSocketsin, kautta aina kun tapahtuma laukeaa.

```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
  }
}
```

Mutationit ottavat **argumentteja** (usein `input`-objektin) ja niiden tulisi **palauttaa muutettu data**, jotta client voi päivittyä ilman toista pyyntöä. Peräkkäisyyssääntö on tärkeä: kaksi mutationia yhdessä dokumentissa — `deposit` ja sitten `withdraw` — ajautuvat aina tässä järjestyksessä, kun taas kaksi query-kenttää saattavat ratketa samanaikaisesti.

## Miksi se on tärkeää

Haastattelijat tarkistavat, tiedätkö että **queryt ovat rinnakkaisia ja sivuvaikutuksettomia, kun taas mutationit ovat peräkkäisiä**, ja että subscription tarvitsee tilallisen transportin (WebSocket/SSE). Muutetun datan palauttaminen mutationista on se käytännön yksityiskohta, joka erottaa GraphQL:ää tuotannossa ajaneet niistä, jotka ovat vain lukeneet siitä.

Miksi se on tärkeää

Aiheeseen liittyvät kysymykset