Anotei essa no caderno depois de errar numa entrevista de verdade. Hoje ela vive no meu baralho de GraphQL. Abaixo, a resposta como eu daria agora.
REST: many endpoints, the SERVER decides the response shape.
GraphQL: one endpoint, the CLIENT decides the shape.
GraphQL solves REST's two classic pains:
Over-fetching — REST returns the whole object when you needed 2 fields.
Under-fetching — one screen needs 3 REST calls (user → orders → products); in GraphQL it's ONE query fetching the nested graph.
The trade-offs (say them — this is what separates you from the hype):
- Caching is harder: everything is a POST to one URL, so HTTP/CDN caching doesn't work out of the box (REST GETs cache for free).
- One unbounded query can be very expensive → you need depth limits, complexity limits, timeouts.
- More moving parts: schema, resolvers, tooling. For simple CRUD, REST is less work.
- File uploads and webhooks: simpler in REST.
When to CHOOSE GraphQL: many clients/screens with different data needs (mobile vs web), highly relational data, aggregating multiple backends behind one API. When to stay REST: simple CRUD, public APIs, heavy caching needs.
Ler é fácil. Falar isso em inglês, sob pressão, com alguém avaliando, é outra história. No VagaGringa esse tópico vira flashcard com repetição espaçada, cai em quiz e entra no simulado.
Treinar este tópico no app