REST APIVSGraphQL
REST API vs GraphQL
REST, con más de 20 años de historia, se enfrenta a GraphQL, nacido en Facebook. ¿Qué paradigma de diseño de API deberías elegir para el backend de tu aplicación móvil?
tRPC vs REST Comparación
APIs con type safety de extremo a extremo para TypeScript
VS
REST
Estándar de la industria agnóstico de lenguaje desde el año 2000
9 min de lecturaBackend
Comparación de puntuaciones
Cargando gráfico...
Puntuación detallada
| Categoría | tRPC | REST |
|---|---|---|
| Rendimiento | 9/10 | 9/10 |
| Facilidad de aprendizaje | 8/10 | 10/10 |
| Ecosistema | 8/10 | 10/10 |
| Comunidad | 9/10 | 10/10 |
| Mercado laboral | 7/10 | 10/10 |
| A prueba de futuro | 8/10 | 8/10 |
Pros y contras
tRPC
Pros
- Type safety del servidor al cliente — sin generación de código
- Validación con Zod integrada
- Integración nativa con React Query
- Soporte de subscriptions (WebSocket)
- Sistema de middleware + contexto
- Sin mantener un esquema OpenAPI/GraphQL
- Columna vertebral del t3-stack de Theo
- Usado por Vercel, Cal.com, Cloudflare
Contras
- Solo TypeScript — difícil para equipos poliglota
- Clientes móviles/nativos incompatibles con TS (requieren REST/GraphQL)
- Mala opción para API pública (sin spec abierta)
- Aumenta el tiempo de build en monorepos grandes
Ideal para
Apps full-stack en TypeScript (Next.js, Remix)APIs internas (servidor + cliente web del mismo equipo)Donde el type safety es críticoIteración rápida (cambios de esquema llegan al cliente al instante)Proyectos de ingeniería similares al T3 stack
REST
Pros
- Agnóstico de lenguaje — cualquier cliente
- Más de 25 años como estándar de la industria
- Ecosistema OpenAPI/Swagger maduro
- Caching HTTP nativo (Cloudflare, Varnish)
- Estándar para APIs públicas
- Compatibilidad directa con clientes móviles/nativos
- Tooling universal (Postman, curl)
- Compatibilidad hacia atrás a largo plazo
Contras
- Type safety manual (requiere codegen de OpenAPI)
- Mucho boilerplate — rutas, validadores y tipos por separado
- Over-fetching/under-fetching (la razón de ser de GraphQL)
- Versionado complejo (v1, v2, deprecación)
Ideal para
APIs públicasEquipos poliglota (iOS, Android, web, terceros)APIs estables a largo plazoEscenarios de alto caching (edge de Cloudflare)Cumplimiento del estándar de la industria
Comparación de código
tRPC
// server/router.ts
export const appRouter = t.router({
getUser: t.procedure
.input(z.object({ id: z.string() }))
.query(async ({ input }) => {
return await db.user.findUnique({ where: { id: input.id } });
}),
});
// cliente (type-safe, ¡con autocompletado!)
const user = await trpc.getUser.query({ id: "123" });
// user.name, user.email — completamente tipadoREST
// OpenAPI-first
GET /api/users/:id
Response: { "id": "123", "name": "Ali", "email": "..." }
// Cliente (definición manual de tipos o codegen)
const res = await fetch("/api/users/123");
const user: User = await res.json(); // Aserción manual de tipoConclusión
Monorepo TypeScript full-stack → tRPC (oro en type safety). API pública + clientes multi-lenguaje → REST. GraphQL es un camino intermedio — type-safe + agnóstico de lenguaje pero con alta complejidad. Híbrido: tRPC interno, fachada REST pública.
Solicita una consultoría gratuitaFAQ
Preguntas frecuentes
GraphQL es un paradigma de diseño distinto — un lenguaje de consultas. tRPC vs REST es TypeScript vs universal. GraphQL puede ser parte de una estrategia híbrida.