Ya viviste esa reunión. Alguien volvió de una charla y quiere migrar toda la superficie de APIs internas a gRPC para el viernes. Nadie preguntó qué problema resuelve. Simplemente sonaba rápido.
Así arrancan la mayoría de las migraciones a gRPC, y por eso tantas quedan a mitad de camino, con una mezcla de servicios REST y gRPC que ya nadie termina de entender del todo. La herramienta no es el problema. La forma en que se decide usarla, sí.
Así que salteemos el discurso de marketing. gRPC es genuinamente bueno en algunas cosas. También es la opción equivocada para buena parte de los servicios que estás corriendo ahora mismo, y hacer como si no fuera así es la forma más rápida de terminar debuggeando un payload binario a las dos de la mañana porque a alguien no le dio la gana de revisar qué devuelve un curl.
Lo que gRPC realmente te da
La ventaja real de gRPC no es la velocidad en abstracto que todos repiten. Es un contrato estricto. Protocol Buffers te obliga a definir la interfaz del servicio antes de escribir la implementación, y esa definición se aplica en ambos extremos. Si un tipo de campo cambia sin el versionado correspondiente, el build se rompe en vez de que un cliente interprete mal un campo JSON tres meses después, en silencio.
Ese contrato importa sobre todo en un escenario específico: comunicación interna entre servicios donde controlas ambos extremos y la superficie cambia seguido. Dos equipos que despliegan de forma independiente, llamándose decenas de veces por request, se benefician enormemente de un esquema que no puede desalinearse sin que alguien se dé cuenta en tiempo de compilación.
La ganancia de rendimiento también es real, pero es más chica de lo que promete el discurso para la mayoría de las cargas de trabajo. El multiplexado de HTTP/2 y la serialización binaria recortan latencia real en llamadas de alto throughput entre servicios que viven en el mismo data center. Si haces doce llamadas por request entre servicios que están a milisegundos de distancia, eso suma. Si haces una llamada cada tantos segundos a una API downstream, no vas a notar la diferencia, y sumaste un formato de serialización que tu ingeniero de guardia necesita una herramienta especial para leer.
Protobuf también obliga a una disciplina que la mayoría de los equipos REST dicen tener y casi nunca aplican de verdad: la compatibilidad hacia atrás como restricción de primer nivel. Agregar un campo es seguro. Eliminar o renumerar uno rompe a cada cliente que sigue en el esquema viejo, y el compilador lo deja en evidencia antes de que salga a producción. Los equipos que ya sufrieron un cliente REST descartando en silencio una clave JSON renombrada suelen valorar esto mucho más que los que todavía no pasaron por eso.
Donde REST sigue ganando, y no es poco
Esto importa más de lo que admiten la mayoría de los diagramas de arquitectura. El costo de un sistema no es solo lo que cuesta construirlo. Es lo que cuesta operarlo bajo presión, seis meses después de que la persona que lo construyó se cambió de equipo. Que REST se pueda inspeccionar fácil es una característica operativa, no una limitación heredada.
Hay también un costo de contratación y onboarding que casi nunca aparece en estas comparaciones. Un ingeniero nuevo puede ser productivo contra una API REST en una hora, leyendo la documentación y disparando requests desde Postman. Lograr lo mismo contra un servicio gRPC implica instalar las herramientas correctas, generar stubs de cliente desde archivos .proto, y entender un formato de serialización que probablemente nunca tocó fuera de este trabajo. Ese tiempo de adaptación es un costo real, y se repite cada vez que contratas.
La decisión que nadie quiere tomar explícitamente
Acá está la parte que se salta en la mayoría del contenido sobre "gRPC vs REST": la respuesta honesta es que ninguno gana de forma universal, y probablemente vas a querer los dos, a propósito, no por accidente.
El modo de falla no es elegir el equivocado. Es elegir uno solo y aplicarlo en todos lados por consistencia, sin más razón que esa. La consistencia es un buen default hasta que te cuesta observabilidad en un endpoint que mira al cliente, o hasta que obliga a tus consumidores externos a pelear con la compilación de protobuf solo para mandar un request.
El streaming es el argumento que se olvidan de mencionar
Si tu carga de trabajo realmente necesita streaming bidireccional (piensa en actualizaciones de posición en tiempo real, chat, o telemetría continua de una flota de dispositivos), el soporte nativo de gRPC para streaming es una razón legítima para elegirlo, independiente del argumento interno versus externo de arriba. REST puede simular streaming con long polling o server-sent events, pero los dos son parches. Los streams de HTTP/2 de gRPC se construyeron para esto desde el principio, y si el streaming es central en lo que estás construyendo, eso solo puede definir la decisión.
Vale la pena marcarlo porque es el único caso donde la elección no pasa realmente por tráfico interno versus externo. Pasa por si tu modelo de datos es fundamentalmente un stream o fundamentalmente un par pregunta-respuesta. La mayoría de los servicios con forma de CRUD son lo segundo. Algunos genuinamente no lo son.
Cuando la respuesta honesta es "todavía no"
Hay una versión de esta decisión que aplica a muchos equipos que leen una comparación de gRPC por primera vez: no tienen el problema que gRPC resuelve. Si corres cuatro servicios con tráfico moderado y un equipo chico, el contrato que ofrece gRPC está resolviendo un problema de coordinación que todavía no tienes, porque todos los que tocan el código ya saben qué construyó cada uno.
Eso cambia al cruzar cierta cantidad de servicios o cierta cantidad de equipos desplegando de forma independiente unos contra las APIs de otros. No hay un número mágico, pero la señal es concreta: si ya tuviste un incidente donde un equipo cambió la forma de una respuesta JSON y rompió a un consumidor que nadie recordaba que existía, ya encontraste el problema para el que se construyó el contrato de gRPC. Si no te pasó, adoptar gRPC ahora es resolver un caso hipotético, y vas a pagar el costo de herramientas y onboarding por un beneficio que todavía no puedes señalar.
Lo que esto significa en una migración real
Si estás migrando un servicio REST existente a gRPC por un problema de latencia específico y medido, hazlo solo para ese servicio. No dejes que se expanda por default a servicios que no comparten ese mismo perfil de throughput.
Mantén las definiciones .proto en un repositorio compartido con ownership real y un proceso de revisión, porque toda la propuesta de valor se derrumba en el momento en que dos equipos definen tipos de mensaje superpuestos de forma independiente. Versiona tus servicios de forma explícita. La rigidez de gRPC solo es un activo si alguien realmente hace cumplir esa disciplina de versionado.
Planifica la observabilidad antes de la migración, no después. Tus dashboards, la agregación de logs y el tracing que ya tienes casi seguro se construyeron alrededor de códigos de estado HTTP y payloads JSON. Los códigos de estado de gRPC mapean distinto, y los payloads binarios no aparecen en una línea de log de la misma forma que un body REST. Los equipos que se saltean este paso terminan volando a ciegas las primeras semanas después del corte, justo cuando más necesitan visibilidad sobre qué cambió.
La postura
gRPC no es el reemplazo moderno de REST. Es una herramienta distinta que cambia inspeccionabilidad por cumplimiento de contrato y throughput crudo, y ese cambio vale la pena en un conjunto de situaciones más chico de lo que dejan entender la mayoría de las charlas de conferencia. Los ingenieros que aciertan acá no son los que eligieron la opción que suena más moderna. Son los que pueden explicar exactamente qué problema resuelve cada protocolo en su stack, y por qué el otro no alcanzaba para ese caso puntual.
Si no puedes responder esa pregunta sobre tus propios servicios ahora mismo, esa es la señal real. No cuál está más de moda este año.
