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:
Ferramentas e recursos úteis
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
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.