¿Qué es gRPC?

Es un framework de llamadas a procedimientos remotos (RPC) de código abierto desarrollado por Google que permite la creación de aplicaciones distribuidas de alto rendimiento. Utiliza el protocolo HTTP/2 para una comunicación eficiente y puede intercambiar datos binarios utilizando Protocol Buffers, lo que resulta en mensajes más pequeños y rápidos que la serialización de texto.

Cómo funciona

Definición de servicios: Se utilizan archivos de definición (.proto) para describir los servicios y los formatos de los mensajes de solicitud y respuesta.
Generación de código: gRPC genera automáticamente bibliotecas cliente en diversos lenguajes de programación basándose en esta definición, simplificando el trabajo del desarrollador.
Llamadas RPC: El cliente puede llamar a funciones en el servidor remoto como si fueran métodos locales, y el servidor ejecuta la función y devuelve el resultado.
Cancelación de solicitudes: gRPC permite la cancelación de solicitudes en curso por parte del cliente. Esto es útil en escenarios donde una operación ya no es necesaria (por ejemplo, el usuario cierra una ventana) o cuando se ha excedido un tiempo de espera. La cancelación se propaga al servidor, que puede detener el procesamiento y liberar recursos.
Streaming: gRPC soporta cuatro tipos de llamadas de streaming:
- Unary RPC: Cliente envía una solicitud, servidor envía una respuesta (el modelo RPC tradicional).
- Server-side streaming RPC: Cliente envía una solicitud, servidor envía una secuencia de respuestas.
- Client-side streaming RPC: Cliente envía una secuencia de solicitudes, el servidor envía una respuesta única.
- Bidirectional streaming RPC: Cliente y servidor envían secuencias de mensajes de forma independiente y simultánea. Esto es ideal para comunicaciones interactivas o de larga duración.

Protocolo de transporte

gRPC utiliza HTTP/2, lo que permite comunicaciones bidireccionales y el envío de múltiples solicitudes a través de una única conexión. HTTP/2 mejora HTTP/1.1 principalmente a través de la multiplexación, que permite múltiples solicitudes y respuestas en una sola conexión; utiliza un protocolo binario para una transmisión de datos más eficiente; introduce la compresión de encabezados para reducir el tamaño de los datos; permite la priorización de recursos; y posibilita el Server Push, donde el servidor envía contenido no solicitado de forma proactiva.

Figura 1. gRPC para un eShop en contenedores

Serialización en APIs Tradicionales vs. gRPC

En las APIs tradicionales basadas en REST, la serialización de datos comúnmente se realiza utilizando formatos basados en texto como JSON (JavaScript Object Notation) o XML (Extensible Markup Language). Estos formatos son legibles por humanos y fáciles de implementar, pero tienen algunas desventajas:

Tamaño de los mensajes: Los formatos basados en texto suelen ser más verbosos, lo que resulta en mensajes más grandes que requieren más ancho de banda para su transmisión.
Eficiencia de parsing: El procesamiento (parsing) de JSON o XML en el lado del cliente y del servidor puede ser más lento debido a la necesidad de analizar cadenas de texto y convertirlas a estructuras de datos internas.
Tipado: Aunque JSON y XML pueden representar tipos de datos, no imponen un esquema estricto de forma nativa, lo que puede llevar a errores de tipo en tiempo de ejecución si no se gestiona cuidadosamente.

En contraste, gRPC utiliza Protocol Buffers (Protobuf) para la serialización de datos. Protobuf es un mecanismo de serialización de datos binarios que ofrece varias ventajas clave:

Tamaño compacto: Los mensajes serializados con Protobuf son significativamente más pequeños que sus equivalentes en JSON o XML. Esto se debe a su naturaleza binaria y a la forma eficiente en que codifica los datos, lo que reduce el consumo de ancho de banda.
Rendimiento: La serialización y deserialización de Protobuf es mucho más rápida que la de los formatos basados en texto, ya que implica operaciones binarias directas en lugar de análisis de texto. Esto es crucial para aplicaciones de alta concurrencia y baja latencia.
Esquema estricto: Protobuf requiere la definición de un esquema (.proto) para los mensajes. Este esquema asegura un tipado fuerte y coherencia de los datos entre el cliente y el servidor, lo que reduce la probabilidad de errores y facilita la evolución de las APIs.
Generación de código: A partir del archivo .proto, gRPC genera automáticamente clases de datos en diversos lenguajes de programación. Esto elimina la necesidad de escribir código de serialización/deserialización manual y garantiza que los datos se manejen de manera consistente en todas las plataformas.

Beneficios clave

Alto rendimiento: La serialización binaria de Protocol Buffers reduce el tamaño de los mensajes y la velocidad de transmisión.
Mayor velocidad que otros protocolos de conexión como HTTP REST.

Casos de uso

