Header Ads Widget

Ticker

6/recent/ticker-posts

5 protocolos para arquitecturas de API basadas en eventos


Internet es un sistema de comunicación y, como tal, la relación entre cliente y servidor, así como servidor a servidor, es uno de los conceptos más discutidos y controvertidos. La arquitectura impulsada por eventos es una metodología para definir estas relaciones y crear sistemas dentro de un conjunto específico de relaciones que permiten una amplia funcionalidad.

En este artículo, analizaremos 5 métodos comunes controlados por eventos: WebSockets , WebHooks , REST Hooks , Pub-Sub y Server Sent Events . Definiremos qué son y qué hacen fundamentalmente, y cómo los proveedores de API los utilizan. Además, proporcionaremos algunos pros y contras de cada uno para que la elección de una solución para su plataforma sea fácil e intuitiva.

¿Qué es una arquitectura impulsada por eventos?

Las arquitecturas impulsadas por eventos establecen un evento al que se puede consumir y reaccionar. Pero, ¿qué es un evento ?

Un evento es esencialmente cualquier cambio significativo de un estado a otro, como el cambio de no tener mensajes en su bandeja de entrada a tener un nuevo mensaje en su bandeja de entrada. Se puede reaccionar a este estado internamente (como cuando el programa de correo electrónico en cuestión se da cuenta de que se ha recibido un nuevo mensaje), externamente (cuando un usuario ve una notificación de un nuevo mensaje) o se puede usar para generar otro evento (por ejemplo, el el recuento de mensajes aumenta en uno).

Las arquitecturas basadas en eventos son atractivas para los desarrolladores de API porque funcionan muy bien en entornos asincrónicos . Al crear API que activan ciertas funciones en la entrega de nuevos eventos, los sistemas de API no tienen que esperar inherentemente la entrega síncrona o la comunicación en tiempo real. Esto es muy beneficioso, ya que la eliminación de la necesidad de sondear constantemente los puntos finales libera recursos de propósitos que de otro modo serían derrochadores, reduciendo tanto los requisitos generales de hardware como la sobrecarga específica de las llamadas.

Por esta razón, las arquitecturas controladas por eventos son muy, muy populares y conducen a una potencia, ancho de banda y coprocesamiento mejorados que otras soluciones y arquitecturas, como sondeos y otros derivados centrados en encuestas.

5 tipos de protocolos basados ​​en eventos para API

1: WebSockets

Los WebSockets son una solución basada en eventos interesante porque, para la mayoría de los navegadores, están integrados en la propia aplicación. Básicamente, WebSocket es un protocolo que proporciona comunicación full-duplex en una sola conexión TCP. Fue estandarizado por el Grupo de trabajo de ingeniería de Internet como RFC 6455 , y la API de WebSocket en Web IDL se estandarizó más tarde bajo el título W3C.

Si bien el protocolo en sí está diseñado para usarse entre navegadores web y servidores , el protocolo se puede usar en cualquier caso donde exista una relación cliente-servidor. El protocolo en sí se basa en TCP, con la declaración de interpretación HTTP adicional que se considera una "solicitud de actualización" para permitir la interoperabilidad.

Pros

Debido a que WebSocket está diseñado expresamente para el funcionamiento del navegador, cuenta con una sobrecarga extremadamente baja para lo que realmente hace. Al establecer una conversación full-duplex usando una metodología estandarizada, la conexión hacia y desde las dos entidades puede tener lugar simultáneamente, lo que resulta en una menor sobrecarga y un mejor rendimiento.

Además, el hecho de que estas comunicaciones se realicen a través de TCP 80/443 significa que los entornos que tradicionalmente bloquean las aplicaciones no basadas en web por razones de seguridad aún pueden manejar este protocolo, ya que los firewalls permiten la comunicación hacia y desde este puerto.

Quizás el argumento más fuerte para el uso de WebSockets es el hecho de que están estandarizados y son compatibles de forma nativa con todos los navegadores principales, desde Microsft Edge hasta Opera, desde Firefox hasta Chrome. Esto significa que cualquier aplicación web que se vincule con ella podrá interactuar dentro de la gran mayoría de las puertas de enlace y aplicaciones tanto basadas en el navegador como independientes del navegador.

