🔗 tRPC vs REST vs GraphQL: qual escolher em 2025 para seu projeto web?

Introdução: Como escolher entre tRPC, REST e GraphQL?
Com o avanço das aplicações web e mobile, a forma como cliente e servidor se comunicam continua evoluindo. REST dominou por anos, GraphQL ganhou força com seu modelo declarativo, e tRPC surgiu como uma opção moderna com foco em segurança de tipos.
Mas, em 2025, qual abordagem faz mais sentido para seu projeto?
Neste post, vamos comparar tRPC, REST e GraphQL de forma objetiva e didática, destacando prós, contras, exemplos práticos e recomendações.
REST: o padrão clássico das APIs
Vantagens
-
Simples e amplamente suportado
-
Usa HTTP nativamente (GET, POST, PUT, DELETE)
-
Fácil de testar com ferramentas como Postman ou cURL
-
Boas práticas e padrões já bem estabelecidos
Exemplo (Express.js)
app.get('/users/:id', (req, res) => {
const user = getUserById(req.params.id);
res.json(user);
});
Desvantagens
-
Overfetching ou underfetching de dados
-
Requer definição e manutenção manual de rotas e tipos
-
Pouca flexibilidade em APIs complexas
GraphQL: flexibilidade com consulta declarativa
Vantagens
-
O cliente escolhe os dados que quer
-
Menos requisições em aplicações complexas
-
Fortemente tipado (via schema GraphQL)
-
Boa integração com frontend (Apollo, Relay)
Exemplo de consulta
query {
user(id: "123") {
name
email
}
}
Desvantagens
-
Curva de aprendizado maior
-
Exige implementação de schema e resolvers
-
Pode ser overkill para projetos pequenos
-
Riscos de performance se não for bem controlado
tRPC: tipos de ponta a ponta no TypeScript
Vantagens
-
Sem necessidade de schema separado: usa os tipos TypeScript diretamente
-
Autocompletar e validação em tempo de desenvolvimento
-
Integração perfeita com Next.js
-
Menos boilerplate comparado a REST/GraphQL
Exemplo
Backend:
export const appRouter = router({
getUser: publicProcedure
.input(z.string())
.query(({ input }) => getUserById(input)),
});
Frontend (com segurança de tipos!):
const { data } = trpc.getUser.useQuery('123');
Desvantagens
-
Fortemente acoplado ao TypeScript
-
Difícil de expor publicamente (sem SDK)
-
Mais indicado para monorepos ou fullstack TypeScript
Comparativo direto: tRPC, REST e GraphQL
Critério | REST | GraphQL | tRPC |
---|---|---|---|
Curva de aprendizado | Baixa | Média/Alta | Baixa (para TS devs) |
Flexibilidade | Média | Alta | Média |
Tipagem end-to-end | Manual | Sim (com schema) | Sim (nativo com TS) |
Ideal para | APIs públicas | Frontends dinâmicos | Monorepos TS/Next.js |
Ferramentas necessárias | Nenhuma | Apollo, GraphQL tools | Zod, tRPC client |
Boas práticas ao escolher sua stack de API
-
REST é ideal para APIs públicas e projetos com integração ampla.
-
GraphQL brilha em apps com muitas entidades e requisitos dinâmicos.
-
tRPC é excelente em projetos TypeScript fullstack com Next.js ou Vite.
Use o que melhor se encaixa no seu time, stack e escala do projeto. O hype não deve ser o fator principal.
Armadilhas comuns
-
❌ Usar GraphQL só porque é "moderno", mesmo sem necessidade real.
-
❌ Usar tRPC sem considerar que seu cliente não é em TypeScript.
-
❌ REST mal estruturado, com rotas inconsistentes e sem validação.
Conclusão: não existe bala de prata
A escolha entre tRPC, REST e GraphQL depende mais do contexto do que de uma tecnologia ser “melhor” que outra.
Se você quer produtividade e segurança de tipos em um projeto fullstack TS, tRPC é uma escolha moderna. Se precisa de flexibilidade no frontend, GraphQL pode ser o melhor. E se busca simplicidade e compatibilidade, REST ainda é um clássico confiável.