A dor que arde: quando a escolha da API vira dívida técnica
O problema não é REST. O problema não é GraphQL. O problema é escolher um dos dois porque alguém disse que ‘está na moda’. Aí nascem APIs obesas, sobrecarregadas de endpoints ou schemas GraphQL que viram uma hidrante de complexidade.
Dor real: quando a API vira gargalo porque a arquitetura ignorou o contexto de negócio.
No Reddit, a discussão .NET mostra isso claramente: novos projetos abraçam GraphQL achando que escalabilidade mágica vem no pacote. Spoiler: não vem.
Como resolver sem drama: critérios pragmáticos para decidir
Aqui vai a bússola simples para não tropeçar:
- REST para operações claras, recursos bem definidos, e equipes que querem previsibilidade.
- GraphQL quando a complexidade de consumo explode (front mobile + web + parceiros + dashboards).
- TDD como força-guia: o contrato nasce testável antes mesmo da implementação.
Regra de ouro: sua API deve nascer testável antes de nascer bonita.
Implementação de Senior: contratos reais, nada de servidor vazio
A seguir, um exemplo pragmático com REST + OpenAPI e GraphQL usando HotChocolate no .NET. O foco é mostrar como TDD guia esse contrato.
REST (OpenAPI) – contrato testável antes da implementação
openapi: 3.0.1
info:
title: Produtos API
version: 1.0.0
paths:
/produtos/{id}:
get:
summary: Obtém detalhes de um produto
parameters:
- in: path
name: id
required: true
schema:
type: string
responses:
200:
description: Sucesso
content:
application/json:
schema:
$ref: '#/components/schemas/Produto'
components:
schemas:
Produto:
type: object
properties:
id:
type: string
nome:
type: string
preco:
type: numberTestes podem consumir esse contrato antes do código existir, garantindo comportamento desde o primeiro commit.
GraphQL (HotChocolate) – schema explícito e testável
public class ProdutoType : ObjectType<Produto>
{
protected override void Configure(IObjectTypeDescriptor<Produto> descriptor)
{
descriptor.Field(p => p.Id).Type<NonNullType<IdType>>();
descriptor.Field(p => p.Nome).Type<NonNullType<StringType>>();
descriptor.Field(p => p.Preco).Type<FloatType>();
}
}
public class Query
{
public Produto GetProduto(string id, [Service] IProdutoService svc) =>
svc.Buscar(id);
}TDD aqui também brilha: testes de query resolvem o comportamento antes da implementação final.
O custo escondido das escolhas: onde REST e GraphQL cobram a conta
REST cobra taxa de manutenção quando o produto cresce demais. Endpoints se multiplicam. A documentação exige disciplina.
GraphQL cobra taxa de complexidade. A camada de resolvers vira uma pequena orquestra. Sem governança, vira caos.
Ambos cobram juros de over-engineering. Escolher sem contexto de negócio é pedir para pagar essa fatura.
Direto das Trincheiras
- Se o front pede sempre “só mais um campo”, GraphQL geralmente paga melhor.
- Se sua equipe não tem maturidade para governança de schema, REST salva seu sprint.
- TDD reduz o impacto de qualquer escolha — contrato é contrato, independente do hype.
Fontes utilizadas
Pergunta honesta para a comunidade .NET: por que novos …, Explorar Astera Website | Astera Software, Untitled
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 descascamos outros hypes da nossa área.
Vlw e até a próxima! 😉
