gRPC

Resumen

gRPC es un framework de Remote Procedure Call (RPC) open source, inicialmente desarrollado por Google, que permite que un servicio llame a métodos de otro servicio como si fueran locales, con serialización binaria eficiente vía Protocol Buffers y transporte multiplexado sobre HTTP/2.

Importa cuando el rendimiento, la tipificación fuerte y la generación automática de código importan más que la legibilidad humana directa. Donde una API REST intercambia JSON legible por humanos sobre HTTP/1.1, gRPC intercambia protobuf binario sobre HTTP/2, con contratos definidos en archivos .proto que generan clientes y servidores tipados en múltiples lenguajes. Esto lo hace ideal para comunicación entre microservicios, sistemas de alta carga y entornos polyglot.

Alcance y supuestos

Este paquete cubre gRPC a nivel conceptual: definición de servicios, mensajes protobuf, HTTP/2 como transporte, generación de código, streaming y trade-offs frente a REST.

No cubre tutorial completo de protobuf, detalles de generación de código, features avanzados como autenticación, load balancing, interceptors, ni gRPC-web. Asume que entiendes HTTP, APIs, formatos de serialización y el concepto de contratos tipados entre servicios.

Modelo mental

Piensa en un contrato legal vs. una conversación informal. En una conversación informal (REST con JSON), dos personas hablan en lenguaje natural, se entienden por contexto y a veces hay malentendidos. En un contrato legal (gRPC con protobuf), cada término está definido con precisión, cada obligación está tipificada y no hay espacio para interpretación ambigua.

gRPC formaliza la comunicación entre servicios de la misma manera. Defines un archivo .proto que especifica exactamente qué servicios existen, qué métodos tienen, qué mensajes reciben y qué mensajes devuelven. Ese archivo es la única fuente de verdad. A partir de él, se genera código cliente y servidor en Go, Java, Python, C++, Node.js y otros lenguajes. Si el contrato cambia, la generación de código fuerza a ambos lados a actualizarse.

HTTP/2 aporta multiplexación: múltiples requests y responses comparten una misma conexión TCP sin bloquearse. Protobuf aporta serialización binaria compacta y rápida. El resultado es menor latencia, menos ancho de banda y contratos que no dependen de que un humano lea JSON correctamente.

Uso práctico

Usa gRPC cuando el rendimiento y la tipificación fuerte son prioritarios:

• ✅ Comunicación interna entre microservicios con alta carga y baja latencia.
• ✅ Entornos polyglot donde distintos servicios usan distintos lenguajes pero comparten contratos.
• ✅ Streaming bidireccional: logs, eventos, actualizaciones en tiempo real.
• ✅ APIs internas donde el contrato puede evolucionar de forma controlada y ambos lados se regeneran juntos.
• ❌ No es la mejor opción para APIs públicas consumidas desde navegadores sin gRPC-web.
• ❌ No uses gRPC si necesitas que humanos lean las respuestas con curl o un navegador; protobuf es binario.

Ejemplo trabajado: definir un servicio de pagos con gRPC

Donde REST define recursos y métodos HTTP, gRPC define un servicio y sus RPCs en un archivo .proto:

syntax = "proto3";

package payments;

service PaymentService {
  rpc CreatePayment (CreatePaymentRequest) returns (CreatePaymentResponse);
  rpc GetPayment (GetPaymentRequest) returns (Payment);
  rpc RefundPayment (RefundPaymentRequest) returns (Refund);
  rpc ListPayments (ListPaymentsRequest) returns (stream Payment);
}

message CreatePaymentRequest {
  int64 amount_cents = 1;
  string currency = 2;
  string customer_id = 3;
  string description = 4;
  string idempotency_key = 5;
}

message CreatePaymentResponse {
  string payment_id = 1;
  string status = 2;
  int64 created_at = 3;
}

message Payment {
  string payment_id = 1;
  string customer_id = 2;
  int64 amount_cents = 3;
  string currency = 4;
  string status = 5;
  int64 created_at = 6;
}

message GetPaymentRequest {
  string payment_id = 1;
}

message RefundPaymentRequest {
  string payment_id = 1;
  string reason = 2;
}

message Refund {
  string refund_id = 1;
  string payment_id = 2;
  int64 amount_cents = 3;
  string status = 4;
}

message ListPaymentsRequest {
  string customer_id = 1;
  int32 page_size = 2;
  string page_token = 3;
}

Lo que hace valioso este enfoque:

1. Contrato único: el .proto es la fuente de verdad para cliente y servidor.
2. Tipos fuertes: int64, string, enums — no hay ambigüedad sobre qué tipo es cada campo.
3. Campos numerados: los números de campo (1, 2, 3...) permiten evolución compatible hacia atrás.
4. Streaming nativo: stream Payment permite enviar resultados paginados sin polling.
5. Generación de código: un comando genera cliente y servidor en todos los lenguajes que necesites.

Antes de elegir gRPC, cinco preguntas:

1. ¿Ambos lados del contrato se regeneran juntos o necesitas consumidores que lean respuestas sin código generado?
2. ¿Necesitas streaming o las operaciones son request-response simples?
3. ¿El overhead de JSON y HTTP/1.1 es un problema medible o es prematuro optimizar?
4. ¿Tus consumidores incluyen navegadores? gRPC-web existe pero no es universal.
5. ¿El ecosistema de tooling (load balancers, proxies, monitoreo) soporta gRPC en tu infraestructura?

Evidencia

• gRPC, Introduction to gRPC presenta gRPC y Protocol Buffers como su IDL y formato de serialización, destacando generación de código, HTTP/2 y soporte multi-lenguaje.