gRPC no es simplemente «REST más rápido». Es un modelo de llamadas remotas con contratos, generación de código y capacidades de streaming, diseñado para escenarios donde estas características aportan valor.

Introducción

Cuando una plataforma crece y divide sus responsabilidades entre servicios, la comunicación interna se convierte en parte importante de su arquitectura. REST ofrece interoperabilidad y una interfaz HTTP sencilla. gRPC aporta contratos definidos mediante Protocol Buffers, clientes generados y streaming sobre HTTP/2.

La pregunta no es cuál tecnología gana en todos los benchmarks. Es cuál se adapta mejor a las necesidades de comunicación, los lenguajes, la infraestructura y la capacidad operativa del equipo.

1. Modelo de REST

Una API REST suele exponer recursos mediante URLs y métodos HTTP:

GET /api/products/123

El contrato puede documentarse con OpenAPI y la respuesta suele utilizar JSON. Esto facilita la integración con navegadores, herramientas y sistemas externos.

REST es especialmente conveniente en fronteras públicas y cuando la interoperabilidad importa. Además, puede aprovechar directamente las semánticas de caché HTTP para operaciones compatibles.

2. Modelo de gRPC

gRPC define servicios y mensajes en archivos .proto:

syntax = "proto3";

service ProductService {
  rpc GetProduct (GetProductRequest)
      returns (ProductResponse);
}

message GetProductRequest {
  string id = 1;
}

message ProductResponse {
  string id = 1;
  string name = 2;
  double price = 3;
}

A partir del contrato se pueden generar clientes y servidores para lenguajes compatibles. Esto facilita la consistencia entre servicios y reduce la necesidad de construir manualmente cada cliente.

gRPC suele utilizar Protocol Buffers y HTTP/2. El formato binario puede reducir tamaño y coste de procesamiento en ciertos escenarios, pero el beneficio depende del mensaje y la implementación.

3. Por qué puede ser eficiente

El rendimiento puede beneficiarse de:

• Mensajes binarios con esquema.
• Clientes generados.
• Conexiones y canales reutilizados.
• Multiplexación de HTTP/2.
• Streaming para flujos de datos.
• Contratos que hacen explícitos los tipos.

Pero la serialización rara vez explica por sí sola todo el tiempo de respuesta. Una llamada gRPC que espera una consulta lenta o un servicio externo seguirá siendo lenta.

4. Canales, deadlines y cancelación

No conviene crear un canal nuevo para cada llamada. Reutilizar canales y conexiones reduce trabajo de establecimiento y permite aprovechar HTTP/2.

Las llamadas también deben tener deadlines: un límite temporal explícito que impida esperar indefinidamente. La cancelación debe propagarse cuando una operación deja de ser necesaria.

Hay que revisar cuidadosamente los reintentos. Repetir una operación no idempotente puede provocar efectos duplicados si no existe un mecanismo adecuado de idempotencia.

5. Streaming: cuándo sí y cuándo no

gRPC admite varios patrones:

• Una solicitud y una respuesta.
• Una solicitud con un flujo de respuestas.
• Un flujo de solicitudes con una respuesta.
• Streaming bidireccional.

Esto puede ser útil para procesamiento continuo, sincronización o intercambio de eventos entre servicios.

Sin embargo, los flujos prolongados complican la gestión de recursos, los límites de concurrencia y la recuperación de fallos. No se debe usar streaming solo porque esté disponible; hay que comprobar que encaja con el patrón de negocio.

6. Compresión y caché

Protocol Buffers ya ofrece una representación binaria eficiente en muchos casos. Añadir compresión puede reducir todavía más el tamaño, pero también consumir CPU. Para mensajes pequeños, el beneficio puede ser insignificante.

gRPC puede utilizar cachés de aplicación o de servicios, pero no debe asumirse que aprovecha automáticamente la caché HTTP convencional como un endpoint REST GET. La estrategia debe diseñarse explícitamente.

7. Interoperabilidad y clientes

REST suele ser más sencillo para APIs públicas y clientes web genéricos. gRPC requiere que el cliente soporte el protocolo. En navegadores, gRPC-web y los proxies compatibles pueden ser necesarios según la arquitectura.

Esto no convierte a gRPC en una mala opción para el frontend, pero sí agrega consideraciones de compatibilidad, generación de clientes y despliegue.

8. Cómo comparar correctamente

Una comparación útil debe realizar la misma operación y mantener constantes datos, lógica de negocio, infraestructura y condiciones de red.

Mide:

• Latencia p50, p95 y p99.
• Throughput bajo concurrencia.
• CPU y memoria.
• Bytes transmitidos.
• Coste de serialización y deserialización.
• Tiempo de base de datos y dependencias.
• Errores, deadlines y reintentos.

Compara conexiones nuevas y reutilizadas, así como diferentes tamaños de mensaje. No es válido comparar una API REST sin optimizar con una implementación gRPC cuidadosamente afinada y atribuir toda la diferencia al protocolo.

9. Cuándo elegir cada uno

REST suele ser mejor cuando:

• La API es pública o consumida por clientes diversos.
• El modelo de recursos encaja con el dominio.
• La interoperabilidad y la caché HTTP son importantes.
• El volumen y el rendimiento actuales son suficientes.

gRPC suele ser atractivo cuando:

• La comunicación es principalmente entre servicios controlados por la organización.
• Se necesitan contratos tipados y generación de clientes.
• Hay alto volumen de llamadas o mensajes.
• El streaming encaja con la operación.
• El equipo puede operar y observar la infraestructura requerida.

También pueden coexistir: REST en la frontera pública y gRPC entre servicios internos. Esa separación permite utilizar la herramienta adecuada para cada relación sin obligar a toda la plataforma a adoptar un único modelo.

Conclusión

gRPC existe para ofrecer un modelo de comunicación remota con contratos definidos, generación de código y streaming. Puede ser eficiente, pero no elimina los costes de red, consultas, dependencias ni diseño.

REST continúa siendo una opción sólida cuando la simplicidad y la interoperabilidad pesan más que las ventajas específicas de gRPC.

No migres porque Protocol Buffers parezca más rápido en teoría. Migra cuando el contrato, el patrón de comunicación o las mediciones demuestren que gRPC resuelve mejor una necesidad concreta.

En esta serie

1. REST: cómo diseñar y optimizar una API
2. REST vs GraphQL
3. gRPC vs REST (esta nota)
4. WebSockets, SSE y Webhooks
5. Caché y compresión
6. Benchmarks y decisiones de arquitectura

Referencias

• gRPC — Documentation
• gRPC — Performance Best Practices
• gRPC — Keepalive
• Protocol Buffers — Overview