REST vs GraphQL vs tRPC: guia de arquitetura

A escolha do protocolo de comunicação de uma API não é um detalhe técnico — é uma decisão arquitetural que vai moldar como seu time trabalha pelos próximos anos. REST, GraphQL e tRPC representam filosofias diferentes de como clientes e servidores devem conversar. Escolher errado significa refatorações custosas, inconsistências de contrato entre equipes e um backlog cheio de "migrar endpoints legados".

Este guia traz um comparativo honesto das três abordagens: quando cada uma brilha, onde cada uma falha e como tomar a decisão certa para o seu projeto.

REST: O Padrão que Funciona para 90% dos Casos

REST (Representational State Transfer) é o protocolo dominante na indústria por boas razões: é simples de entender, tem tooling maduro em qualquer linguagem e qualquer desenvolvedor contratado já conhece.

O modelo mental do REST é elegante: recursos são substantivos, verbos HTTP representam ações. GET /users/123 busca um usuário. POST /orders cria um pedido. DELETE /sessions/abc faz logout. Essa simplicidade torna APIs REST legíveis mesmo sem documentação.

Onde REST se sai bem:

• APIs públicas consumidas por parceiros externos que você não controla
• Sistemas com cache agressivo — GET requests são cacheable nativamente via HTTP
• Projetos com times pequenos onde a overhead de GraphQL/tRPC não compensa
• Integrações com ERPs, bancos e sistemas legados que já expõem REST
• Microsserviços que precisam ser acessíveis por múltiplas linguagens

Onde REST gera fricção:

• Mobile apps que precisam de dados muito específicos (overfetching/underfetching)
• Dashboards com visualizações complexas que agregam dezenas de entidades
• Desenvolvimento paralelo onde frontend bloqueia esperando novos endpoints

O problema clássico do REST é o "N+1 de endpoints": para renderizar uma tela de pedido, você faz GET /order/123, depois GET /user/456, depois GET /product/789 para cada item. Isso resulta em múltiplos round-trips de rede e código de orquestração no frontend que deveria ser responsabilidade do backend.

Se você está construindo uma API pública ou integrando com sistemas legados, nosso guia sobre quando usar um API gateway pode ajudar a decidir se uma camada intermediária faz sentido no seu caso.

GraphQL: Quando o Cliente Precisa Controlar os Dados

GraphQL surgiu no Facebook em 2012 para resolver exatamente esse problema: times de mobile que precisavam de dados muito específicos, em formatos muito diferentes, sem sobrecarregar uma API monolítica.

A proposta é inverter o controle: em vez do backend definir o shape dos dados, o cliente declara exatamente o que precisa.

query GetOrderDetails($id: ID!) {
  order(id: $id) {
    id
    status
    total
    items {
      quantity
      product {
        name
        price
        imageUrl
      }
    }
    customer {
      name
      email
    }
  }
}

Em uma única requisição, você busca o pedido, os itens, os produtos e o cliente. Zero round-trips extras. Zero campos desnecessários na resposta.

Onde GraphQL é a escolha certa:

• Apps com múltiplos clientes (web, iOS, Android) com necessidades de dados diferentes
• Produtos com dados altamente relacionais onde o cliente define o grafo de navegação
• Times grandes onde frontend e backend trabalham de forma desacoplada
• Plataformas que expõem API para terceiros construírem aplicações (GitHub, Shopify, Twitter usam GraphQL)

Custos reais do GraphQL:

• Curva de aprendizado significativa para times acostumados com REST
• Caching HTTP nativo não funciona — você precisa implementar caching na camada de aplicação (Apollo Client, urql)
• N+1 queries no banco de dados se você não implementar DataLoader
• Instrospection exposta pode vazar schema em produção se não for desabilitada

tRPC: Type-safety End-to-End sem Overhead

tRPC é a abordagem mais nova e a mais específica de contexto. Funciona exclusivamente em projetos TypeScript onde frontend e backend compartilham o mesmo repositório (monorepo) ou são servidos pela mesma base de código, como Next.js.

A proposta é radical: eliminar completamente a camada de serialização/deserialização e contratos de API. Você chama funções do servidor como se fossem funções locais, com type-safety completa.

// No servidor (app/api/trpc/[trpc]/route.ts — Next.js 15 App Router)
export const appRouter = router({
  getOrder: publicProcedure
    .input(z.object({ id: z.string() }))
    .query(async ({ input }) => {
      return db.order.findUnique({ where: { id: input.id } });
    }),
});

// No cliente — totalmente type-safe, sem código manual
const { data } = trpc.getOrder.useQuery({ id: "123" });
// data é tipado automaticamente como o retorno da função do servidor

Se você mudar o retorno da procedure no servidor, o TypeScript vai gritar em todos os lugares do frontend que consomem aquela procedure. Zero contratos desatualizados. Zero runtime errors por schema mismatch.

Onde tRPC é imbatível:

• Next.js 15 full-stack (App Router ou Pages Router)
• Startups e produtos onde velocidade de iteração é crítica
• Times pequenos que querem DX máxima sem overhead de configuração
• Projetos internos onde você controla 100% dos consumidores da API

Limitações importantes:

• Funciona apenas com TypeScript — Python, Go, iOS nativo ficam de fora
• Não é uma API pública — não dá para compartilhar com parceiros externos
• Vendor lock-in leve: migrar para REST/GraphQL depois requer reescrita

Se você está montando a stack de um projeto Next.js novo, nosso artigo sobre desenvolvimento web moderno com Next.js detalha como tRPC se encaixa no ecossistema atual.

Server Components e a Nova Era do Data Fetching

