Volver al blog

Evolución web: de CGI a Websockets (y cómo te ayudará a monitorear mejor tu infraestructura en la nube)

Evolución web: de CGI a Websockets (y cómo te ayudará a monitorear mejor tu infraestructura en la nube)

En los últimos años, websockets se han convertido más o menos en un componente estándar en todas las aplicaciones web modernas, pero ¿por qué es así y cómo hemos llegado hasta aquí? Más importante aún, ¿cómo pueden los websockets ayudarle a monitorear su infraestructura en la nube de manera más eficaz?

Debido a la naturaleza técnica de este tema, es posible profundizar mucho en los detalles. Pero intentaré mantener las cosas a un nivel relativamente alto y centrarme en los beneficios para los usuarios de nuestra infraestructura en la nube.

La antigua forma de hacer las cosas

En los inicios de la web, todo era estático. Si necesitaba interactuar con un servidor (más allá de renderizar una página estática), tenía que ejecutar algún tipo de script CGI. Un ejemplo típico de esto era algo como el registro en una lista de correo. Introduce su dirección de correo electrónico y pulsa 'enviar', luego ve una página independiente que procesa los datos. Esto a su vez era un script que tomaba la entrada y la procesaba en el servidor.

PHP Logo
Para la década de los 90, la programación del lado del servidor había evolucionado significativamente. La tecnología había pasado de ejecutar tareas simples a crear páginas totalmente dinámicas. Lenguajes de programación como PHP, y tecnologías del lado del servidor más avanzadas, como mod_perl, permitieron una programación web mucho más sofisticada. Aunque estas tecnologías fueron significativas, seguían girando en torno al concepto de generación de página al cargar. Una vez cargada, había que recargar toda la página para actualizar el contenido.

A medida que la web evolucionaba, entramos en la AJAX/Web 2.0-era de los años ’00, las páginas web se volvieron mucho más dinámicas y adaptativas. Ya no era necesario recargar la página para actualizar el contenido en la pantalla. Todo lo que tenía que hacer era activar algunas acciones de JavaScript. Muchas páginas AJAX todavía funcionaban con PHP, pero con la introducción de JavaScript del lado del cliente, se pudieron hacer más dinámicas.

Introducción a AJAX

Con la introducción de AJAX, se volvió cada vez más importante la comunicación continua entre el servidor y el cliente. De repente, se podía tener una cantidad significativa de llamadas a la API generadas por un usuario de forma individual en una página determinada. Hacemos esto mediante un método de 'extracción' (pull), lo que significa que el cliente solicitaba actualizaciones al servidor a un intervalo determinado (o en función de alguna acción).

A medida que entramos en los años ’10, era común que las páginas web estuvieran completamente divididas entre el front-end (HTML/JavaScript/CSS) y el back-end (Ruby on Rails, Django etc.), que a menudo se alojaba en servidores diferentes. La forma en que el front-end se comunicaba con el back-end era a través de una API. El front-end era más o menos estático. Con esta tendencia, realizar llamadas a la API al servidor se convirtió en un cuello de botella importante. Si tenía que obtener diez cosas diferentes del servidor, a menudo significaba que necesitaba realizar diez llamadas a la API diferentes, y cada llamada conllevaba una sobrecarga y latencia significativas.

La forma moderna

HTML5 LogoPara abordar este problema de latencia y sobrecarga, se introdujeron los websockets como parte de HTML5 y se implementaron en todos los navegadores modernos. Al contrario del enfoque tradicional de 'extracción' (es decir, el cliente solicita cambios al servidor), un websocket es, como su nombre indica, un socket donde el servidor puede 'enviar' (push) cambios al cliente. Por lo tanto, si no hay cambios, no hay necesidad de ninguna comunicación. Además, dado que el cliente puede comunicarse directamente con el servidor sin la sobrecarga adicional de abrir y cerrar conexiones, la aplicación se vuelve mucho más receptiva.

Así es exactamente como está construida nuestra propia aplicación web. La aplicación real es una página estática que abre una conexión websocket con la API. Una vez que este socket está abierto, la aplicación web puede recibir notificaciones del servidor con los cambios. Seguimos enviando comandos a la API RESTful, pero enviamos notificaciones desde el servidor al cliente utilizando el websocket.

No solo para páginas web

Si bien el caso más obvio para recibir actualizaciones mediante un websocket es a través de un navegador, también existen otros casos. Tal vez esté escribiendo una herramienta que monitorea los cambios en su arquitectura y desencadena acciones basadas en esto. En ese caso, puede acelerar significativamente su aplicación utilizando nuestro websocket.

En nuestra biblioteca de Python, pycloudsigma, contamos con soporte integrado para websockets. Incluso tenemos un sencillo ejemplo de cómo puede utilizar esto para monitorear las actividades de websocket con solo unas pocas líneas de código. Aquí tiene una demostración rápida de monitor_websocket_activity.py que monitorea las acciones desencadenadas por la entrada del usuario en la aplicación web.
Para obtener más información sobre nuestros servicios, consulte nuestras Características.

author

Viktor Petersson

Autor · CloudSigma

Preslav Dobrev es diseñador creativo en CloudSigma, centrado en una identidad empresarial coherente mediante el uso de canales de marketing tradicionales e innovadores. Es experto en fusionar la visión artística con el marketing estratégico para crear narrativas de marca impactantes.

Comentarios

Aún no hay comentarios. Sea el primero.