# GraphQL vs tRPC: schema-first ou TypeScript?

> GraphQL vs tRPC: uma camada de query tipada e agnóstica de linguagem vs type safety TypeScript end-to-end sem schema. Casos de uso e adequação ao CI comparados com honestidade.

Source: https://latchkey.dev/pt/learn/tool-comparisons/graphql-vs-trpc  
Updated: 2026-06-26

GraphQL é uma camada de query baseada em schema e agnóstica de linguagem; tRPC oferece type safety TypeScript end-to-end entre cliente e servidor sem schema ou codegen.

GraphQL define um schema tipado que qualquer cliente ou linguagem pode consumir, com queries flexíveis e um ecossistema rico, adequando-se a APIs públicas e clientes poliglotas. tRPC é apenas TypeScript: procedures do servidor são importadas como chamadas de cliente totalmente tipadas, eliminando schemas e codegen para apps full-stack TS, mas apenas dentro do mundo TS. GraphQL favorece flexibilidade e interoperabilidade; tRPC favorece type safety sem atrito em monorepos TS.

## Comparison

|  | GraphQL | tRPC |
| --- | --- | --- |
| Linguagens | Qualquer | Somente TypeScript |
| Schema | Explícito, tipado | Inferido do código |
| Codegen | Frequentemente necessário | Nenhum |
| Clientes | Poliglota, público | Full-stack TS |
| Melhor para | Clientes públicos/variados | Monorepos TS |

## Caso de uso e type safety

GraphQL se adequa a APIs públicas, mobile e consumidores poliglotas que precisam de um contrato formal. tRPC se adequa a apps full-stack TypeScript (frequentemente Next.js) onde cliente e servidor compartilham tipos diretamente, dando segurança end-to-end instantânea sem um schema, mas não consegue servir consumidores não-TS ou externos com a mesma limpeza.

## Em CI

Pipelines de GraphQL validam o schema e rodam codegen de cliente. tRPC depende do compilador TypeScript, então o type-check é o gate principal. Ambos rodam em runners gerenciados, onde runners mais rápidos encurtam as etapas de type-check e codegen.

## Decide with your own numbers, not a feature table

Feature comparisons age badly and rarely decide anything, because both tools in a mature category can do the job. What differs is how each behaves on your repository, and that takes one afternoon to measure.

```Terminal
# time a cold install with each candidate, cache cleared
hyperfine --prepare "rm -rf node_modules" --warmup 1 \
  "<tool-a> install" "<tool-b> install"

# and the thing CI actually pays for: a cold run with no local cache
docker run --rm -v "$(pwd):/w" -w /w node:22 sh -c "<tool> install"
```

> Measure the cold path. Warm local benchmarks favour whichever tool you already have cached, which is exactly the condition a CI runner never has.

## What actually changes when you switch

- Lockfile format. A switch is a one-way door for anyone still on the old tool until everyone migrates, so plan it as a single coordinated change.
- Resolution strictness. Tools differ on whether an undeclared transitive import works, and the stricter one will surface latent bugs as new failures.
- CI cache configuration. The cache path and key differ per tool; carrying over the old ones silently disables caching.
- Everyone on the team and every runner must move together. Pin the version so they cannot drift.

## O veredito

APIs públicas ou clientes poliglotas que precisam de um contrato formal e flexível: GraphQL. Apps full-stack TypeScript internos que querem type safety end-to-end sem atrito: tRPC. tRPC é excelente dentro de um monorepo TS; GraphQL é a escolha quando consumidores externos ou não-TS importam.

## FAQ

### GraphQL vs tRPC: Schema-First or TypeScript?

GraphQL defines a typed schema any client or language can consume, with flexible queries and a rich ecosystem, suiting public APIs and polyglot clients. tRPC is TypeScript-only: server procedures are imported as fully typed client calls, eliminating schemas and codegen for full-stack TS apps, but only within the TS world.

### Use case and type safety?

GraphQL fits public APIs, mobile, and polyglot consumers needing a formal contract. tRPC fits full-stack TypeScript apps (often Next.js) where client and server share types directly, giving instant end-to-end safety without a schema, but it cannot serve non-TS or external consumers as cleanly.

### In CI?

GraphQL pipelines validate the schema and run client codegen. tRPC relies on the TypeScript compiler, so type-check is the main gate. Both run on managed runners, where faster runners shorten type-check and codegen steps.

### Which should I choose?

Public APIs or polyglot clients needing a formal, flexible contract: GraphQL. Internal full-stack TypeScript apps wanting frictionless end-to-end type safety: tRPC. tRPC is excellent inside a TS monorepo; GraphQL is the choice when external or non-TS consumers matter.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt