gRPC para el programador .NET

Introducción

Ahora que ya sabemos un poco más sobre gRPC y su historia, ¿cómo se presenta este framework de cara al programador de .NET?.

gRPC soporta más de 10 lenguajes de programación entre los que se encuentra C#, por lo que podemos desarrollar nuestros servicios gRPC con C# como lenguaje de programación y .NET como plataforma de desarrollo.

Encontraremos más información sobre gRPC con C# en este enlace.

Sin embargo, aunque parezca que desde hace relativamente poco se ha puesto de moda gRPC para .NET, la realidad es que se podía utilizar hace ya tiempo en .NET.

 

gRPC para .NET Framework y .NET Core

El caso es que podemos utilizar gRPC para entornos Mac OS X y Linux a través de Mono, y también podemos utilizar .NET Framework 4.5.x para entornos Windows.

De igual forma, podemos utilizar .NET Core para desarrollar aplicaciones gRPC.

Toda esta información la encontraremos en este enlace de GitHub.

Respecto al paquete NuGet básico necesario, deberíamos apoyarnos en el paquete gRPC e instalar también Grpc.Tools para poder trabajar con el compilador Protocol Buffer (protobuf).

Como curiosidad, comentar que el compilador de Protocol Buffer (protobuf) lo encontraremos en GitHub en este enlace.
Por su parte, el paquete Nuget Google.Protobuf lo encontraremos aquí.

Si tienes más curiosidad, puedes encontrar un sencillo ejemplo de .NET Core 2.1 en este enlace.
Encontrarás algún ejemplo más en este otro enlace.

 

gRPC para ASP.NET Core 3

Llegados a este punto, conviene mencionar que Microsoft está impulsando la capacidad del desarrollo de servicios a través de gRPC dentro de ASP.NET Core 3.0.
¿Qué tiene entonces ASP.NET Core 3 que no tenía antes?.

La implementación anterior de Google se basa en la librería nativa escrita en C (gRPC C-Core).

Microsoft, como sabes, trabaja activamente en ASP.NET Core 3 (en versión preview aún).
Dentro de este trabajo, trata de colaborar con Google con respecto a gRPC y focaliza sus esfuerzos en implementarlo de forma completamente manejada y basada en el servidor HTTP de Kestrel y la pila de ASP.NET Core.
El objetivo de Microsoft es comportarse con gRPC lo más parecido a como lo hacen lenguajes como Java y Go que aglutinan una de sus capas en una sola resolviendo algunas problemáticas que se pueden dar.

Otra de las intenciones de Microsoft es unificar y utilizar todas las opciones del protocolo HTTP/2 para que los desarrolladores de ASP.NET Core 3.x se beneficien de sus ventajas y las puedan aplicar a sus servicios.

Quizás en este punto te preguntes como lo hizo un usuario de Twitter que le preguntó a David Fowler sobre la ventaja de correr nuestros servicios en la parte superior de ASP.NET Core en lugar de hacerlo en Grpc.Core.Server.

Aquí la conversación dónde luego intervino otro usuario de Twitter:

Por otro lado, aparte de todo esto y si te has dado cuenta ya (sino lo aclaro), no estoy nombrando en ningún momento (intencionadamente) la palabra microservicios, y es que mucha gente reduce el uso de gRPC a microservicios, pero la realidad es que aunque se pueda aplicar a ellos, debemos evitar malos entendidos y verlo de forma amplia, global y válida de establecer comunicaciones entre clientes o consumidores de un servicio, y del servicio en sí, y no sólo para un ámbito enfocado a microservicios.

 

¿REST o gRPC?

Otra de las discusiones generales que aparecen en la mesa cuando hablamos de gRPC es qué pasará con REST.

En ASP.NET Core podemos desarrollar nuestras propias APIs con ASP.NET Core Web Api.
¿Es acaso gRPC un sustituto de ASP.NET Core Web Api?.

La respuesta es tajante. NO.

Simplemente tenemos dos mecanismos o dos formas para desarrollar nuestros propios servicios.
El primero de ellos basado en ASP.NET Core Web Api, y el otro a través de gRPC.

