La mayoría de las aplicaciones de software necesitan poder conectarse a otro código por varias razones. Esto puede ser cualquier cosa, desde la integración hasta la adición de nuevas funcionalidades. Para asegurarse de que el software puede enlazarse con otras aplicaciones y para garantizar su integración en otros programas, los desarrolladores utilizan las API. Por eso es necesaria una interfaz de programación de aplicaciones para la mayoría del software. Gracias a su papel de puente entre sistemas, las APIs permiten a las personas acceder a una variedad de servicios web. Por lo tanto, es importante elegir la tecnología adecuada para ofrecer una API a su proyecto.
Cualquier organización que quiera compartir su aplicación o plataforma con sus usuarios necesita utilizar APIs. Hay muchas formas de desarrollar y perfeccionar las APIs para que se adapten perfectamente a su aplicación. Uno de los últimos métodos que los programadores están utilizando para diseñar APIs es gRPC. Veamos qué es gRPC y sus ventajas e inconvenientes.
¿Qué es gRPC?
gRPC significa Google Remote Procedure Call. gRPC es un marco RPC de código abierto que se utiliza para crear APIs escalables y rápidas. Permite el desarrollo de sistemas en red y la comunicación abierta entre las aplicaciones cliente y servidor de gRPC. gRPC ha sido adoptado por varias empresas tecnológicas de primer nivel, como Google, IBM y Netflix, entre otras. El marco de trabajo de gRPC depende de pilas de tecnología de vanguardia como HTTP/2, búferes de protocolo y más para una óptima protección de la API, llamadas a procedimientos remotos de alto rendimiento y escalabilidad.
¿Qué es RPC?
RPC y REST - Representational State Transfer- han sido históricamente dos enfoques distintos para construir APIs. Además, protocolos como SOAP y GraphQL también se utilizan para este fin. Las llamadas a procedimientos remotos permiten escribir software como si se fuera a ejecutar localmente, aunque se ejecute en un dispositivo diferente.
Son el marco más utilizado para diseñar APIs. A diferencia de la típica llamada al protocolo HTTP, una RPC emplea una llamada a una función como método principal de interacción entre el cliente y el servidor. RPC es una técnica productiva para crear APIs, ya que los intercambios son sencillos y los contenidos son ligeros. Los servicios gRPC también imitan esta arquitectura de comunicación. RPC emplea IDL - Interface Definition Language para contratar el tipo de datos y los métodos que serán invocados. Los servicios gRPC adoptados a partir de los RPC se han hecho muy populares en los últimos años.
¿Por qué se han desarrollado los servicios gRPC?
A medida que más empresas abren canales de integración, se hace más difícil vincular estos programas. RPC Las API son difíciles de integrar y su distribución es arriesgada porque pueden revelar detalles internos. Se desarrollan en muchos lenguajes de programación y están estrechamente ligadas al marco subyacente.
Este problema se abordó y la accesibilidad de las APIs aumentó cuando se lanzó la API REST en el año 2000. En concreto, proporcionó a los usuarios una forma coherente de recuperar información de forma indirecta a través de activos mediante técnicas HTTP estándar como GET, PUT, POST, y otras. La principal distinción de RPC con respecto a REST API es que con RPC se abordan los procesos, pero no es fácil prever cuáles podrían ser los procesos en varios sistemas.
El REST API no pudo sustituir completamente al sencillo y ligero RPC porque producía una gran cantidad de metadatos, aunque ofrecía un formato mejorado para tratar muchas aplicaciones. Esto dio lugar a la eventual aparición de los servicios GraphQL de Facebook y gRPC de Google.
Google construyó gRPC en 2015 como una adición al marco RPC para conectar numerosas arquitecturas de microservicios realizadas con diversas técnicas. gRPC estaba originalmente muy relacionado con la infraestructura central de Google, pero finalmente se hizo de código abierto y se estandarizó para su uso por el público en general.
Visión general de los conceptos de gRPC
La utilización de tecnologías de vanguardia, que tienen un alto rendimiento sobre JSON y XML y ofrecen una mayor integridad de la API, es responsable de la creación y la popularidad de gRPC. Algunos de los conceptos de gRPC que debe conocer son
Búferes de protocolo
Los búferes de protocolo, también conocidos como Protobuf, son estándares de serialización o deserialización que simplifican la definición de aplicaciones y realizan automáticamente la generación de código de las bibliotecas de clientes. La versión más reciente, proto3, es más sencilla de utilizar y ofrece las capacidades más novedosas para gRPC.
.Proto Los archivos habilitan los servicios gRPC y las comunicaciones entre los clientes gRPC y los mensajes del servidor. El archivo .proto es cargado en memoria en la ejecución por el compilador Protobuf - protoc. Este compilador construye aplicaciones de cliente gRPC y de servidor gRPC que emplean la estructura en memoria para serializar y deserializar los datos binarios. Cada comunicación se envía y recibe entre el usuario y el servicio remoto siguiendo la generación de código en gRPC.
Como los datos se traducen a una forma binaria y las señales codificadas son más pequeñas, el análisis sintáctico con Protobuf utiliza menos potencia de CPU para gRPC. Por lo tanto, incluso en ordenadores con un CPU más débil, como los teléfonos móviles, los mensajes se envían más rápidamente con gRPC.
HTTP/2
El servicio gRPC está construido sobre HTTP/2, la versión de HTTP/1.1 que tiene menos limitaciones. Aunque funciona con el protocolo HTTP más antiguo, HTTP/2 tiene varias características sofisticadas para gRPC. Esto incluye una capa de encuadre binario, que divide cada consulta y respuesta de HTTP/2 en mensajes más pequeños y los encuadra en formato binario para mejorar la entrega del mensaje. Además, gRPC soporta múltiples peticiones y respuestas del cliente y del servidor gRPC en flujo bidireccional full-duplex.
HTTP/2 cuenta con un método de control de flujo que permite un control preciso de la RAM necesaria para almacenar paquetes en vuelo. También ofrece compresión de cabeceras para los servicios gRPC. Todo en HTTP/2 se encripta antes de la transmisión, incluso las cabeceras, lo que proporciona un alto rendimiento en las llamadas a procedimientos remotos. gRPC proporciona un procesamiento tanto asíncrono como síncrono con HTTP/2, permitiendo la ejecución de varios tipos de RPC interactivos y en streaming.
Con la ayuda de todas estas características de HTTP/2, los servicios gRPC pueden utilizar menos recursos, lo que conduce a tiempos de respuesta más rápidos entre las aplicaciones basadas en la nube y los servicios gRPC y una mayor duración de la batería para los clientes gRPC que operan en dispositivos móviles.
Streaming
Una idea crucial que soporta gRPC es el streaming, que permite la ejecución de varios procesos dentro de una única solicitud. gRPC hace esto posible a través de la función de multiplexación de HTTP/2, que permite enviar o recibir varias respuestas o solicitudes simultáneamente a través de una conexión TCP - Transmission Control Protocol -. Los principales formatos de streaming son los RPCs server-streaming, client-streaming RPCs, y bidirectional-streaming RPCs.
Canales
A diferencia de los streams de HTTP/2, que permiten numerosos streams simultáneos en una sola conexión de solicitud, un canal con gRPC soporta múltiples streams continuos a través de múltiples solicitudes. Se emplean para construir un stub de cliente y dan un mecanismo para enlazar con un servidor gRPC en una IP y un puerto específicos.
Arquitectura gRPC
La arquitectura gRPC consiste en un cliente gRPC y un servidor gRPC. Cada servicio cliente gRPC contiene un stub o un archivo autogenerado, que es similar a una interfaz que contiene los procesos remotos activos. El cliente gRPC inicia una llamada de procedimiento local a un stub que contiene los argumentos que deben ser reenviados a los mensajes del servidor gRPC. A continuación, el stub del cliente gRPC envía la consulta a la unidad local del cliente en el ordenador local después de serializar los argumentos mediante el procedimiento de marshaling Protobuf.
El sistema operativo utiliza el protocolo HTTP/2 para comunicarse con el ordenador servidor distante. El sistema operativo del servidor acepta los mensajes e invoca el proceso stub del servidor, que utiliza Protobuf para invocar la operación apropiada después de decodificar los parámetros entrantes. La capa de transporte del cliente recibe entonces la respuesta cifrada del stub del servidor. La ejecución pasa de nuevo a la persona que llama después de que el stub del cliente gRPC reciba los mensajes de respuesta y desenvuelva los argumentos proporcionados.
Ventajas de gRPC
gRPC tiene varias ventajas sobre otros mecanismos de diseño de API. gRPC también mejora la estructura de RPC. Estas son las ventajas más destacadas de los servicios gRPC:
- Llamadas a procedimientos remotos de alto rendimiento
Utilizando Protobuf y HTTP/2, los servicios gRPC proporcionan hasta 10 veces más alto rendimiento y protección de la API que la interacción REST+JSON. Con el uso de server push, multiplexación y compresión de cabeceras, HTTP/2 proporciona clasificaciones de alto rendimiento para los servicios gRPC. Mientras que el multiplexado elimina el retardo de las cabeceras, el server push hace posible que HTTP/2 empuje el material del servidor al cliente antes de que sea necesario. Los mensajes se comprimen de forma más eficaz con HTTP/2, lo que se traduce en una carga más rápida de los servicios gRPC.
- Streaming
La descripción del servicio para los servicios gRPC de streaming ya incluye los principios de streaming del cliente o del servidor. La construcción de clientes gRPC y de servicios de streaming se facilita significativamente como resultado.
- Generación de código
La generación de código para los programas cliente gRPC y servidor gRPC es el componente clave del enfoque web gRPC. Para la generación de código a partir del archivo .proto, los módulos gRPC emplean el compilador .protoc. El formato Protobuf se controla mediante la generación de código en gRPC, que se utiliza para definir tanto los formatos de datos como los puntos finales de la aplicación. Puede crear stubs de red del lado del cliente y esqueletos del lado del servidor, lo que reduce el tiempo necesario para diseñar programas con una variedad de servicios en los servicios gRPC.
- Interoperabilidad
Numerosos sistemas y lenguajes de programación, como Java, Ruby Go, C#, y otros, son compatibles con los recursos y bibliotecas de gRPC. Con estos lenguajes de programación, los desarrolladores pueden crear aplicaciones de alto rendimiento utilizando una compatibilidad completa entre plataformas con gRPC. Esto es gracias a la forma de cableado binario Protobuf y a la generación efectiva de código para casi todos los sistemas.
- Seguridad
La seguridad de la API está garantizada en gRPC utilizando HTTP/2 sobre una sesión cifrada TLS de extremo a extremo. gRPC promueve la adopción de SSL/TLS para el cifrado de datos y la autenticación entre el servidor y el cliente gRPC.
- Productividad y facilidad de uso
Dado que gRPC es una alternativa completa a RPC, funciona sin problemas en una amplia gama de sistemas y lenguajes. gRPC también cuenta con una gran cantidad de herramientas, ya que gran parte del código necesario se genera manualmente. Los ingenieros pueden concentrarse más en la funcionalidad principal gracias al importante ahorro de tiempo que supone gRPC.
Contras de gRPC
Aunque podemos esperar que los inconvenientes de gRPC se resuelvan con el tiempo, ahora plantean algunos problemas para su uso. Algunos de los contras de gRPC que debe conocer son
- Falta de madurez
El desarrollo de una tecnología puede ser una barrera importante para su adopción. Esto también queda claro al utilizar gRPC. GraphQL La comunidad de gRPC, uno de los pares de gRPC, tiene más de 14k consultas en StackOverflow, mientras que gRPC sólo tiene un poco menos de 4k en este momento. La comunidad de gRPC carece de conocimientos sobre las mejores prácticas, soluciones y éxitos, ya que no hay mucha ayuda de los programadores para HTTP/2, así como de los búferes de protocolo fuera de Google. Sin embargo, a medida que la comunidad gRPC se expanda y atraiga a nuevos desarrolladores, esto acabará evolucionando.
- Compatibilidad limitada con los navegadores
Dado que ningún navegador web gRPC actual puede manejar marcos HTTP/2, no se puede llamar eficazmente a un servicio gRPC desde un navegador, ya que gRPC Web depende principalmente de HTTP/2. En consecuencia, debe utilizar un proxy con gRPC, lo que conlleva varios inconvenientes.
- Imposible de leer por los humanos
A diferencia de XML y JSON, los archivos Protobuf no son legibles por los humanos, ya que los datos se comprimen en un formato binario. Los desarrolladores deben hacer uso de herramientas adicionales, como el protocolo de reflexión del servidor y el prompt de comandos gRPC para evaluar las cargas útiles, llevar a cabo la resolución de problemas y crear consultas manuales.
- Curva de aprendizaje pronunciada
Llevará un tiempo familiarizarse con los búferes de protocolo y descubrir métodos para hacer frente a las fricciones de HTTP/2, a diferencia de REST y GraphQL, que emplean principalmente JSON.
¿Cómo ayuda AppMaster?
La generación sincódigo está cambiando la forma de ver la programación. La generación sin código hace posible que la gente aprenda y cree software más rápidamente con la generación de código. La generación de código para su aplicación es más sencilla utilizando plataformas de generación sin código como AppMaster. Tampoco hay problemas de propiedad, ya que la generación de código está protegida y el código que cree le pertenecerá únicamente a usted. Con AppMaster podrá crear aplicaciones cliente y servidor de forma más rápida y sencilla.
La plataforma de generación de código de AppMaster permite a los desarrolladores utilizar el protocolo gRPC para realizar peticiones entre la arquitectura de microservicios del backend. El año que viene ampliaremos el soporte de gRPC incluyendo la API a las aplicaciones gRPC Web y gRPC Mobile.
Conclusión
Aunque los servicios gRPC tienen varios beneficios que los hacen atractivos para las empresas y los desarrolladores, finalmente, la decisión de utilizar servicios gRPC sobre otros como REST o SOAP depende de su aplicación. Mientras que algunos programas tendrán beneficios de alto rendimiento con gRPC, otros podrían ser más adecuados para sus alternativas. Debe conocer los inconvenientes y las ventajas de los servicios gRPC y decidir si le conviene.