Contras

Los WebSockets tienen una falla importante distintiva: si bien puede tener soporte para una funcionalidad similar a HTTP, no es HTTP en absoluto. Esto tiene implicaciones, especialmente cuando se considera la optimización en HTTP, como el almacenamiento en caché, el proxy, etc., que no se han hecho evidentes.

Debido a que los WebSockets son relativamente nuevos, ya que solo se estandarizaron oficialmente en 2011, la industria aún comprende qué significan los efectos secundarios. La mayoría de las aplicaciones que utilizan WebSockets están diseñadas específicamente para todo lo que es un WebSocket; sin embargo, lo que aún está por verse es si esta solución es mejor a largo plazo que cualquier solución sin estado disponible actualmente.

Por supuesto, existe el hecho de que, al igual que con otras arquitecturas en esta lista, WebSockets crea una conexión "siempre activa" durante la duración de la transferencia de datos. Si bien esto está bien para muchos usos, como la transmisión de medios y los cálculos de transmisión en vivo, también significa esencialmente que, para WebSockets, no hay escalabilidad . Los puertos tienen limitaciones y ancho de banda codificados, por lo que para "escalar", debe agregar puertos adicionales para igualar la carga máxima. En los sistemas sin estado, esto es un problema menor, ya que las solicitudes pueden esperar y realizarse de tal manera que sean independientes del estado del servidor en sí.

2: WebHooks

Los WebHooks son un concepto similar al WebSocket. Funcionan principalmente mediante devoluciones de llamada personalizadas o código que se pasa como argumento a otro fragmento de código y se ejecuta en un momento específico. Esencialmente, un WebHook es un sistema glorificado de "si esto es así, entonces hazlo", lo que permite a los usuarios, independientemente del evento, crear una respuesta personalizada a ese evento dentro de su propio sistema.

El término fue acuñado por Jeff Lindsay en 2007 y rápidamente se hizo popular entre los usuarios que deseaban crear respuestas automáticas a comportamientos externos. Un gran ejemplo de esto sería un desarrollador que envía un nuevo elemento a GitHub, lo que provoca un evento. Un usuario tiene un sistema vinculado al URI de un WebHook. Cuando se publica la inserción, el sistema del usuario utiliza el URI de WebHook para integrar la inserción en una compilación más grande, creando así un componente compilado.

Pros

Los WebHooks funcionan de manera muy parecida a los WebSockets, pero son diferentes en algunas áreas clave. En primer lugar, los WebSockets están diseñados principalmente para comunicaciones basadas en navegador y, si bien se pueden usar independientemente en cualquier comunicación cliente-servidor, no se comportan bien en una configuración de servidor a servidor.

Los WebHooks, por otro lado, funcionan muy bien en sistemas de servidor a servidor debido a cómo operan. Debido a que el sistema funciona esencialmente como el mencionado "si esto es así", los servidores pueden configurarse para vincularse a URI preformados en cualquier momento y ejecutar una función determinada siempre que se active ese evento.

Además, los WebHooks tienen la ventaja única de estar basados ​​en HTTP , a diferencia de los WebSockets. Esto significa que el sistema se puede integrar sin utilizar ninguna infraestructura nueva, lo que permite una adopción rápida y una configuración relativamente simple.

Contras

El problema con WebHooks es que gran parte de su funcionalidad ya se puede colocar en el enfoque arquitectónico REST posiblemente más poderoso. Si bien la adopción de una arquitectura impulsada por eventos es a menudo un requisito del servicio que se está construyendo, es difícil de vender cuando se puede reflejar en REST y al mismo tiempo brindar la gran cantidad de opciones que REST brinda al usuario.

Sin embargo, estas soluciones RESTful, como RestMS, son esencialmente simplemente servicios de consulta de mensajes y requieren una infraestructura adicional, que puede ser factible o no teniendo en cuenta el propósito de la aplicación.

