Queries kontra mutations kontra subscriptions i GraphQL?

Question

IT Interview Practice · Accepted Answer

De er de tre **operasjonstypene**, hver knyttet til en rot-type i schemaet:

- **Query** — leser data. Felt kjører **parallelt** og må være uten sideeffekter (som HTTP GET).
- **Mutation** — skriver data (opprett/oppdater/slett). Felt på toppnivå kjører **sekvensielt**, så rekkefølgen er garantert.
- **Subscription** — en langlivet strøm: serveren dytter nye data til klienten over en transport som WebSockets hver gang en hendelse utløses.

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

mutation AddComment {        # skriv; returnerer det opprettede objektet så klienten oppdaterer cachen sin
  addComment(postId: "1", text: "Nice!") {
    id
    text
  }
}

subscription OnComment {     # sanntid: utløses hver gang en kommentar legges til
  commentAdded(postId: "1") {
    id
    text
  }
}
```

Mutations tar **argumenter** (ofte et `input`-objekt) og bør **returnere de påvirkede dataene** så klienten kan oppdatere uten en ny forespørsel. Sekvensregelen er viktig: to mutations i ett dokument — `deposit` deretter `withdraw` — kjører alltid i den rekkefølgen, mens to query-felt kan resolves samtidig.

## Hvorfor det er viktig

Intervjuere sjekker at du vet at **queries er parallelle og uten sideeffekter, mens mutations er sekvensielle**, og at en subscription trenger en tilstandsfull transport (WebSocket/SSE). Å returnere oppdaterte data fra en mutation er den praktiske detaljen som skiller de som har levert GraphQL i produksjon fra de som bare har lest om det.

Hvorfor det er viktig

Relaterte spørsmål