Fundamentos de gRPC: contratos protobuf, streaming y dónde encaja

Qué es

La introducción a gRPC (citada) describe el modelo: un servicio y sus métodos se definen en un archivo .proto, protoc genera stubs de cliente e interfaces de servidor por lenguaje, y un cliente llama a un método en un servidor remoto como si fuera un objeto local; Protocol Buffers sirve por defecto tanto de lenguaje de definición de interfaz como de formato de mensaje. La página de conceptos básicos (citada) enumera cuatro tipos de método: unario, streaming del servidor, streaming del cliente y streaming bidireccional. Toda llamada puede llevar un deadline, tras el cual falla con DEADLINE_EXCEEDED; cualquiera de las partes puede cancelarla; los metadatos viajan como pares clave-valor junto con la llamada; y las llamadas terminan con un estado de un conjunto fijo (OK, NOT_FOUND, UNAVAILABLE y otros). Las preguntas frecuentes (citadas) indican que gRPC sigue la semántica de HTTP sobre HTTP/2, pero permite explícitamente streaming full-duplex, usa rutas estáticas para el despacho, y formaliza su propio conjunto de errores en lugar de los códigos de estado HTTP.

Por qué importa

Clientes tipados y generados en muchos lenguajes, más streaming y deadlines que se propagan a través de cadenas de llamadas, eliminan toda una clase de código de cliente escrito a mano y de errores de tiempo de espera. El precio son las cargas útiles binarias, HTTP/2 de extremo a extremo, y herramientas que curl simple no tiene.

Cómo aplicarlo

• Usar gRPC para llamadas internas entre servicios donde ambos extremos se generan a partir de los mismos archivos .proto, para streams (telemetría, suscripciones, conjuntos de resultados grandes) y para clientes móviles, donde las preguntas frecuentes citan ahorros de ancho de banda y de conexión.
• Establecer un deadline en cada llamada de cliente y pasar el deadline restante a las llamadas posteriores; hacer que los servidores comprueben la cancelación en bucles largos.
• Mapear los errores a los códigos de estado estándar y poner los detalles en el mensaje o en los detalles del error; no inventar códigos.
• Mantener los archivos .proto en un único paquete con una comprobación de compatibilidad en cada cambio; los números de campo son el contrato.
• Para navegadores, usar gRPC-Web, que las preguntas frecuentes describen como disponible con carácter general; para APIs públicas de socios, ofrecer JSON sobre HTTP en lugar de, o transcodificado desde, las definiciones gRPC.
• Confirmar que cada balanceador de carga y proxy de la ruta lleva HTTP/2 hasta el backend; gRPC lo necesita de extremo a extremo.

Trampas

Suponer que gRPC es automáticamente rápido: la serialización es barata, pero un diseño «hablador» sigue siendo hablador. Streams de larga duración que fijan una conexión a un solo backend y anulan el balanceo de carga. Reintentar INVALID_ARGUMENT igual que UNAVAILABLE porque el cliente no distingue los códigos reintentables. Exponer gRPC a integradores que solo disponen de herramientas HTTP.