Además, WebHooks puede consumir muchos recursos tanto para el cliente como para el servidor. Si el cliente necesita notificar a muchos servidores que se ha producido un evento, y un servidor necesita escuchar a una gran cantidad de clientes que notifican este cambio, puede encontrarse rápidamente con una situación en la que su red crece sin control. Si bien HTTP se escala bastante bien, esto es definitivamente un aspecto negativo a considerar.

Sin embargo, también hay formas de crear un servicio de cola de mensajes sobre HTTP; algunos ejemplos de RESTful incluyen IronMQ y RestMS .

3: ganchos de descanso

Hablando de ejemplos RESTful, REST Hooks es esencialmente "enganchar" horneado en REST. Definido como una iniciativa de Zapier , este es un tema que hemos cubierto antes : los ganchos se recopilan en una única URL de destino como una suscripción, que hace ping al solicitante de recursos cuando se observa un cambio.

Este enfoque es una respuesta a la práctica del sondeo , en el que un cliente comprueba constantemente los cambios en un recurso. Bajo el paradigma REST Hooks, el cliente espera un cambio y reacciona a él. En pocas palabras, este es un WebHook en REST.

Pros

Los REST Hooks son obviamente superpoderosos en el contexto correcto: ser capaz de recibir un recurso de forma pasiva en lugar de dedicar potencia de procesamiento al sondeo constante libera gran parte del costo del lado del cliente.

Quizás el argumento más fuerte para REST Hooks, sin embargo, es el hecho de que es tan fácil e intuitivo de usar. Si bien los WebHooks utilizan HTTP y, por lo tanto, no necesitan una nueva arquitectura para configurarse, también están limitados por el hecho de que se basan en HTTP y, por lo tanto, pueden ser algo complejos de configurar correctamente y usar de manera efectiva.

Sin embargo, los REST Hooks se basan en suscripciones y, como tales, se pueden usar simplemente mediante la suscripción. Esto la convierte en una solución muy fácil de usar a la vez que proporciona mucha facilidad de uso y eficacia de sistemas más complejos.

Contras

Por supuesto, cada solución tiene sus aspectos negativos, y los REST Hooks no son diferentes. Se podría ver que los ganchos REST realmente se enfrentan a lo que es REST sesión gratuita y sin estado . REST Hooks esencialmente crea un sondeo consistente, simplemente mueve el sondeo de un lado a otro.

Luego, está el problema discutible de que REST Hooks podría estar haciendo algo que ya se ha resuelto. Algunos argumentarían que TCP ya hace la mayor parte de lo que REST Hooks está tratando de hacer, y simplemente colocar más soluciones en capas sobre HTTP para obtener lo que TCP ya hace es un enfoque deficiente.

4: Pub-Sub

Pub-Sub es un enfoque ligeramente diferente. Conocido por su nombre completo como publicación-suscripción , el concepto es donde los eventos se publican en una clase sin el conocimiento del cliente que se suscribe a la clase. Básicamente, un usuario se unirá a una o más clases y luego recibirá actualizaciones del evento sin tener en cuenta ni conocimiento del editor del evento.

La principal diferencia aquí es la elección consciente del proveedor: en las otras soluciones mencionadas en este documento, un usuario se comunica conscientemente con un servidor o proveedor determinado y recibe eventos predeterminados. Bajo el esquema Pub-Sub, el usuario solo especifica de qué clase desea formar parte y qué eventos está interesado en recibir. A partir de ahí, reciben estos eventos cuando uno es expulsado.

Una forma en que esto se enmarca a menudo en las discusiones de Internet es en el marco de un canal de radio . Las compañías discográficas o editores emiten audio a la estación, que luego transmite este audio a los oyentes o suscriptores. Pub-sub es la estación de radio intermediaria aquí: los oyentes no saben quién le dio la música a la estación, ni las empresas saben quiénes son los oyentes. Es esta segmentación la que se incorpora al patrón.

Cuando hablamos de Pub-Sub, debemos tener en cuenta que en realidad estamos hablando de dos cosas diferentes. Pub-Sub puede significar la metodología y el concepto general en términos de programación, pero también puede significar soluciones de proveedor específicas basadas en esa metodología. Por ejemplo, Cloud Pub / Sub de Google es una implementación de la metodología general dentro de su servicio en la nube y permite relaciones asincrónicas de muchos a muchos pub-sub como se indicó anteriormente.

