Queries vs. mutations vs. subscriptions no GraphQL?

Question

IT Interview Practice · Accepted Answer

São os três **tipos de operação**, cada um mapeado para um root type no schema:

- **Query** — lê dados. Os campos rodam **em paralelo** e não devem ter efeitos colaterais (como o HTTP GET).
- **Mutation** — escreve dados (create/update/delete). Os campos de topo rodam **sequencialmente**, então a ordem é garantida.
- **Subscription** — um fluxo de longa duração: o servidor envia novos dados ao cliente por um transporte como WebSockets sempre que um evento dispara.

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

As mutations recebem **argumentos** (frequentemente um objeto `input`) e devem **retornar os dados afetados** para que o cliente possa atualizar sem uma segunda requisição. A regra sequencial importa: duas mutations em um mesmo documento — `deposit` e depois `withdraw` — sempre rodam nessa ordem, enquanto dois campos de query podem resolver de forma concorrente.

## Por que isso importa

Os entrevistadores verificam se você sabe que **queries são paralelas e sem efeitos colaterais, enquanto mutations são sequenciais**, e que uma subscription precisa de um transporte com estado (WebSocket/SSE). Retornar os dados atualizados de uma mutation é o detalhe prático que separa quem já colocou GraphQL em produção de quem apenas leu sobre ele.

Por que isso importa

Perguntas relacionadas