TeamGenik está hecho con Elixir y Phoenix LiveView

Lenguaje de programación Elixir

El núcleo del sistema de TeamGenik está escrito en Elixir, un lenguaje de programación funcional.

Elixir es un nuevo idioma nacido en 2012. Menos famoso que C nacido en 1972, Python nacido en 1991, Java nacido en 1995, Ruby, etc. Sin embargo, está ganando popularidad en los campos Web e IoT. Programming Languages InfoQ Trends Report de InfoQ publicado en octubre de 2019 afirma que Elixir ha entrado en la fase Innovador.

Marco de Phoenix

TeamGenik utiliza el Phoenix Framework (Phoenix), un marco de desarrollo de aplicaciones web basado en Elixir.

Phoenix está fuertemente influenciado por Ruby on Rails. En particular, los mecanismos de enrutamiento y controlador son muy similares. La biblioteca Ecto que Phoenix usa para las operaciones de la base de datos es similar a Active Record. Para aquellos de nosotros familiarizados con Ruby on Rails, Phoenix fue una elección muy natural.

Phoenix LiveView

TeamGenik usa Phoenix LiveView para representar el código HTML. Phoenix LiveView genera código HTML en dos pasos:

• En respuesta a eventos que ocurren fuera de la aplicación, el estado de la aplicación se convierte en un nuevo estado.  
• Detecta cambios en estado y genera código HTML.

Phoenix LiveView proporciona una conexión constante entre el navegador y el servidor a través de WebSocket.

Phoenix LiveView envía solo la diferencia generada en el código HTML debido al cambio en estado al navegador, por lo que la cantidad de comunicación entre el navegador y el servidor puede mantenerse baja.

Nuevas tendencias en el desarrollo de aplicaciones de una sola página (SPA)

TeamGenik está construido como una aplicación de página única (SPA). En otras palabras, en lugar de causar una transición de pantalla cada vez que un usuario hace clic en un enlace, una parte de la pantalla se cambia en el acto.

A fines de la década de 2010, el desarrollo de SPA floreció y los marcos de JavaScript como React, Angular y Vue se hicieron ampliamente utilizados.

Sin embargo, elegimos Phoenix LiveView en anticipación de la marea después de la década de 2020. El desarrollo de SPA con Phoenix LiveView está centrado en el lado del servidor y difiere mucho de los convencionales.

La figura anterior compara la configuración del sistema usando el marco de JavaScript con la configuración del sistema usando Phoenix LiveView. Las dos elipses escritas como State representan los datos (estado) que posee la aplicación. El código HTML se genera a partir de este State en cualquier configuración del sistema. Cuando el State cambia debido a las operaciones del usuario, el código HTML cambia en consecuencia y la pantalla del navegador cambia.

En la configuración del sistema de la izquierda, State está en el navegador. Para reescribir este State y generar código HTML desde State, se ejecutará un gran programa JavaScript en el navegador. Por otro lado, en la configuración del sistema con Phoenix LiveView a la derecha, State está en el lado del servidor. El programa Elixir se ejecuta en el servidor, reescribe State y genera código HTML desde State. Se conecta con un pequeño programa JavaScript que se ejecuta en el navegador mediante WebSocket, recibe eventos del navegador y envía diferencias de código HTML al navegador.

Hay cuatro razones principales por las cuales el enfoque del desarrollo se ha desplazado desde el front-end (lado del navegador) al lado del servidor:

• La programación usando JavaScript, un lenguaje no funcional, es casi innecesario. En otras palabras, casi todo el sistema se puede desarrollar en un tipo de lenguaje (Elixir).
• No es necesario implementar una API que reciba consultas de la parte delantera.
• Ya no es necesario crear el mismo tipo de funciones (validación, etc.) en el front-end y el lado del servidor.
• Los usuarios malintencionados no pueden analizar el código fuente de JavaScript para obtener ataques al sistema pistas o revelar secretos comerciales.

Por supuesto, hay cosas que pierdes. Mover parte del procesamiento que se realizó en la computadora del usuario al lado del servidor significa aumentar la carga en el servidor. También aumenta la cantidad de comunicación que se produce entre el front-end y el lado del servidor. Además, aumenta la cantidad de comunicación entre el front-end y el lado del servidor. Además, cuando el navegador y el servidor están separados entre sí en una red, el usuario siente una respuesta lenta.

Creemos que estas deficiencias se superarán a medida que avance el desarrollo y la aceptación de Phoenix LiveView. Después de todo, la versión 0.1 se lanzó en agosto de 2019 y aún no ha alcanzado la versión 1.0.

LiveView Socket tiene una correspondencia uno a uno con los navegadores

En los sistemas web tradicionales, una pequeña cantidad de aplicaciones web responden al acceso desde una gran cantidad de navegadores (ver más abajo).

Una aplicación web procesa las solicitudes de varios navegadores en orden. Además, no es constante qué aplicación web es responsable de las solicitudes de un determinado navegador. Como resultado, las aplicaciones web no pueden contener datos específicos del navegador específicos. Los datos se almacenan en la base de datos o en el State en el navegador.

Por otro lado, en el sistema que usa LiveView, LiveView Socket tiene una correspondencia uno a uno con el navegador como se muestra en la siguiente figura. Ambos están siempre conectados a través de WebSocket.

Cada LiveView Socket es tan pequeño que puede continuar ejecutando miles o incluso decenas de miles en un solo servidor. Y cada LiveView Socket tiene un State único.

De esta manera, el uso de Phoenix LiveView cambia fundamentalmente la forma en que se crean los sistemas web.