O que GraphQL realmente é
GraphQL é três coisas: (1) uma query language, (2) um sistema de tipos, (3) um runtime que resolve a query contra o seu backend. Não é um banco, não é transport (roda sobre HTTP, WebSocket ou qualquer coisa). É um contrato entre cliente e servidor onde o cliente declara o shape dos dados que quer.
# Query: cliente pede só o que precisa
query PerfilUsuario($id: ID!) {
user(id: $id) {
id
name
avatar(size: SMALL)
posts(last: 5) {
edges {
node { id title publishedAt }
}
}
}
}Over-fetching e under-fetching
Over-fetching: REST devolve 40 campos, você usa 3. Mobile paga em bytes e bateria. Under-fetching: para montar a tela você chama /user, depois /user/id/posts, depois /post/id/comments — 3 round-trips sequenciais. GraphQL colapsa em uma chamada tipada.
Regra prática: se a mesma API serve 3+ clientes (mobile iOS, mobile Android, web, widget, watch) com necessidades diferentes, GraphQL paga o overhead. Se serve 1 cliente CRUD, REST + OpenAPI é mais barato.
Quando GraphQL vence
Times com múltiplos clientes heterogêneos (Meta, GitHub, Shopify Storefront). Produtos com UI rica que muda shape por tela. BFFs que agregam microsserviços para clientes. Exploração rápida do dado (introspection + GraphiQL destroi Postman).
Quando GraphQL perde
CRUD público com cache pesado em CDN. Upload binário. Streaming grande (use HTTP range). APIs internas simples com 1 consumidor. Teams sem cultura de schema review (schema vira lixão em 6 meses).
Não adote GraphQL porque é moda. Adote porque um problema concreto (over/under-fetching real em múltiplos clientes) está doendo. Caso contrário o custo operacional (N+1, cache, auth, DoS) come todo o ganho.