Un desarrollador pasó dos semanas cambiando una API REST por tRPC en una herramienta interna.

Por qué el cambio fue importante

El stack anterior nos obligaba a mantener un DTO, un validador y un conjunto separado de tipos de TypeScript para el frontend. Si se renombraba un campo en el backend, la API seguía devolviendo un 200, la interfaz de usuario seguía renderizando y el error solo aparecía como valores “undefined”. Un cliente detectó el problema antes que cualquier miembro del equipo. Los contratos de REST ocultaban el problema y los archivos adicionales añadían un mantenimiento que nunca valió la pena.

Cómo era la configuración de REST

  • Especificación OpenAPI – un archivo estático que describía los endpoints, pero que nunca servía como la única fuente de verdad.
  • Paso de generación del SDK del cliente – un trabajo de CI que producía un wrapper de JavaScript.
  • Colección de Postman – un artefacto de prueba compartido que nadie utilizaba.
  • Interfaces de TypeScript manuales – tipos escritos a mano que debían mantenerse sincronizados con el servidor.

Cada cambio en la API afectaba al menos a tres de esos artefactos, además del validador y cualquier llamada fetch posterior. El proceso era lento y propenso a errores.

Cómo tRPC redujo la base de código

tRPC elimina el archivo de contrato separado. El servidor exporta un tipo de router; el cliente importa ese mismo tipo. Si se renombra un campo en el backend, el editor señala la discrepancia al instante, sin necesidad de ejecutar el código ni de que falle una solicitud. El desarrollador eliminó:

  • El archivo de especificación OpenAPI.
  • El paso de generación del SDK del cliente.
  • La colección de Postman que no se usaba.
  • La carpeta de interfaces de TypeScript manuales.

El repositorio se volvió más ligero y el feedback llegaba durante el desarrollo en lugar de después del despliegue.

Limitaciones de tRPC

tRPC solo funciona cuando ambos extremos hablan TypeScript. Se queda corto si:

  • Un equipo de móviles utiliza Swift o Kotlin.
  • La API debe ser consumida por socios externos.
  • Necesitas una interfaz pública e independiente del lenguaje.

Lo que la migración requirió realmente

El esfuerzo de dos semanas fue más que un simple copiar y pegar. El desarrollador tuvo que:

  • Reescribir cada llamada fetch para usar las funciones del cliente de tRPC.
  • Ajustar la lógica de manejo de errores.
  • Actualizar los componentes de la interfaz de usuario que dependían de estados de carga y reintento vinculados a respuestas HTTP puras.

Preguntas que debes hacerte antes de empezar

  • ¿Tanto el frontend como el backend usan TypeScript? Sin un sistema de tipos compartido, tRPC pierde su principal ventaja.
  • ¿El mismo equipo es responsable de ambos lados? Las brechas de responsabilidad pueden reintroducir la deriva de contratos.
  • ¿Estás solucionando un error concreto o siguiendo una tendencia? El aumento de productividad es real, pero debe resolver un punto de dolor existente.

Un enfoque híbrido para 2025

Muchos equipos encuentran el punto de equilibrio ejecutando ambos stacks:

  • tRPC para capas de aplicación internas donde la base de código es totalmente TypeScript y el mismo equipo es dueño del servidor y del cliente.
  • REST para webhooks, APIs públicas e integraciones con socios donde se requiere un acceso independiente del lenguaje.

Usar la herramienta adecuada para cada superficie mantiene el desarrollo interno rápido, al tiempo que preserva la apertura necesaria para los consumidores externos.

Conclusión: Reemplazar REST con tRPC puede eliminar artefactos de contrato duplicados y hacer que los errores aparezcan en el momento de la edición, pero las ganancias solo se materializan cuando todo el stack comparte TypeScript y el equipo puede absorber el coste de la migración. Una estrategia mixta te permite cosechar los beneficios sin excluir a los consumidores que no usan TypeScript.