Pros

Un gran beneficio de Pub-Sub es el hecho de que está débilmente acoplado y, por lo tanto, es extremadamente escalable y flexible. Lo único que está haciendo el proveedor de eventos es generar el contenido; cada paso se realiza a través de un intermediario separado, por lo que el contenido se escala y se modula fácilmente según la arquitectura y el diseño de la solución.

Además, Pub-Sub se presta muy bien para realizar pruebas . Un suscriptor está limitado a un conjunto de eventos que ha solicitado bajo una clase, por lo que si ocurre una falla, esta segmentación natural informa al proveedor sobre dónde está la falla y qué clase de usuarios está experimentando la falla.

Contras

Desafortunadamente, el desacoplamiento también es una gran desventaja para este patrón. Al ser un intermediario , Pub-Sub no puede notificar eficazmente al proveedor que se ha enviado un mensaje, y el oyente está separado del evento y, por lo tanto, es posible que no sepa si no se envió un mensaje que debería haber sido. Volviendo a la explicación de la radio, un oyente nunca sabrá si una canción estaba destinada a reproducirse en un canal o si el canal está fuera de alcance, y una vez que los ejecutivos de grabación entregan la música, no tienen idea de si el usuario recibió las canciones sin comentarios directos de ellos.

Además, si bien el sistema es extensible y flexible, la inestabilidad ocurre con una alta carga de tráfico, ya que se pueden construir subclase tras subclase para manejar una mayor segmentación. Esto, por supuesto, conduce a la inestabilidad mencionada además de una mayor complejidad.

Debe tener en cuenta que si bien la relación entre el editor y el suscriptor en este modelo puede ser beneficiosa, también presenta sus propias dificultades cuando estas relaciones deben ser moduladas. Si bien ciertamente puede solucionar esto, en este punto, está luchando contra la base misma del patrón, en lugar de contra naturalezas secundarias: está tratando de producir agua deshidratada, y luchar contra la naturaleza de un patrón sugiere que el patrón debe ser inherentemente pobre.

Lea también: Creación de un backend para frontend (BFF) para sus microservicios

5: Eventos enviados por el servidor

Server Sent Events , o SSE, es un protocolo de comunicación muy parecido a WebSockets, pero con la implicación de datos unidireccionales . En esta arquitectura, el servidor envía constantemente actualizaciones al cliente como un proceso automático. Esto fue estandarizado en HTML5 por el W3C y, por lo tanto, es compatible con cualquier solución que sea igualmente compatible con HTML5.

Es de destacar que existe una estandarización competitiva del Grupo de Trabajo de Tecnología de Aplicación de Hipertexto Web : esto es una reliquia del movimiento que se alejó de "HTML5" y se convirtió en lo que WHATWG llama "HTML Living Standard". El consenso general de trabajo es que la estandarización de WHATWG se prioriza en los raros casos de estándares divergentes. Esto podría convertirse en un problema mayor a medida que avanza el tiempo, dado que WHATWG se creó debido a una falta de interés percibida por parte del W3C hacia la evolución de HTML, pero por el momento, cualquiera de los estándares es generalmente aceptable.

Si bien son simples en teoría, los eventos enviados por el servidor son todo menos simples cuando se consideran los beneficios y los inconvenientes.

Pros

SSE no es bidireccional en sus comunicaciones: el servidor emite los eventos de forma constante y predecible. Esto es muy beneficioso para las aplicaciones que no necesitan las comunicaciones bidireccionales integradas en WebSockets u otras soluciones similares, ya que esto significa un ancho de banda más bajo y un margen para que la conexión sea temporal en lugar de estar siempre activa durante la transferencia de datos. Por su naturaleza, los datos se transfieren en un solo sentido y, por lo tanto, no es necesario esperar a que se devuelvan los datos.

