gRPC: contratos tipados y transporte eficiente entre servicios

  • arquitectura

Una aplicación de transporte puede necesitar precio, conductor, ubicación y notificaciones para completar una acción. Entre servicios internos aparecen muchas llamadas pequeñas y repetidas. Allí importan el costo de serializar mensajes, las conexiones, la concurrencia y la compatibilidad entre lenguajes.

HTTP, RPC y serialización son capas distintas

gRPC es un framework de llamadas a procedimientos remotos que normalmente utiliza HTTP/2 y Protocol Buffers. No es una alternativa a HTTP en el mismo nivel. Una API de estilo REST también puede viajar por HTTP/2; del mismo modo, una conexión HTTP/1.1 puede reutilizarse. No es correcto atribuir a toda API HTTP una nueva negociación TCP y TLS por cada petición.

Qué aporta HTTP/2

HTTP/2 permite multiplexar streams en una conexión, evitando dedicar una conexión distinta a cada intercambio concurrente. La compresión de cabeceras reduce información repetida. Esto no elimina toda espera: los streams comparten recursos y, sobre TCP, una pérdida de paquetes puede afectar su progreso. Un canal gRPC abstrae las conexiones y su gestión; no significa necesariamente una única conexión física durante toda su vida.

El contrato genera código, Protobuf representa los datos y HTTP/2 transporta streams. No son alternativas en la misma capa.
El contrato genera código, Protobuf representa los datos y HTTP/2 transporta streams. No son alternativas en la misma capa.

Qué aporta Protocol Buffers

Un archivo .proto define mensajes y métodos. A partir del contrato se generan clientes y estructuras del servidor para distintos lenguajes. Protocol Buffers codifica datos en binario con identificadores de campo, evitando repetir nombres como en JSON. Suele reducir tamaño y trabajo de procesamiento en escenarios apropiados, pero el resultado debe medirse.

Protocol Buffers · contrato ilustrativo
syntax = "proto3";
service Conductores {
  rpc Consultar (Consulta) returns (Conductor);
}
message Consulta { string id = 1; }
message Conductor {
  string id = 1;
  string nombre = 2;
}

Más que petición y respuesta

gRPC contempla llamadas unarias, streaming del servidor, streaming del cliente y streaming bidireccional. También incluye estados, metadatos, cancelación y plazos. Un cliente debe fijar un deadline acorde con el presupuesto total de la operación para que un servicio lento no retenga recursos indefinidamente.

El contrato tipado no garantiza compatibilidad si se cambia sin disciplina. Al evolucionar mensajes hay que conservar identificadores y no reutilizar los campos eliminados para significados incompatibles. En navegadores puede requerirse gRPC-Web u otra adaptación.

Es una opción útil para comunicación interna frecuente, streaming y equipos que necesitan contratos compartidos. Una API HTTP con JSON puede facilitar integraciones públicas y depuración manual. El criterio es la carga, el ecosistema y el costo operativo, no una superioridad universal de un formato.

Referencias