Quando o ‘one endpoint to rule them all’ vira armadilha
GraphQL promete liberdade: um único endpoint, queries flexíveis, payload sob demanda. No monolito, essa liberdade funciona. Em microservices, ela vira um convite ao caos.
O problema real: o front quer simplicidade, mas o backend paga a conta.
Quando cada query vira uma orquestração entre múltiplos serviços, o gateway GraphQL vira um mini-monólito disfarçado. A dor explode quando uma query aparentemente inocente dispara 12 chamadas internas. E claro: quando algo quebra, ninguém sabe onde começa a culpa — no gateway, no schema, no resolver ou no microservice downstream.
Como reduzir o estrago com uma arquitetura pragmática
O caminho maduro não é abandonar GraphQL — é usá-lo com consciência. Em microservices, o ganho está em tratá-lo como uma API de composição, não como um hub mágico que resolve tudo.
A regra é simples: schema fino, lógica fora.
Isso significa:
- Resolvers que delegam, não pensam.
- Orquestração movida para serviços especializados.
- GraphQL como camada de agregação, não como motor de negócio.
Implementação sênior: Gateway GraphQL com federation e resolvers enxutos
Abaixo um exemplo realista usando Apollo Federation — foco na composição, não na magia.
# products-service/schema.graphql
extend type Query {
product(id: ID!): Product
}
type Product @key(fields: "id") {
id: ID!
name: String!
price: Float!
}// products-service/resolvers.js
module.exports = {
Query: {
product: (_, { id }, { dataSources }) =>
dataSources.productsAPI.getProductById(id)
},
Product: {
__resolveReference(product, { dataSources }) {
return dataSources.productsAPI.getProductById(product.id);
}
}
};// gateway/index.js
import { ApolloServer } from '@apollo/server';
import { ApolloGateway } from '@apollo/gateway';
const gateway = new ApolloGateway({
serviceList: [
{ name: 'products', url: 'http://products-service/graphql' },
{ name: 'users', url: 'http://users-service/graphql' }
]
});
const server = new ApolloServer({ gateway });
server.listen(4000);Nada de regra de negócio no resolver, nada de transformação complexa de dados. O gateway apenas compõe o que os serviços realmente sabem fazer. Simples, claro, sustentável.
O preço de cada escolha: nem GraphQL é bala de prata, nem REST é santo
Usar GraphQL em microservices custa:
- Gateway hipertrofiado se a equipe não tiver disciplina.
- Debugging mais difícil quando uma query dispara cascatas internas.
- Observabilidade mais cara por causa do tracing distribuído.
Mas evitar GraphQL também custa:
- REST vira colcha de retalhos de endpoints altamente acoplados ao front.
- Over-fetching e under-fetching voltam com força.
- Mais payload, mais tráfego, mais latência.
O ponto é simples: não escolha GraphQL por modinha. Escolha por contexto de negócio.
Direto das Trincheiras
- Evite resolver joins no gateway. Se dois serviços vivem se relacionando, eles provavelmente fazem parte do mesmo bounded context.
- Traceamento é obrigatório. Jaeger e OpenTelemetry salvam sua sanidade quando o caos começa.
- Monitore resolvers lentos. Esses são os responsáveis por 90% do sofrimento antes do deploy.
Fontes Relacionadas
Rest, GraphQL ou gRPC? – guireisbr.dev,GraphQL para iniciantes – Medium
Obrigado por acompanhar essa reflexão até o fim!
Espero que esses pontos ajudem você a tomar decisões mais lúcidas no seu próximo projeto. Não deixe de conferir outros artigos aqui no blog, onde descasquemos outros ‘hypes’ da nossa área.
Valeu e até a próxima! 😉
