En este post exploramos gRPC y Protobuf para microservicios, una alternativa eficiente al protocolo REST que mejora el rendimiento y la comunicación entre servicios distribuidos.
¿REST es la única opción en arquitectura de microservicios?
Si te dedicas al desarrollo software, independientemente de la tecnología, te habrás cruzado con el protocolo API Rest, muy extendido a día de hoy.
Atrás quedaron los tiempos de una arquitectura basada en un monolito, pues ahora abrazamos arquitectura orientada a microservicios (o, más allá, a eventos).
API Rest es, posiblemente, el protocolo de comunicación (basado en arquitectura REST) más maduro y fuerte del mercado pero, ¿es la única opción? ¿Existen más opciones en el mercado? Claro que sí.
Hoy veremos en detalle la «nueva» versión de RPC (Remote Process Control) adquirida por Google y la introducción de nuevos elementos como los Protocol Buffers, aplicados al desarrollo de microservicios.
¿Qué es gRPC?
Empecemos por lo básico, ¿te suena RPC? Un más que conocido (y en desuso) protocolo de comunicación en remoto.
Pues bien, Google adquirió esta tecnología y la llamó gRPC (la «g» de Google). gRPC es la implementación de llamadas a procesos remoto. Pero además, Google añadió algunas ventajas como el uso de Protocol Buffers (que veremos en el siguiente apartado) y cambiar la capa de transporte a HTTP/2.
Ventajas de gRPC
- Multiplexación: poder realizar una única conexión para múltiples llamadas
- Compresión de cabeceras: toda la información se envía en un único bloque, mejorando tiempos de respuesta
- Permitir que el servidor envíe información considerada útil al cliente, mejorando el rendimiento
- Formato binario: permite mejorar la eficiencia al estar la información compactada
¿Qué es un Protocol Buffer?
Un Protocol Buffer es un mecanismo para la serialización de datos estructurados independiente de lenguajes de programación y plataforma. Esto nos permite definir la estructura de la comunicación. A efectos prácticos es el contrato, siendo un equivalente la documentación Swagger generada de una API Rest. La gran ventaja es que nos permite definirlo antes y posteriormente generar la implementación.
Ventajas clave
Otra ventaja es el uso de tipado fuerte, es decir, si definimos como dato de entrada un String, en la propia implementación ya se tendrá en cuenta. Así, no tendremos que preparar cliente o servidor para inferir cómo nos llega la información y adecuarla a nuestra implementación. Puedes encontrar más información aquí sobre los tipos disponibles.
Resaltar de nuevo que este documento (nuestro fichero protobuf) es agnóstico del lenguaje utilizado, ya que existen librerías para implementarlo independientemente de la tecnología utilizada. Además, la serialización es binaria, formato (en principio) no legible por humanos.
Desarrollo de microservicios con gRPC y Protocol Buffers (con Spring Boot)
A continuación, vamos a explicar como definir un fichero proto y unos sencillos pasos iniciales para poder implementarlo mediante Spring Boot.
Ejemplo de archivo .proto
Para empezar tendremos que crear un fichero con extensión .proto y ubicar en el source de nuestro proyecto (ya sea cliente o servidor). Para nuestro ejemplo, simplemente añadiremos la información necesaria para los datos de entrada y salida y métodos para gestionar la petición y la respuesta. Este fichero tiene la siguiente estructura, explicamos punto por punto:
syntax = "proto3"; (1)
package com.profile.blog.entry;
message BlogEntryRequest { (2)
string title = 1; (3)
string author = 2;
string topic = 3;
}
message BlogEntryResponse { (4)
string blogEntry = 1;
}
service BlogEntryService {
rpc getBlogEntry(BlogEntryRequest) returns (BlogEntryResponse) (5)
} (1) Declaración de la versión de protobuf que estamos usando
(2) Definición de la estructura de datos de entrada
(3) Ejemplo de campo que debe venir en request y tipo. El número define el orden
(4) Definición de la estructura de datos de salida
(5) Definición de servicios que se realizan
Dependencias necesarias
Este fichero normalmente se guarda en una carpeta llamada «proto» que cuelga de nuestro directorio principal «src/main/java». En el caso de un microservicio con Spring Boot, deberemos importar las siguientes dependencias en nuestro fichero pom.xml de io.grpc, siempre intentando tener la última versión:
- grpc-netty-shaded
- grpc-protobuf
- grpc-stub
- grpc-testing
Implementación del servicio
Una vez que ejecutemos el comando maven clean install, generará los ficheros necesarios para poder realizar la comunicación. En nuestro ejemplo, nuestra clase resultará algo como el siguiente fragmento de código:
@GrpcService
public class BlogEntryServiceImpl extends BlogEntryServiceGrpc.BlogEntryServiceImplBase{
@Override
public void getBlogEntry(BlogEntryRequest request, StreamObserver<BlogEntryResponse> responseObserver){
String blogEntry = (...llamada a método que consulta base de datos y nos trae el texto de un post...)
BlogEntryResponse response = BlogEntryResponse.newBuilder()
.setBlogEntry(blogEntry)
.build();
responseObserver.onNext(response);
responseObserver.onCompleted();
}
}Podemos ver que hemos implementado el método getBlogEntry que anteriormente se había definido en el fichero proto (en este caso, por simplificar, simulamos una llamada a otro método donde según parámetros de entradas encuentra el contenido de un post y lo devuelve). Especial atención a la anotación @GrpcService porque sustituye a la conocida @Service.
¿Cuándo usar gRPC y Protobuf para microservicios?
Ya hemos visto que el uso de gRPC nos aporta sencillez y, sobre todo, flexibilidad, pero también, al estar basado en HTTP/2, mejora el rendimiento respecto al uso de REST y JSON. gRPC y Protobuf para microservicios puede ser una excelente opción en escenarios donde la comunicación entre servicios internos o externos requiera mayor eficiencia, baja latencia y un flujo de datos muy alto. También es útil en entornos donde conviven distintas tecnologías que deben comunicarse entre sí.
Pero ¡ojo! Existe de momento un soporte limitado en navegadores, por ello hay que decidir bien los casos de uso.
Sin embargo, y desde mi punto de vista, gRPC no sustituye a REST. Es una buena alternativa a valorar que, según la casuística, puede venirnos bien o no, pero desde luego, debemos conocer que existe y tenerla bajo radar.
Déjanos tu comentario en nuestras redes sociales y síguenos en nuestro canal de YouTube para mantenerte al día sobre lo último en programación.