Desde o Next.js 13 e consolidado no Next.js 15, Server Components mudaram como pensamos sobre comunicação cliente-servidor. Em vez de expor uma API e consumi-la no frontend, você pode buscar dados diretamente no servidor durante a renderização — sem precisar de REST, GraphQL ou tRPC para muitos casos.

Isso não elimina a necessidade de APIs, mas muda onde elas vivem:

• Server Components: buscam dados diretamente no banco ou em serviços internos. Zero HTTP requests do cliente. Ideal para dados que não mudam frequentemente ou que precisam de SEO.
• Server Actions: permitem mutações diretas do servidor sem expor endpoints explícitos. Type-safe por padrão no Next.js 15 com TypeScript.
• Client Components: quando precisar de interatividade no browser, aí sim uma API (REST, GraphQL ou tRPC) entra em cena.

A implicação prática é que muitos projetos Next.js 15 hoje usam uma mistura: Server Components para a maioria das telas, tRPC ou Server Actions para mutações, e REST ou GraphQL apenas para integrações externas ou apps mobile.

Para projetos que precisam de autenticação robusta entre essas camadas, vale a pena entender as diferenças entre JWT, OAuth2 e session-based auth.

Matriz de Decisão por Tipo de Projeto

Critério	REST	GraphQL	tRPC
API pública / parceiros externos	Excelente	Bom	Não recomendado
Múltiplos clientes (web + mobile)	Médio	Excelente	Médio
Monorepo TypeScript full-stack	Bom	Bom	Excelente
Time com experiência limitada	Excelente	Ruim	Bom
Caching HTTP nativo	Excelente	Ruim	Médio
Type-safety end-to-end	Médio	Bom	Excelente
Integrações com sistemas legados	Excelente	Médio	Ruim
Performance em mobile com dados complexos	Médio	Excelente	Bom
Complexidade de setup	Baixa	Alta	Baixa
Ecossistema e tooling	Maduro	Maduro	Jovem

A decisão raramente é binária. Muitas arquiteturas maduras usam REST para APIs públicas, tRPC para comunicação interna entre serviços TypeScript e GraphQL para o BFF (Backend for Frontend) consumido pelo app mobile.

API-first com IA: REST e GraphQL em 2026

A explosão de integrações com IA generativa em 2025 e 2026 trouxe uma nova camada de complexidade para decisões de API. Modelos de linguagem, agents autônomos e assistentes de código consomem APIs de formas que humanos não consomem: eles precisam de schemas bem documentados, endpoints previsíveis e respostas estruturadas.

REST se beneficia disso porque OpenAPI (Swagger) é o padrão de facto para documentação machine-readable. Ferramentas como LangChain e CrewAI consomem especificações OpenAPI para gerar chamadas de API automaticamente. Se você está construindo um produto que será consumido por agents de IA, REST com OpenAPI 3.1 é a aposta mais segura.

GraphQL também funciona bem com IA, mas exige que o modelo entenda o schema antes de gerar queries. Isso é viável, mas adiciona uma camada de complexidade que REST não tem.

tRPC, por outro lado, é invisível para IA externa. É uma ferramenta de produtividade interna, não uma interface para consumo externo. Se seu produto precisa ser "plugável" em ecossistemas de IA, tRPC sozinho não é suficiente — você vai precisar de uma camada REST ou GraphQL por cima.

FAQ

Posso misturar REST, GraphQL e tRPC no mesmo projeto? Sim, e muitas vezes é a decisão correta. REST para APIs públicas e integrações externas, GraphQL para apps mobile com necessidades de dados complexas, e tRPC para comunicação interna em monorepo TypeScript. O custo é a complexidade operacional de manter três protocolos.

tRPC funciona fora do Next.js? Sim, tRPC funciona com qualquer framework TypeScript: Express, Fastify, Remix, Nuxt. Mas a DX máxima é realmente no ecossistema Next.js + React Query (TanStack Query), onde a integração é praticamente zero-config.

GraphQL ainda vale a pena em 2026? Para projetos que se encaixam nos casos de uso ideais — múltiplos clientes, dados altamente relacionais, times grandes — sim. Para projetos simples ou times pequenos, o overhead de setup e manutenção pode não compensar. A hype passou, mas a tecnologia continua sólida onde faz sentido.

Server Actions substituem tRPC? Para mutações simples em projetos Next.js 15, Server Actions cobrem boa parte do que tRPC faz. Mas tRPC ainda é superior para queries complexas, subscriptions em tempo real, e projetos onde o backend precisa ser independente do framework de frontend.

Como documentar uma API REST para consumo externo? Use OpenAPI 3.1 com Swagger UI ou Redoc. Mantenha a especificação versionada junto com o código. Ferramentas como Zod podem gerar schemas OpenAPI automaticamente a partir das validações do backend, eliminando duplicação.

Conclusão

Não existe protocolo universalmente superior — existe protocolo certo para o contexto certo.

Escolha REST quando você precisa de uma API consumível por qualquer cliente, em qualquer linguagem, com tooling maduro e caching HTTP. É a escolha segura para a maioria dos projetos.

Escolha GraphQL quando você tem múltiplos clientes com necessidades de dados divergentes, um time dedicado para o schema e dados altamente relacionais. O investimento em aprendizado se paga em flexibilidade.

Escolha tRPC quando você está construindo um produto Next.js 15 full-stack com TypeScript e quer a melhor experiência de desenvolvimento possível. A type-safety end-to-end elimina uma classe inteira de bugs.

No SystemForge, cada projeto começa com uma decisão arquitetural documentada — protocolo de API, estratégia de autenticação, política de versionamento. O resultado é um sistema que o próximo desenvolvedor consegue entender e evoluir sem decifrar código legado. Se você está iniciando uma API ou migrando uma existente, podemos ajudar a estruturar essa decisão com base no seu contexto específico.

Atualizado em maio de 2026