Por qué AJAX no es suficiente

 

 

 

  • Patrones de diseño para interfaces de IA, con Vitaly Friedman
  • Implemente rápidamente. Implementar inteligentemente

  • Índice
    1. Lo que resolvió AJAX
    2. Lo que queda sin resolver
    3. PubSub: actualizaciones de una a muchas
    4. ¿Dos patrones de mensajería, dos tecnologías?
    5. WAMP: RPC y PubSub
    6. Actualizaciones de votación en vivo: vote usando WebSockets y WAMP
      1. Incluyendo una biblioteca WAMP
      2. Estableciendo una conexión
      3. Registrar y llamar a un procedimiento
      4. Suscripción y publicación de actualizaciones
    7. Resumen
      1. Notas finales
      2. Otras lecturas

    Las llamadas AJAX no cubren las actualizaciones del servidor, que son necesarias para la web moderna colaborativa y en tiempo real. PubSub (como en "publicar y suscribirse") es un patrón de mensajería establecido que logra esto. En este artículo, Alexander Gödde analizará precisamente cómo PubSub resuelve el problema de actualización y analizará una solución particular (el protocolo WAMP) que integra tanto la llamada de procedimientos en el servidor como PubSub en una única API.

     

    Las llamadas AJAX han dado un gran paso adelante en la interacción del usuario en la Web: ya no necesitamos recargar la página en respuesta a cada entrada del usuario. Usando AJAX, podemos llamar a procedimientos específicos en el servidor y actualizar la página según los valores devueltos, brindando a nuestras aplicaciones una rápida interactividad.

    Lo que las llamadas AJAX no cubren son las actualizaciones del servidor, que son necesarias para la Web moderna colaborativa y en tiempo real. Esta necesidad de actualizaciones cubre casos de uso que van desde un par de usuarios que editan de forma colaborativa un documento hasta la notificación a potencialmente millones de lectores de un sitio web de noticias de que se ha marcado un gol en un partido de la Copa Mundial. Se necesita otro patrón de mensajería, además de la solicitud de respuesta de AJAX, uno que funcione a cualquier escala. PubSub (como en "publicar y suscribirse") es un patrón de mensajería establecido que logra esto.

    En este artículo, veremos precisamente cómo PubSub resuelve el problema de actualización y veremos una solución particular (el protocolo WAMP ) que integra tanto la llamada de procedimientos en el servidor como PubSub en una única API.

    Lo que resolvió AJAX

    Antes de AJAX, la interactividad en las páginas web era terriblemente complicada. Cualquier interacción del usuario requería que se generara una versión actualizada de la página en el servidor, se enviara al navegador y se representara allí. En este modelo, la unidad fundamental de interacción era la página. Cualquiera que sea el navegador que envíe al servidor, no importa cuán pequeña sea la actualización requerida, el resultado siempre será una página completamente nueva. Esto suponía un desperdicio tanto de tráfico por cable como de recursos del servidor, y era lento y doloroso para el usuario.

    AJAX rompió esto al granularizar las cosas: ahora puede enviar datos, recibir solo el resultado de la interacción desencadenada por ellos y luego actualizar las partes relevantes de la página en función de esta respuesta. Con AJAX, pasamos de una única llamada generalizada (“Dame una nueva página”) a múltiples llamadas específicas de interacción. Con AJAX, teníamos llamadas a procedimientos remotos (RPC) en el servidor.

    Considere el siguiente ejemplo sencillo de una aplicación web para votar que es posible gracias a esto:

    El usuario podrá votar por cualquiera de los tres sabores de helado que se ofrecen.

    Usando AJAX, un voto en el que se hace clic podría conducir a algo como esto:

    var xhr = new XMLHttpRequest();xhr.open('get', 'send-vote-data.php');xhr.onreadystatechange = function() { if(xhr.readyState === 4) { if(xhr.status === 200) { // Update vote count based on call result } else{ alert('Error: '+xhr.status); // An error occurred during the request } }}

    Luego cambiaríamos solo el recuento de votos por el tipo votado por el usuario, de acuerdo con el retorno de la llamada AJAX. Pasamos de representar una página completa a actualizar un solo elemento DOM.

     

    Esto significa mucho menos trabajo para el servidor y menos tráfico en la red. Estamos recibiendo un recuento de votos en lugar de una página completa. Lo más importante es que permite una actualización rápida de la interfaz, mejorando drásticamente la experiencia del usuario.

    Lo que queda sin resolver

    En un caso de uso del mundo real, algo como esta aplicación de muestra haría que muchos usuarios votaran, a menudo en paralelo. El recuento de votos cambiaría según las interacciones combinadas de los usuarios. Debido a que las llamadas AJAX activadas por la interacción de un usuario serían la única conexión al servidor, el usuario vería los números de votación actuales cuando cargara la aplicación por primera vez, pero no estaría al tanto de los cambios de votación de back-end a menos que actualizara la página.

    Esto se debe a que AJAX nos permite actualizar páginas sólo en respuesta a la acción del usuario en la página . No soluciona el problema de las actualizaciones provenientes del servidor. No ofrece una manera de hacer lo que realmente necesitamos aquí: enviar información desde el servidor al navegador. Necesitamos un patrón de mensajería adicional que envíe actualizaciones al cliente sin que el usuario (o el código del cliente) tenga que solicitarlas constantemente.

    PubSub: actualizaciones de una a muchas

    Un patrón de mensajería establecido para manejar actualizaciones para muchos clientes es PubSub . En este caso, un cliente declararía interés en un tema (“suscribirse”) a un corredor central. Cuando el cliente envía un evento para un tema al corredor (“publicar”), el corredor distribuirá este evento a todos los clientes actualmente conectados y suscritos.

    Una gran ventaja del patrón PubSub es que los editores y suscriptores están desacoplados a través del corredor. Un editor no necesita ningún conocimiento de los suscriptores actuales de un tema y, de manera similar, los suscriptores no necesitan ningún conocimiento de los editores. Esto significa que PubSub es fácil de implementar tanto para los editores como para los suscriptores y se escala bien.

    Hay numerosas implementaciones de PubSub disponibles para elegir, según los marcos, bibliotecas y lenguajes de back-end y front-end que esté utilizando. Por ejemplo, para Node.js o Ruby, puedes usar algo como Faye . Si no desea ejecutar su propio corredor, los servicios web como Pusher alojarán la funcionalidad por usted.

    ¿Dos patrones de mensajería, dos tecnologías?

    No es difícil encontrar una tecnología PubSub que se adapte a las necesidades de una aplicación o sitio web en particular. Pero incluso para algo tan simple como nuestra demostración de votación, hemos visto que necesitas tanto RPC como PubSub: necesitas enviar y solicitar datos, así como recibir actualizaciones automáticas. Con cualquiera de las soluciones PubSub puras, debes utilizar dos tecnologías diferentes para la mensajería de tu aplicación: AJAX y PubSub.

     

    Esto claramente tiene algunas desventajas:

    • Debe configurar dos pilas de tecnología, posiblemente incluyendo dos servidores, y mantenerlas actualizadas y en funcionamiento.
    • La aplicación necesita conexiones independientes para los dos patrones de mensajería, lo que requiere más recursos del servidor. Estas dos conexiones también requerirían su propia autenticación y autorización, lo que aumentaría la complejidad de la implementación y, con ello, el margen de error.
    • En el servidor, necesitaría integrar las dos pilas de tecnología en su única aplicación, coordinando entre las dos.
    • Para los desarrolladores front-end, las preocupaciones son similares: establecer y manejar dos conexiones y tratar con dos API separadas.

    WAMP: RPC y PubSub

    El Protocolo de mensajería de aplicaciones web (WAMP) resuelve las desventajas anteriores integrando RPC y PubSub en un único protocolo. Tienes una única biblioteca, una única conexión y una única API. Manejará todos los mensajes de su aplicación entre el front-end del navegador y el back-end de la aplicación.

    WAMP es un protocolo abierto y tiene una implementación de JavaScript de código abierto (Autobahn|JS) que se ejecuta tanto en el navegador como en Node.js, lo que le permite realizar aplicaciones exclusivamente de JavaScript. Existen implementaciones de código abierto para otros lenguajes, por lo que puede usar PHP, Java, Python o Erlang, así como JavaScript en el servidor (y se espera que la lista de lenguajes crezca). Cine de Calidad gratis

    Estos otros lenguajes no se limitan al back-end: también puede utilizar las bibliotecas WAMP para clientes nativos, lo que permite mezclar clientes web y nativos utilizando el mismo protocolo. La biblioteca C++, por ejemplo, es muy adecuada para ejecutar componentes WAMP en dispositivos integrados con recursos limitados: piense en sensores en una aplicación de Internet de las cosas .

    Las conexiones WAMP no se establecen desde el navegador hasta el back-end, sino con un enrutador WAMP, que realiza la distribución de mensajes. Maneja el rol de intermediario para PubSub, de modo que su servidor simplemente publica en el enrutador, y este maneja la distribución del evento a todos los suscriptores. Para los RPC, el front-end emite la llamada para un procedimiento remoto al enrutador, y este la reenvía al back-end, que ha registrado el procedimiento. Luego devuelve el resultado desde el back-end a la persona que llama. Esto desacopla los front-ends y back-ends como con PubSub. Puede distribuir su funcionalidad en varias instancias de back-end sin que el front-end necesite saber la existencia de ninguna de ellas.

    Hay características de protocolo adicionales además del enrutamiento básico, como autenticación de clientes, autorización basada en roles y temas de publicación, y restricción de publicaciones a clientes particulares. Los enrutadores WAMP ofrecen diferentes conjuntos de esta funcionalidad avanzada.

    Veremos cómo resolver el problema de actualización de nuestra aplicación de votación usando WAMP y veremos con precisión cómo WAMP también maneja los RPC.

     

    Actualizaciones de votación en vivo: vote usando WebSockets y WAMP

    Examinaremos más de cerca la funcionalidad de mensajería requerida por la aplicación de votación y repasaremos cómo implementarla en el navegador y en el servidor. Para mantener las cosas lo más simples posible, el código back-end también estará en JavaScript y se ejecutará en una pestaña del navegador.

    El "back-end en el navegador" es posible porque los clientes del navegador pueden registrar procedimientos para llamadas remotas como cualquier otro cliente WAMP. Esto significa que, dejando de lado las consideraciones de persistencia y rendimiento, el código del navegador es tan capaz como el código que se ejecuta, por ejemplo, en Node.js. Para nuestro navegador de demostración, el rendimiento es perfectamente suficiente.

    El código completo para la demostración de votación está disponible en GitHub, incluidas instrucciones sobre cómo ejecutarlo y el enrutador WAMP utilizado (Crossbar.io). Todo lo que necesita para ejecutar la demostración es gratuito y de código abierto.

    Incluyendo una biblioteca WAMP

    Lo primero que debemos hacer en nuestro código es incluir una biblioteca WAMP. Usaremos Autobahn|JS.

    Para desarrollo y pruebas en el navegador, simplemente inclúyalo así:

    script src="https://autobahn.s3.amazonaws.com/autobahnjs/latest/autobahn.min.jgz"/script;

    (Esta versión no permite la implementación en un sitio web de producción y está limitada a descargas desde páginas alojadas localhosten una IP de red local, como las del 192.168.1.xrango).

    Estableciendo una conexión

    Ahora necesitamos establecer una conexión con el enrutador WAMP:

    var connection = new autobahn.Connection({ url: "ws://example.com/wamprouter", realm: "votesapp"});

    El primer argumento es la URL del enrutador WAMP. Esto usa el wsesquema, en lugar del httpque estamos acostumbrados, porque WAMP usa WebSockets como transporte predeterminado. WebSockets proporciona una conexión bidireccional persistente, que permite la inserción desde el servidor sin ningún tipo de piratería. Además, no se transfieren encabezados HTTP con cada mensaje, lo que reduce significativamente la sobrecarga en la conexión. WebSockets es compatible con todos los navegadores modernos.

    Para el segundo argumento, debemos elegir un “reino” al que esté vinculada esta conexión. Los dominios crean dominios de enrutamiento separados en el enrutador, es decir, los mensajes se enrutan solo entre conexiones en el mismo dominio. Aquí, estamos usando un reino específicamente para la demostración de votación.

    El connectionobjeto que hemos creado permite adjuntar dos devoluciones de llamada, una para cuando se haya establecido la conexión y otra en caso de que el establecimiento de la conexión falle o la conexión se cierre más adelante.

    Se llama al onopensiguiente controlador al establecer la conexión y recibe un sessionobjeto. Pasamos esto a la mainfunción que llamamos aquí y que contiene la funcionalidad de la aplicación. El sessionobjeto se utiliza para las llamadas de mensajería WAMP.

     

    connection.onopen = function (session, details) { main(session);};

    Para que todo funcione, finalmente necesitamos activar la apertura de la conexión:

    connection.open();

    Registrar y llamar a un procedimiento

    El front-end enviará votos llamando a un procedimiento en el back-end. Primero definamos la función que maneja un voto enviado:

    var submitVote = function(args) { var flavor = args[0]; votes[flavor] += 1; return votes[flavor];};

    Todo lo que esto hace es aumentar el recuento de votos para el sabor de helado y devolver este número incrementado.

    Luego registramos esta función con el enrutador WAMP para que sea invocable:

    session.register('com.example.votedemo.vote', submitVote)

    Al registrarlo, le asignamos un identificador único que se utiliza para llamar a la función. Para ello, WAMP utiliza URI expresados ​​en notación de paquete Java (es decir, comenzando con el TLD). Los URI son prácticos porque son un patrón bien establecido y permiten separar fácilmente el espacio de nombres.

    Eso es todo por el registro. La submitVotefunción ahora puede ser llamada externamente por cualquier cliente WAMP (autorizado) conectado al mismo dominio.

    Llamar a la función desde nuestra interfaz se hace así:

    session.call('com.example.votedemo.vote',[flavor]).then(onVoteSubmitted)

    Aquí, el retorno de la submitVotefunción se pasa al onVoteSubmittedcontrolador.

    Autobahn|JS hace esto no mediante el uso de devoluciones de llamada convencionales, sino con promesas : devuelve session.call inmediatamente un objeto que eventualmente se resuelve cuando regresa la llamada y luego se ejecuta la función del controlador.

    Para el uso básico de WAMP y Autobahn|JS, no necesita saber nada sobre promesas. Tal como se usan anteriormente, puedes considerarlos como nada más que una notación diferente para devoluciones de llamada. Sin embargo, si está interesado en aprender más, el artículo de HTML5 Rocks es un buen lugar para comenzar.

    Suscripción y publicación de actualizaciones

    Pero ¿qué pasa con la actualización de los otros clientes? Después de todo, eso es lo que AJAX no hace y es por eso que estamos aquí en primer lugar.

    Para recibir actualizaciones, un cliente debe decirle al enrutador WAMP qué información le interesa suscribiéndose a temas. Entonces, nuestra interfaz hace esto:

    session.subscribe('com.example.votedemo.on_vote', updateVotes);

    Simplemente estamos enviando el tema (nuevamente, un URI) y una función para ejecutar cada vez que se recibe un evento para el tema.

    Todo lo que queda por hacer es enviar las actualizaciones de votación desde el servidor. Para hacer esto, simplemente construimos el objeto de actualización que queremos enviar y luego lo publicamos en el mismo tema al que se suscriben nuestros navegadores.

    Esto debe ser parte del procesamiento de votos. Entonces, agreguemos esta funcionalidad a la submitVotefunción que registramos anteriormente, que ahora se ve así:

    var submitVote = function(args, kwargs, details) { var flavor = args[0]; votes[flavor] += 1; var res = { subject: flavor, votes: votes[flavor] }; session.publish('com.example.votedemo.on_vote', [res]); return votes[flavor];};

    Bueno, eso es todo: tanto el envío de votos al backend como las actualizaciones de votos para todos los navegadores conectados, manejados por un único protocolo. Realmente no hay más uso básico de WAMP que esto.

    Resumen

    WAMP unifica la mensajería de su aplicación: con RPC y PubSub, debería poder cubrir todo lo que su aplicación necesita. Con WebSockets, esto se hace mediante una conexión única, bidireccional y de baja latencia al servidor, lo que ahorra recursos del servidor, reduce el tráfico de cables y permite tiempos de ida y vuelta muy cortos. Debido a que WAMP es un protocolo abierto y existen implementaciones para múltiples idiomas, usted tiene la opción de elegir tecnología de back-end y puede extender su aplicación más allá de la Web a clientes nativos.

    WAMP facilita la creación de aplicaciones web modernas y reactivas con excelentes experiencias de usuario y actualizaciones en vivo desde el servidor, y su extensión más allá de la Web.

    Notas finales

    • “Vote”, Crossbar.io Una versión en vivo de la demostración de votación
    • “¿ Por qué WAMP? ”, WAMP El razonamiento detrás del diseño de WAMP
    • "Libere su código: backends en el navegador", Alexander Gödde, Tavendo Una publicación de blog sobre cómo la simetría en WAMP afecta dónde puede implementar código
    • “WebSockets: ¿Por qué, para qué y puedo usarlo?” Alexander Gödde, Tavendo Una breve descripción general de WebSockets
    • “WAMP comparado” WAMP Una comparación de este protocolo de mensajería con otros
    • Crossbar.io Primeros pasos con este enrutador de aplicaciones unificado

    Otras lecturas

    • Un flujo de trabajo simple desde el desarrollo hasta la implementación
    • Cualidades de las implementaciones de Good Flux
    • Realidad aumentada simple con OpenCV, Three.js y WebSockets
    • Realidad aumentada simple con OpenCV, Three.js y WebSockets

    (ml, al, mrn)Explora más en

    • Codificación
    • AJAX
    • javascript
    • API





    Tal vez te puede interesar:

    1. ¿Deberían abrirse los enlaces en ventanas nuevas?
    2. 24 excelentes tutoriales de AJAX
    3. 70 técnicas nuevas y útiles de AJAX y JavaScript
    4. Más de 45 excelentes recursos y repositorios de fragmentos de código

    Por qué AJAX no es suficiente

    Por qué AJAX no es suficiente

    Lo que resolvió AJAXLo que queda sin resolverPubSub: actualizaciones de una a muchas¿Dos patrones de mensajería, dos tecnologías?WAMP: RPC y PubSubActualiz

    programar

    es

    https://pseint.es/static/images/programar-por-que-ajax-no-es-suficiente-866-0.jpg

    2024-05-20

     

    Por qué AJAX no es suficiente
    Por qué AJAX no es suficiente

    Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente

     

     

    Update cookies preferences