Además, al menos en teoría, SSE es más fácil de configurar en situaciones complejas. Solo tiene que preocuparse de que los datos viajen en una dirección a través de un sistema, reduciendo así la complejidad de forma espectacular. No es necesario definir un protocolo de intercambio de mensajes, no es necesario especificar la duración de los datos o los tiempos de espera, no es necesario admitir la mensajería bilateral: la dirección única ahorra mucha complejidad.

Contras

Esa simplicidad podría ser donde SSE falla para casos de uso particulares. SSE es una solución muy pobre para situaciones que requieren comunicación bidireccional , y aunque esto parece obvio, a muchos desarrolladores les sorprendería ver cuántos sistemas realmente dependen de la comunicación bidireccional para una funcionalidad simple.

Si bien gran parte de esto se puede solucionar con soluciones alternativas, el objetivo de un desarrollador al elegir un protocolo impulsado por eventos debe ser encontrar uno que funcione de inmediato , no encontrar una solución que pueda funcionar si se configura correctamente y se le dan sistemas secundarios sobre los cuales depender.

También está la cuestión de la seguridad y la autenticación. Si bien los sistemas bidireccionales pueden usar fácilmente metodologías de autenticación, SSE maneja esto mediante el reenvío de encabezados . Si bien los encabezados se pueden manipular y anular en muchos idiomas y aplicaciones, el objeto EventSource en JavaScript no es compatible de forma nativa con esto, lo que causaría a muchos adoptados algunos dolores de cabeza importantes.

Finalmente, existe una preocupación por la pérdida de eficiencia con la transmisión excesiva de datos. Un sistema bidireccional puede determinar cuándo se desconecta un cliente o servidor, pero SSE solo puede determinar que un cliente se ha desconectado después de intentar una transmisión de datos completa y recibir una falla notada. Debido a esto, los datos se pueden perder con bastante rapidez y, con muchas conexiones fallidas, esta pérdida puede aumentar drásticamente con el tiempo.

Conclusión

No existe una solución basada en eventos que funcione en todos los casos de uso. Si bien muchos argumentarían que las soluciones impulsadas por eventos deberían basarse en REST, lo que sugiere REST Hooks como la respuesta, muchos otros argumentarían que es completamente situacional y que REST no siempre es la bala de plata que se promociona.

Si está creando escalabilidad con una sobrecarga baja en un entorno de navegador, WebSockets es una gran solución. Por el contrario, si desea esos mismos beneficios pero está trabajando en un sistema sin navegador, WebHooks debería ser su enfoque. Los REST Hooks no solo son excelentes para los servicios RESTful, sino que también son mucho más fáciles de configurar que cualquiera de los dos y, por lo tanto, son excelentes en situaciones de poca prisa. Pub-Sub puede ser excelente si necesita hacer cumplir una división entre cliente y servidor, y esto puede establecerse y controlarse aún más de una manera aún más sólida con Server Sent .

En pocas palabras, la mejor solución será la que se adapte a su situación y construcción específicas; cualquiera de estas soluciones, dado el sistema correcto, es una gran solución. Con ese fin, cada solución tiene un caso de uso muy específico.

Tabla de comparación de TLDR

PROTOCOLORELACIONADO CONCUERPO ESTÁNDARNOTAS
WebSocketsTCP, similar a HTTPIETF, W3C
  • Comunicación bidireccional sobre TCP
  • Diseñado para navegadores web y servidores web
  • Bueno para escenarios de gastos generales más bajos
  • Compatible con los principales navegadores
WebhooksURI, HTTP-
  • "Devoluciones de llamada HTTP" definidas por el usuario
  • Activado por un evento HTTP
  • Las solicitudes se realizan a Webhook URI
  • Permite la activación de eventos en tiempo real
Ganchos de descansoHTTPZapier
  • Capa de suscripción ligera
  • Manipulado por una API REST
  • Esencialmente un WebHook en REST
Pub-Sub--
  • El cliente se suscribe a las clases
  • Bidireccional
  • Capa de intermediario entre cliente y servidor
  • Bajo acoplamiento
Servidor enviadoHTTP, HTML5, DOMWHATWG, W3C
  • El servidor envía actualizaciones constantemente al cliente
  • Notificaciones push unidireccionales como eventos DOM

 


Publicar un comentario

0 Comentarios