De forma general, me atrevo a afirmar que desarrollar una solución en ASP.NET Core Web Api es más sencilla o rápida que hacerlo en gRPC.
Sin embargo y por norma general también, recibir datos y enviar respuestas en gRPC mejora el rendimiento que ofrece REST (entre 5 y 10 veces aproximadamente).

El uso del protocolo HTTP/2 (en lugar de HTTP/1.x como en REST) y el hecho de no utilizar datos planos como JSON, ayudan en buena parte a que la balanza de rendimiento se incline a favor de gRPC.

Los payloads en JSON son de forma general legibles, lo cual facilita su rápida lectura e interpretación, pero demasiado grandes a veces.
Los payloads con Protobuf son binarios, y aunque no sean legibles en una rápida lectura, son más pequeños y por lo tanto consume menos recursos de red además de ser enviados y recibidos más rápidamente.

HTTP/2 por su parte, posee la característica principal de manejar múltiples conexiones, a excepción de REST que sólo puede manejar 1 por llamada.
gRPC nos permite también comunicarnos bidireccionalmente entre cliente y servicio.

Finalmente, es posible agregar a gRPC diferentes plugins para traceo, logging o monitoreo por ejemplo.

Para más información sobre algunas comparaciones entre HTTP API con JSON y gRPC, te invito a visitar este enlace de Microsoft al respecto.

Para ver algunas comparaciones más, te indico una imagen comparativa:

Por si tienes problemas para ver esta imagen, puedes acceder a ello directamente aquí.

 

gRPC everywhere

Una de las características más destacables de gRPC es el hecho de ser multiplataforma.
Podríamos disponer de un cliente programado en un lenguaje de programación concreto (de los más de 10 soportados anteriormente comentados) y un servidor en otro lenguaje o tecnología.

Incluso por razones estratégicas u otras diferentes, podríamos llegar a portar en un momento dado una de esas partes de un lenguaje de programación a otro.

Esto es o puede llegar a ser algo muy atractivo para las empresas y sus equipos de desarrollo.

Aunque ya he comentado algunas cosas con respecto a HTTP/2, te sugiero leer esta entrada explicativa y esta otra muy interesante también.

 

Otras características destacables de gRPC

El hecho de apoyarse en el protocolo HTTP/2 aporta ventajas adicionales como el streaming bidireccional, la compresión de cabeceras, y el multiplexing y control de flujo o congestión para conexiones simples TCP, ofreciendo un alto rendimiento.

Por lo anteriormente comentado y más, gRPC es asíncrono por naturaleza.
Cabe recordar que las redes son inherentemente asíncronas.
Recordemos que el objetivo principal de la asincronía es no bloquear el hilo.

La reconexión en conexiones con problemas es automática, y es posible propagar los errores y cancelación.

Aunque lo he comentado en otra entrada, no está de más recordar que gRPC es extensible.
Podemos extenderlo con traceo y logging, monitorización, balanceo de carga o load balancing, chequeo de salud o health checking, descubrimiento de servicios o service discovery, autenticación y seguridad, proxies, etc.

También es posible medir los niveles de calidad de servicio (QoS).

La instalación y uso de gRPC es tremendamente sencilla y rápida, si bien creo que (y puede ser que diga esto basándome en mi costumbre) hacerlo con ASP.NET Core Web Api es aún más rápido y sencillo.

 

Resumen de los beneficios de gRPC

Para recordar de forma rápida y sencilla los beneficios principales que nos ofrece gRPC, me he inventado una sigla que los engloba a todos.

CPM – Compatibility, Performance and Manteinance.

Enfocado a la compatibility o compatibilidad porque es multiplataforma, multilenguaje y evita los breaking changes (eso no significa que no los pueda haber, porque nada es infalible).

Enfocado al performance o rendimiento porque maneja las conexiones de red permitiendo múltiples llamadas por conexión, permite la transmisión rápida de datos binarios, y mejora el uso y consumo de recursos (CPU).

Enfocado al mantenimiento porque permite extender o utilizar plugins para obtener datos de traceo, logging y monitorización entre otros.

En próximas entradas entraremos en detallar las partes principales de gRPC y lo que debes conocer y dominar de él.

 

Happy Coding!