La popular arquitectura cliente-servidor divide la comunicación en dos partes: una que se encarga de todas las tareas pesadas y proporciona servicios, conocida como servidor, y la otra que disfruta de esos servicios, conocida como cliente.
En la comunicación cliente-servidor en general, el cliente simplemente envía una solicitud pidiendo recursos o servicios al servidor, y el servidor responde a esa solicitud.
Para la comunicación cliente-servidor, tanto los clientes como los servidores necesitan tener bibliotecas que puedan entender el protocolo en el que se están comunicando. Un protocolo es un lenguaje o conjunto de reglas de comunicación en Internet. Son mecanismos de transporte que siguen algunas pautas para transportar datos por Internet.
El segundo aspecto más importante de la comunicación del cliente es el formato de mensaje en el que tanto el cliente como el servidor pueden acordar. Este formato de mensaje se basa en algunos esquemas, y al no seguir estos esquemas, no se llevaría a cabo la comunicación. Los formatos de mensajes pueden ser similares a XML, que se adhiere a un esquema, o a un archivo JSON, que debe contener pares de valores específicos.
Otro aspecto importante de este tipo de comunicación para comprender es que se basa en un mecanismo de solicitud y respuesta, lo que significa que el servidor solo se comunica cuando el cliente inicia la comunicación. Con REST y GraphQL, esto es mayormente unidireccional. Este es un problema básico que será resuelto por tecnologías como gRPC.
¿Por qué surgió REST?
En los años 90, un protocolo cliente-servidor popular llamado SOAP utilizaba un formato de mensaje XML con un esquema codificado de manera rígida. El esquema del formato de mensaje era muy estricto. La falta de libertad es lo que llevó al abandono de SOAP y a la aparición de REST.
REST surgió debido al creciente auge de JavaScript, lo que llevó al aumento de la popularidad del formato de archivo JSON. Era sencillo de entender y conveniente. Solo tenía pares de clave y valor en su formato de mensaje.
En términos simples, Rest es una pauta para transferir mensajes JSON a través de Internet con HTTP como su protocolo (mecanismo de transporte). Con Rest, uno no necesita preocuparse por crear un esquema.
¿Qué es REST?
Ya hablamos sobre el surgimiento de REST. Ahora profundicemos en su tecnología central. Entonces déjame decirte que REST significa Representational State Transfer. Rest es un estilo arquitectónico de software estandarizado, una API muy utilizada en la industria.
Razones de la popularidad y uso generalizado de REST
- REST es simple y estandarizado para la arquitectura de comunicación. Al utilizar R, no tendrías que preocuparte por formatear tu mensaje o datos. No necesitas preocuparte por el formato de tu mensaje cada vez, ya que todo está estandarizado y utilizado en la industria.
- REST es escalable. Si tu servicio se vuelve más grande y necesita más funcionalidad, puedes renovar fácilmente tu servidor sin preocuparte por el rendimiento de REST del servidor, y puedes crear nuevas funciones en completa aislamiento a menos que estén alterando tus datos.
- REST es sin estado. Esto significa que cada solicitud tendrá algunos datos que deben ser comprendidos por el servidor. La arquitectura del servidor hace que el servidor recuerde la información de esta solicitud, pero en la arquitectura REST, el estado de la sesión se almacena en el lado del cliente, lo que hace que el servidor sea más eficiente y le da al servidor un poco de carga de trabajo para un funcionamiento más fino.
- Por último, pero no menos importante, Rest es una arquitectura de alto rendimiento y soporta la caché.
Cuándo Usar REST
Imagina que estás creando un sitio web para un restaurante. Tienes todos los menús en línea, y los artículos de comida están divididos en tres categorías:
- Entrantes
- Plato principal
- Bebidas
Ahora, digamos que quieres ver todas las bebidas en línea. En la arquitectura Rest, puedes dividir fácilmente y de manera consistente todos tus recursos en puntos finales de API. Por supuesto, puedes usar múltiples autenticaciones en ellos para hacerlos seguros.
En este tipo de caso, enviamos una solicitud GET al servidor a un punto final donde podemos obtener datos de recursos de bebidas.
Del mismo modo, podemos realizar todas las operaciones CRUD (Crear, Leer, Actualizar, Eliminar) en la API Rest, lo que la hace adecuada para grandes proyectos que no requieren una transferencia de datos super-rápida y que no necesitan ser en tiempo real.
Rest funciona mejor para proyectos donde la transferencia eficiente de datos es un factor importante. La caché es otra característica de REST que es útil para aplicaciones estándar como aplicaciones de reserva de comida, aplicaciones de reserva de hoteles, sitios web de blogs, sitios web de foros, etc.
Limitaciones y Problemas con REST
REST es excelente, pero tiene varios inconvenientes que son bastante cruciales en algunos casos. Hablemos de ellos.
- La necesidad de comunicación bidireccional.
¿Qué pasa si el servidor necesita enviar algunos datos al cliente? El servidor desea iniciar la comunicación. En la arquitectura REST, esto no es posible. Por supuesto, puedes usar algunos trucos, pero no son prácticos. - Imagina crear un sitio web de puntuación en vivo. ¿Cómo gestionarías que el servidor envíe una solicitud al cliente para actualizar los datos de la puntuación? Podemos hacer que los clientes envíen solicitudes cada 10 segundos, pero no es una buena práctica en absoluto. Sobrecalentará el servidor, lo que podría provocar problemas de velocidad.
- La arquitectura REST es puramente de solicitud y respuesta y no admite la transmisión de datos (procesamiento de eventos continuos).
- La propiedad de ser sin estado de REST puede considerarse una bendición y una maldición porque no puedes decidir el estado de los datos en la arquitectura REST.
¿Por qué surgió gRPC?
Para abordar el primer problema con REST, que es la necesidad de comunicación bidireccional, se inventó WebSocket, que permite que el servidor inicie la comunicación, pero el problema es que no tiene formato. Solo envía bytes y no tiene restricciones.
Los Websockets no tenían problemas propios, pero el verdadero problema es que cualquier tipo de comunicación requiere un protocolo, y cada protocolo requiere una biblioteca de cliente que pueda comunicarse usando ese protocolo.
Si estás creando una aplicación Python que funciona con la arquitectura Rest, necesitarás un cliente HTTP que pueda comunicarse con el servidor. En muchos casos, las bibliotecas de clientes son desarrolladas por terceros, principalmente por un desarrollador independiente. Usar bibliotecas de terceros puede exponer tu seguridad, y toda tu aplicación dependerá de un tercero para la comunicación.
En el caso de una aplicación web, el navegador actúa como una biblioteca de clientes, pero para proyectos no web, necesitarás una biblioteca de clientes de terceros. Si estás pensando en crear una propia, recuerda que no es tan fácil, y te cargarás de mantener otra aplicación.
Entonces, para abordar algunos problemas con Rest y para abordar problemas con las bibliotecas de clientes, Google inventó gRPC en 2015.
Para gRPC, una biblioteca de clientes es mantenida por Google para casi todos los lenguajes populares. Utiliza el protocolo HTTP 2 en segundo plano y protocol buffer (protobuf) como su formato de mensaje.
No necesitas preocuparte por ninguna biblioteca de clientes, ya que Google la mantiene para ti y para casi todos los lenguajes de programación. Una única y centralizada biblioteca de clientes es una de las principales fortalezas de gRPC.
Otra ventaja de gRPC es el formato de mensaje que utiliza. El protocolo buffer es agnóstico de lenguaje, por lo que puedes hacer clientes en Python y servidores en Go y aún así poder comunicarte sin hacer ningún alboroto.
gRPC es esencialmente una biblioteca de clientes y un protocolo que se puede utilizar en cualquier dispositivo.
¿Qué es gRPC?
gRPC utiliza protobuf para comunicarse. Serializa los archivos proto en formato binario y los envía al servidor, y en el lado del servidor, se deserializan en su formato original. Así es como funciona con protobuf.
gRPC tiene diferentes formas de comunicación. Puedes pensar en ellas como características de gRPC.
Características de gRPC
- Solicitud única: Es un tipo simple de comunicación solicitud-respuesta donde el cliente envía una solicitud proto y, al recibirla, el servidor espera algún tiempo para realizar algún proceso y luego devuelve alguna respuesta.
- Streaming del servidor: Al hacer una sola solicitud, una inundación de datos viene como respuesta desde el servidor. Por ejemplo, al hacer clic en un video, una gran cantidad de datos relacionados con el video inunda desde el lado del servidor.
- Streaming del cliente: Es lo contrario para el streaming del servidor. Aquí el cliente envía una gran cantidad de datos a la vez al servidor. Por ejemplo, ocurre cuando compartes un archivo grande en Internet o subes una imagen o video a Internet. El cliente envía constantemente datos al lado del servidor.
- Streaming bidireccional: En este tipo de comunicación, el cliente y el servidor envían múltiples mensajes. Chatear es un excelente ejemplo de ello.
Estas son cuatro características populares de gRPC que lo hacen tan poderoso.
Cuándo usar gRPC
En cuanto a las características de gRPC, vimos algunos casos de uso para gRPC. Imaginemos que deseas crear una aplicación de chat. No vas a utilizar la API Rest ya que no permitirá la rápida transmisión de comunicación bidireccional. Para esto, utilizaremos el flujo de gRPC, que proporcionará algunas ventajas adicionales además de la velocidad.
Primero, su comportamiento independiente del lenguaje no importa en qué lenguaje de programación esté escrito el servidor u otros clientes. La comunicación aún puede establecerse siempre que el formato del mensaje sea aceptado.
Entonces, con esta característica, la versión Android de la aplicación de chat puede comunicarse con la versión iOS y viceversa.
Problemas con gRPC
Todo tiene problemas, incluyendo gRPC.
- Soporte limitado para navegadores: gRPC utiliza HTTP 2, por lo que es difícil llamar al servicio gRPC directamente desde el navegador, lo que a veces requiere configurar un proxy.
- Forma no legible: Como todos sabemos, gRPC utiliza un formato binario que no es legible por humanos. Es una desventaja en algunos casos.
- Falta de madurez: gRPC fue desarrollado en 2015, por lo que aún es un poco inmaduro en comparación con REST, y muchos errores y problemas necesitan ser resueltos.
- Problemas de aprendizaje: Rest y GraphQL utilizan JSON, que es más fácil de aprender. La mayoría de las personas intentarán apegarse a ellos ya que protobuf sigue siendo un tema nuevo y complejo, por lo que será difícil encontrar expertos en gRPC.
REST vs. gRPC:
Ahora discutiremos la diferencia técnica entre REST y gRPC.
Formato de mensaje:
El formato de mensaje utilizado por REST es principalmente JSON (a veces formato XML), que es una forma más legible y fácil de manejar. No tendrás que preocuparte por el esquema en Rest. Por otro lado, gRPC utiliza un protocol buffer para serializar los datos. La forma comprimida es más ligera y más rápida para viajar. Está en formato binario, por lo que serializa y deserializa los datos para transmitirlos.
HTTP 1.1 vs. HTTP 2:
La API Rest suele utilizar HTTP 1.1 como protocolo, mientras que gRPC utiliza HTTP 2 como protocolo bajo el capó. La API Rest aún puede usar HTTP 2 pero sigue limitada debido al mecanismo de solicitud-respuesta. gRPC utiliza HTTP 2 y aprovecha el soporte de HTTP 2 tanto para la comunicación de respuesta del cliente como para la comunicación bidireccional. Este es otro aspecto que hace que el rendimiento de gRPC sea superior al de REST. Puede manejar solicitudes unidireccionales como HTTP 1.1 y solicitudes bidireccionales simultáneamente como HTTP 2.
Latencia:
La baja latencia y la alta velocidad de comunicación de gRPC lo hacen útil para conectarse a sistemas que consisten en una arquitectura de microservicios ligeros, lo que aumenta la eficiencia de la transmisión de mensajes. En la mayoría de los casos de la red, la latencia de REST es de 25ms, mientras que la latencia de gRPC es mucho menor que la de REST.
Límite de carga útil:
Rest tiene un límite máximo de carga útil de 45MB al enviar mensajes salientes, mientras que gRPC no tiene ningún límite, lo que significa que tu mensaje saliente puede ser tan pesado como desees.
Seguridad:
En términos de seguridad, Rest tendrá un desventaja ya que utiliza HTTP 1.1 y formato JSON, que es fácil de descifrar y acceder. Por otro lado, gRPC utiliza HTTP 2, que es mucho más seguro, y emplea protobuf, que está en formato binario y es difícil de descifrar.
Velocidad:
Aquí también, gRPC es superior, ya que ofrece 10 veces más velocidad que Rest, y es por la misma razón, al utilizar HTTP 2 como protocolo y protobuf como formato de mensaje.
Función de generación de código
Rest no proporciona características integradas de generación de código, lo que significa que el desarrollador necesita aplicaciones de terceros para producir código API, mientras que gRPC tiene características nativas de generación de código debido a su compilador de protobuf, que es compatible con varios lenguajes de programación. Este es otro beneficio, particularmente para arquitecturas de microservicios.
Puerta de enlace REST de Memphis
Para permitir la producción de mensajes a través de llamadas HTTP para varios casos de uso y facilidad de uso, Memphis agregó una puerta de enlace HTTP para recibir solicitudes basadas en REST (=mensajes) y producir esos mensajes a la estación requerida.
Casos de uso comunes que se benefician de la Puerta de enlace REST son:
- Producir eventos directamente desde el frontend
- Conectar Debezium usando Servidor HTTP
- Webhooks de ArgoCD
- Integración de PostHog
- Recibir datos de Fivetran/Rivery/Cualquier plataforma ETL mediante llamadas HTTP
Puerta de enlace REST de Memphis + un esquema JSON puede ser una combinación poderosa para aumentar la calidad de los datos y asegurar una comunicación saludable entre aplicaciones o servicios.
Memphis pronto también soportará gRPC.
Conclusión
En última instancia, me gustaría decir que REST sigue siendo la arquitectura más utilizada y popular, y es imposible abandonarla. REST tiene varios inconvenientes, como la falta de transmisión de datos, la ausencia de comunicación bidireccional, la velocidad lenta, etc., pero es la mejor opción para aplicaciones estándar que vemos en la vida cotidiana.
Por otro lado, gRPC, siendo joven y difícil de aprender, ofrece muchas cosas como alta transmisión de datos en ambos lados, cliente y servidor, una buena transmisión de datos bidireccional, es rápido y compacto, y utiliza HTTP 2. Debido a su rápida ejecución, gRPC es ideal para aplicaciones de alta carga de trabajo como transmisión de video, transmisión de música, juegos en línea, compartir archivos y aplicaciones de chat.