Queries mot mutations mot subscriptions i GraphQL?

Question

IT Interview Practice · Accepted Answer

De är de tre **operationstyperna**, var och en kopplad till en rot-typ i schemat:

- **Query** — läser data. Fält körs **parallellt** och får inte ha några sidoeffekter (som HTTP GET).
- **Mutation** — skriver data (create/update/delete). Fält på toppnivå körs **sekventiellt**, så ordningen är garanterad.
- **Subscription** — en långlivad ström: servern skickar ny data till klienten över en transport som WebSockets varje gång en händelse inträffar.

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

Mutations tar **argument** (ofta ett `input`-objekt) och bör **returnera de påverkade data** så att klienten kan uppdatera sig utan en andra förfrågan. Den sekventiella regeln spelar roll: två mutations i ett och samma dokument — `deposit` följt av `withdraw` — körs alltid i den ordningen, medan två query-fält kan lösas samtidigt.

## Varför det är viktigt

Intervjuare kontrollerar att du vet att **queries är parallella och fria från sidoeffekter medan mutations är sekventiella**, och att en subscription behöver en tillståndsbärande transport (WebSocket/SSE). Att returnera uppdaterade data från en mutation är den praktiska detaljen som skiljer dem som har levererat GraphQL i produktion från dem som bara har läst om det.

Varför det är viktigt

Relaterade frågor