Comunicación entre microservicios en arquitecturas nativas de la nube.
Entornos que requieren baja latencia y alto rendimiento.
Aplicaciones que necesitan soporte para diferentes lenguajes de programación.
Facilita la comunicación entre servicios escritos en diferentes lenguajes de programación.
Permite que tanto el cliente como el servidor envíen múltiples mensajes de forma simultánea a través de una sola conexión.
Abstrae las complejidades de la comunicación de bajo nivel, permitiendo a los desarrolladores centrarse en la lógica de la aplicación.

Implementación Básica de gRPC

Para ilustrar cómo funciona gRPC, consideremos un servicio simple de "Saludo".

Definición del servicio (.proto):

syntax = "proto3";
package greet;
service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply) {}
}
message HelloRequest {
  string name = 1;
}
message HelloReply {
  string message = 1;
}

Este archivo define un servicio Greeter con un método SayHello que toma un HelloRequest y devuelve un HelloReply.

Generación de código:

Con las herramientas de protoc y el plugin de gRPC para tu lenguaje, se generan automáticamente los stubs del cliente y del servidor. Por ejemplo, para Python:

python -m grpc_tools.protoc -I. --python_out=. --grpc_python_out=. greet.proto

Implementación del servidor (Python):

import grpc
from concurrent import futures
import greet_pb2
import greet_pb2_grpc
class GreeterServicer(greet_pb2_grpc.GreeterServicer):
    def SayHello(self, request, context):
        return greet_pb2.HelloReply(message=f"Hello, {request.name}!")
def serve():
    server = grpc.server(futures.ThreadPoolExecutor(max_workers=10))
    greet_pb2_grpc.add_GreeterServicer_to_server(GreeterServicer(), server)
    server.add_insecure_port('[::]:50051')
    server.start()
    server.wait_for_termination()
if __name__ == '__main__':
    serve()

El servidor implementa el método SayHello definido en el .proto.

Implementación del cliente (Python):

import grpc
import greet_pb2
import greet_pb2_grpc
def run():
    with grpc.insecure_channel('localhost:50051') as channel:
        stub = greet_pb2_grpc.GreeterStub(channel)
        response = stub.SayHello(greet_pb2.HelloRequest(name='Andres'))
    print(f"Greeter client received: {response.message}")
if __name__ == '__main__':
    run()

El cliente crea un stub y llama al método SayHello como si fuera una función local.

Comparación entre APIs Tradicionales (REST) y gRPC

Característica	APIs Tradicionales (REST)	gRPC
Protocolo	HTTP/1.1 (principalmente)	HTTP/2
Formato de datos	JSON, XML (basado en texto)	Protocol Buffers (binario)
Rendimiento	Generalmente menor debido a la serialización de texto y HTTP/1.1	Mayor debido a la serialización binaria y las características de HTTP/2
Tamaño del mensaje	Más grandes (verbosos)	Más pequeños (compactos)
Tipado	Débil (esquema opcional con OpenAPI/Swagger)	Fuerte (esquema estricto con Protocol Buffers)
Generación de código	Manual o con herramientas de terceros	Automática (stubs de cliente/servidor)
Streaming	Limitado (generalmente unidireccional con WebSockets)	Soporte nativo para cuatro tipos de streaming (unidireccional, bidireccional)
Compatibilidad	Amplia compatibilidad con navegadores y herramientas	Requiere bibliotecas cliente/servidor específicas
Legibilidad	Alta (JSON/XML son legibles por humanos)	Baja (Protocol Buffers son binarios)

Cuándo usar cada uno:

Usa APIs Tradicionales (REST) cuando:

Necesitas una API pública que sea fácilmente consumible por navegadores web y una amplia gama de clientes.
La legibilidad de los mensajes es una prioridad (para depuración o integración manual).
No se requiere un rendimiento extremadamente alto o baja latencia.
El ecosistema de herramientas existente para REST es suficiente para tus necesidades.
Estás construyendo servicios que serán consumidos por aplicaciones web tradicionales o móviles donde la simplicidad de HTTP/JSON es beneficiosa.

Usa gRPC cuando:

Estás construyendo microservicios internos donde el rendimiento y la baja latencia son críticos.
Necesitas una comunicación eficiente entre servicios escritos en diferentes lenguajes de programación.
El streaming de datos (unidireccional o bidireccional) es un requisito fundamental.
La definición de un esquema estricto y la generación automática de código son beneficiosas para la mantenibilidad y la prevención de errores.
El tamaño del mensaje y el uso del ancho de banda son consideraciones importantes.
Estás desarrollando aplicaciones en entornos de nube nativa donde la optimización de la comunicación es clave.

Conclusiones

gRPC se posiciona como una tecnología fundamental para el desarrollo de aplicaciones distribuidas de alto rendimiento, especialmente en arquitecturas de microservicios. Su diseño, que se apoya en HTTP/2 y Protocol Buffers, ofrece ventajas significativas sobre las APIs tradicionales basadas en REST, particularmente en escenarios donde la eficiencia, la baja latencia y la comunicación entre servicios heterogéneos son cruciales.

Te recomendamos en video

Desarrollo de API para empresa de telecomunicaciones

Mira todos los servicios que ofrecemos