Las claves verificadas
- gRPC permite invocar métodos remotos con código generado a partir de un contrato. Ver evidencia
- Protocol Buffers define mensajes tipados y reglas de compatibilidad para evolucionar campos. Ver evidencia
- HTTP/2 puede transportar llamadas gRPC multiplexadas y streams. Ver evidencia
- El diseño de APIs debe definir errores, plazos, autenticación y evolución del contrato. Ver evidencia
Qué es gRPC
gRPC es un marco para que un cliente invoque métodos de un servicio remoto como si fueran funciones locales. El contrato se define en archivos Protocol Buffers y las herramientas generan código para cliente y servidor. La comunicación puede incluir llamadas simples o streams, según el método que se declare.
También puede servirte: Server-Sent Events: qué son y cuándo convienen
La implementación habitual usa HTTP/2 para transportar mensajes y multiplexar llamadas. Protocol Buffers describe los tipos y serializa los datos en un formato compacto. El contrato tipado ayuda a detectar cambios incompatibles antes de que lleguen a producción, siempre que el equipo mantenga las reglas de evolución.
Cuándo conviene usar gRPC
gRPC encaja en servicios internos que intercambian mensajes estructurados, necesitan streaming o tienen clientes generados en varios lenguajes. Un contrato compartido puede reducir código repetido entre equipos y hacer explícitos los estados de error, los plazos y los metadatos.
Para una API pública consumida directamente desde cualquier navegador, HTTP con JSON suele tener menos fricción. gRPC-Web puede acercar el modelo al navegador, pero agrega una capa y requisitos de infraestructura. La decisión depende de quién consume el servicio, qué latencia se necesita y cuánto importa el contrato tipado.
Guía para elegir gRPC frente a HTTP tradicional
Empezá por el contrato: declarà métodos, mensajes, códigos de error y deadlines en el archivo .proto. Reservá números de campos que se eliminen y agregá campos opcionales de manera compatible. No cambies el tipo de un campo ni reutilices su número para otro significado.
Definí autenticación, TLS, límites de tamaño, timeouts y política de reintentos antes de exponer el servicio. Instrumentá cliente y servidor con trazas y métricas que incluyan método, código de estado y latencia, sin registrar datos sensibles del mensaje.
Límites y errores frecuentes
Un contrato tipado no resuelve una mala frontera de servicio. Métodos demasiado grandes, streams sin límite o reintentos sin deadline pueden consumir conexiones y hacer difícil recuperar una falla. Los clientes deben cancelar llamadas que ya no necesitan y el servidor debe liberar recursos cuando recibe esa cancelación.
La compatibilidad requiere disciplina: documentá deprecaciones, mantené clientes durante la migración y probá versiones mezcladas. Si el servicio necesita cache HTTP, enlaces fáciles de inspeccionar o consumo desde herramientas simples, una API REST puede ser una elección más práctica.
Qué aporta VisteEsto: Nuestro trabajo en esta nota
VisteEsto convierte gRPC en una decisión operativa: consumidor, contrato, streaming, deadlines, evolución de campos, observabilidad y compatibilidad pública.
Fuentes, actualizaciones y metodología 3 fuentes
Fuentes consultadas
- Fuente primariagRPC: Introduction
- Fuente primariaProtocol Buffers: Overview
- Fuente primariaGoogle Cloud: API design guide
Historial de actualización
- Publicación inicial basada en la documentación oficial de gRPC, Protocol Buffers y la guía de diseño de APIs de Google Cloud.
Cómo elaboramos esta nota
Definimos la consulta principal “gRPC qué es cuándo conviene usarlo”, contrastamos los datos con 3 fuentes —3 primarias— y revisamos contexto, imágenes y posibles vacíos antes de publicar. Conocé nuestra política editorial y de verificación.
