tRPC vs oRPC: API type-safe em TypeScript
tRPC vs oRPC: tipagem ponta a ponta, OpenAPI e critérios de escolha no monorepo.
Por que isso é importante
tRPC vs oRPC: batalha typesafe — madureza e DX do time pesam mais que Twitter.
Leitura relacionada: tRPC no Next.js · TypeScript + tRPC custo · CRUD Fastify + Postgres · Curso tRPC.
Por que isso é importante
tRPC vs oRPC é disputa de API type-safe: tipagem ponta a ponta e DX no client. Escolha pelo ecossistema do monorepo e pela curva do time — não pelo tweet.
Padrões modernos de Type Safety em APIs e RPCs
Você tem pelo menos quatro caminhos para fazer chamadas type-safe em TypeScript: TRPC, ORPC,
server functions e a velha API REST. Next.js, Nest.js, TanStack Start — todos aceitam essas abordagens,
mas cada uma muda completamente como você estrutura, mantém e escala seu sistema. Escolher não é sobre
opinião, é sobre contexto.
O que é API Raw?
API raw é a abordagem clássica: rotas REST (GET, POST...), contrato manual, fetch no front, validação
com Zod ou Valibot se você se lembrar de fazer. Controle total sobre URL e payload, mas zero ajuda do
TypeScript para manter front e back sincronizados. Mudou a API? O front quebra em produção, não em
compilação. Validação? Só se você implementar, senão passa qualquer coisa.
Atenção
Ao usar APIs raw, qualquer mudança no formato esperado pode gerar erros silenciosos no
front, visto que o TypeScript não será capaz de alertar inconsistências de contrato.
Server Functions: middle ground entre conveniência e type-safety
Server functions são o meio termo: você escreve funções no servidor, chama no cliente, e o framework
cuida da tipagem automaticamente. TanStack Start e Next.js têm suas próprias versões, mas não conversam
entre si. Cada um com seu formato de URI, payload e resposta. A vantagem? Velocidade. A desvantagem?
Você perde controle sobre o endpoint e formato, e não existe padrão universal.
Atenção
Apesar do ganho de produtividade, server functions não seguem um padrão universal e
não são interoperáveis entre frameworks distintos.
TRPC: type safety de ponta a ponta para RPCs em TypeScript
TRPC é type safety de verdade: monorepo onde backend e frontend compartilham os mesmos tipos. Mudou um
procedimento? O compilador grita antes de você fazer commit. Validação com Zod vem de fábrica, rotas são
flexíveis, e tudo funciona de ponta a ponta. O único porém: só funciona bem quando todo mundo usa TypeScript.
Cliente externo em Go ou Rust? Complica.
Atenção
O maior diferencial do TRPC é evitar completamente APIs quebradas por mudanças não
sincronizadas, elevando a produtividade e robustez de equipes fullstack TypeScript.
ORPC: TypeSafe RPC interoperável e alinhado com padrões abertos
ORPC resolve o problema de quando você precisa de type safety mas também precisa conversar com outras
linguagens. Times usando Go, Rust, Python consumindo sua API? ORPC gera contratos OpenAPI que todo mundo
entende. Você mantém a vantagem do TypeScript, mas não fica preso nele. O custo é setup um pouco mais
rigoroso.
Atenção
Se sua API precisa ser consumida por times em stacks diferentes, onde TypeScript puro
não é opção universal para o cliente, ORPC é a abordagem certa.
Comparativo prático das principais abordagens
Aqui está o que realmente importa em cada abordagem:
API Raw
Endpoints clássicos com controle total, integração manual de tipos e validação.
+ Prós
- • Controle total sobre URL e resposta
- • Adapta a qualquer cliente
- • Flexibilidade máxima
− Contras
- • Sem segurança de tipo automatizada
- • Validação depende de implementação manual
- • Não há alerta para mudanças no contrato
Server Functions
Procedures internas, tipagem propagada, conveniência extrema porém padrão proprietário.
+ Prós
- • Type Safety entre front e back
- • Validação de input via validador integrado
- • Produtividade altíssima em mono-repo
− Contras
- • Formato de endpoint pouco padronizado
- • Pouca interoperabilidade entre frameworks
- • Menos controle sobre URLs/payloads
TRPC
RPC TypeSafe integrada, ideal para mono-repo ou times fullstack TypeScript.
+ Prós
- • Sync automáticos de tipos
- • Validação embutida
- • Controle razoável de rotas
- • Alternância simples entre SSR/client
− Contras
- • Padrão menos conhecido fora do universo TypeScript
- • Extensões necessárias para OpenAPI
- • Não interoperável nativamente com clientes não TS
ORPC
RPC TypeSafe com padrão aberto e fácil consumo por outros stacks.
+ Prós
- • Type Safety
- • Compatível com OpenAPI
- • Pronto para multiplas linguagens
- • Ideal para times distribuídos
− Contras
- • Curva de aprendizado para times acostumados ao TRPC
- • Padronização rígida de contratos
- • Pode demandar tooling extra
Passo a passo: do API raw ao ORPC
Vamos do mais simples ao mais complexo, experimentando cada abordagem:
- Passo 1: Inicie um projeto TanStack Start ou Next.js com
TypeScript. - Passo 2: Implemente um endpoint de API raw com route handler
(GET/POST), definindo a tipagem manualmente e validação com Zod opcional. - Passo 3: Crie funções de servidor, usando helpers do framework
para orquestrar lógica, propagando tipos do servidor ao cliente. - Passo 4: Teste a integração usando apenas server functions,
observando o formato rígido das URLs e payloads. - Passo 5: Instale e configure TRPC, criando o router com
procedures e usando Zod para validar as entradas. - Passo 6: Migre o consumo no client para hooks TRPC, validando
que as alterações no contrato refletem automaticamente na tipagem. - Passo 7: Para interoperabilidade, implemente ORPC adicionando
definição de contratos que geram documentação e clients para múltiplas
linguagens.
Ferramentas e recursos úteis
TRPC
RPC Type Safe para TypeScript, com integração completa front-back.
ORPC
RPC interoperável, gera contratos OpenAPI type safe.
TanStack Start
Starter fullstack com suporte nativo de TRPC e ORPC.
Zod
Validação de esquemas e tipos para os dados.
Valibot
Alternativa simples para validação em TS.
Next.js App Router
Framework fullstack com suporte a server functions.
Cuidados essenciais ao evoluir sua arquitetura de RPC
Atenção
Não negligencie os detalhes do controle de versões e compatibilidade de contratos.
Mudar signatures sem versionamento pode quebrar clientes externos quando migrar de
raw/server functions para TRPC/ORPC.
Quando usar cada abordagem?
API raw serve para protótipos, demos, tools internos — cenários onde você precisa de controle total
e não liga para type safety. Server functions são perfeitas para MVPs e quando você não precisa de
padrão universal. TRPC domina em monorepos TypeScript puro. ORPC entra quando você tem times em
linguagens diferentes ou precisa de OpenAPI. Simples assim.
Dicas de produtividade e redução de bugs
Atenção
Sempre inicie seu backend modelando os esquemas de input/output (usando Zod ou
similar). Independentemente do framework, uma boa base de tipos diminui erros em todas
as abordagens.
Resumo e escolhas rápidas
Resumindo: API raw dá controle mas perde em segurança. Server functions são rápidas mas proprietárias.
TRPC é imbatível em TypeScript, mas só em TypeScript. ORPC conecta tudo mas exige disciplina.
Não existe melhor, existe o que faz sentido pro seu caso.
Próximo passo prático
Escolha de RPC é decisão de arquitetura: meça DX, OpenAPI e quem consome a API — não o tweet da semana.
Implemente o mesmo endpoint nos dois stacks e compare tipagem, docs e deploy antes de padronizar o monorepo.
Para praticar backend tipado de ponta a ponta, o CrazyStack cobre Next/Node com contratos reais — sem prometer que ‘oRPC resolve tudo’.
Checklist de Implementação
- Entendeu o que é API Raw e suas limitações
- Testou funções de servidor e avaliou facilidade
- Comparou prós e contras do TRPC para sua stack
- Analisou necessidade de interoperabilidade para priorizar ORPC
- Montou exemplos práticos das quatro abordagens
- Validou segurança de tipo e fluxo de validação do input
Perguntas frequentes
tRPC vs oRPC: quem vence?
tRPC é maduro no Next. oRPC compete em typesafe RPC. Escolha por ecossistema e DX do time.
Preciso de GraphQL?
Não se tRPC/oRPC cobrem seus casos.
E REST?
Ainda ótimo para público/multi-client.
Como decidir?
Spike de 1 endpoint real nos dois.
Continue explorando
Continue: tRPC no Next.js · TypeScript + tRPC custo · CRUD Fastify + Postgres · Curso tRPC.
Perguntas frequentes
tRPC ou oRPC: qual escolher?
tRPC vence em madureza e DX em monorepo TS puro. oRPC ganha quando você precisa de OpenAPI/consumidores fora de TypeScript. Faça spike de um endpoint real nos dois.
Server Functions substituem tRPC?
Cobrem casos simples no framework. Para contratos compartilhados, routers e clientes tipados em vários apps, RPC dedicado costuma escalar melhor.
Ainda faz sentido REST/API raw?
Sim para API pública, multi-linguagem e integrações. Type-safety RPC brilha quando client e server são do mesmo time TS.
Preciso de GraphQL?
Só se o modelo de dados e clientes pedirem. Muitos times resolvem com tRPC/oRPC + queries bem desenhadas sem GraphQL.
O que é API Raw?
API raw é a abordagem clássica: rotas REST (GET, POST...), contrato manual, fetch no front, validação com Zod ou Valibot se você se lembrar de fazer. Controle total sobre URL e payload, mas zero ajuda do TypeScript para manter front e back sincronizados. Mudou a API? O front quebra em produção, não em compilação. Validação? Só se você implementar, senão passa qualquer coisa.
Quando usar cada abordagem?
API raw serve para protótipos, demos, tools internos — cenários onde você precisa de controle total e não liga para type safety. Server functions são perfeitas para MVPs e quando você não precisa de padrão universal. TRPC domina em monorepos TypeScript puro. ORPC entra quando você tem times em linguagens diferentes ou precisa de OpenAPI. Simples assim.