Aplicaciones SPA versus MPA

Cual és el entorno actual?

En la actualidad existen una gran cantidad de frameworks y bibliotecas web. Muchos desarrolladores a veces desconocen las diferencias o no saben escoger el más adecuado para utilizar. A continuación se expone cuál es el más adecuado para el proyecto que se quiera realizar.

Así que en un principio parecen iguales pero la forma de diferenciarlos no está en lo que produce sino en cómo lo produce esto en los frameworks serían sus métodos de renderizado.  Se trata de cómo se procesan los archivos antes de crear páginas.

Así que vamos a diferenciar frameworks de server side rendering o template rendering y client Side rendering.

Un ejemplo a continuación, se supone que como desarrolladores freelance alguien está pagando por crear una tienda virtual para poder lograr esto primero veamos una de las primeras opciones el server Side rendering, el renderizado del lado del servidor significa en la práctica que cada vez que un usuario visita una URL una aplicación de servidor le responde con una página html en el ejemplo del E Commerce y cuando un usuario pide la página de productos o la página de un producto, el servidor le va a generar una página desde cero, es decir el servidor está generando múltiples páginas en cada URL visitada.

Es por esto que las aplicaciones utilizando este enfoque también se les llama multi-page applications o aplicaciones de múltiples páginas, entre algunos frameworks que entran en esta categoría podríamos encontrar a asp.net, el laravel, el django y ruby on rails y para crear la interfaz de html estos frameworks usan bibliotecas que se llaman motores de plantillas o template engines esos hacen que en el código de html se puede utilizar lógica extra como condicionales, bucles y funciones. Pero al final los frameworks los convertirá en html antes de enviarlos al cliente por ejemplo:

• En Django se utiliza Jinja 2. 
• En Laravel se utiliza Blade
• En Ruby se utiliza  Erb.

Aunque cualquier framework de backend puede utilizar múltiples motores de plantillas, por ejemplo en Go se utilizan los Go templates y en Node JS se puede utilizar cualquier motor de plantilla como Handlebars, por ejemplo. 

Como se hace uso de templates también es popular el término template rendering relacionado a esto. Este enfoque tiene ventajas en cuanto a seo, ya que como el html llega generado al navegador este puede leer el contenido y saber de qué se trata, haciendo que pueda rankear fácilmente en buscadores. Son más seguros, al estar toda la lógica en el backend.

El usuario solo ve el resultado final en el frontend. 

Tiene facilidad integrarse con base de datos y herramientas que requieran del sistema operativo al ya estar en un servidor y son fáciles de desplegar al estar toda la aplicación en el mismo proyecto pero como desventaja tenemos que la experiencia de usuario es más lenta al generarse una página en cada cambio de la URL cosa que tratan de resolver utilizando Ajax y bibliotecas de frontend de javascript como alpine.js htmx o incluso Jquery. Es vital aprender un lenguaje de servidor para poder crearlas y en aplicaciones complejas el tiempo de renderizado hace que la carga en el frontend sea más lenta. A pesar de que se pueda resolver en parte, con técnicas de caching, no todo se puede resolver de este modo ya que justamente se necesitan datos que cambian constantemente de forma dinámica. Con estos frameworks se puede crear la tienda virtual entera y es cómodo de empezar a desarrollar pero si el proyecto requiere de ir mejorando la interfaz de usuario con más interactividad y funcionalidad, el usar este enfoque es más complicado al tener en cuenta siempre que la lógica se debe ejecutar desde el servidor. Este método renderizado fue una de las primeras formas para crear aplicaciones web y al día de hoy sigue siendo utilizado principalmente en CMS basados en PHP como wordpress, Adobe, E Commerce, drupal, Joomla o usando Frameworks que se han mencionado antes. Se puede crear un proyecto desde cero y que esté basado en multi page application, sin embargo si se crea una interfaz compleja lo mejor es usar un framework de lado cliente y dejarle el backend solo la tarea de comunicarse con la base de datos. Aquí es donde entra la otra técnica que sería el client Side Rendering desde el año 2009 con la mejora de motores de javascript en el navegador, el rendimiento de aplicaciones de javascript mejora mucho, apareciendo frameworks y bibliotecas de javascript que permiten crear aplicaciones más grandes entre estos estaban Angulars.js, React.js., ember, Blackbone.js. Desde entonces han ido apareciendo y desapareciendo más frameworks. Actualmente los más populares son Angular, React, Vue y Svelte. El objetivo de estos frameworks es que la interfaz se genere completamente en el frontend y que el backend solo envíe los datos de un formato Json de tal forma que el backend ya no tiene que estar enviando archivos html en cada cambio de URL.

Esto funciona así; Cuando un usuario visita la URL de productos lo primero que hace el servidor es enviarle un archivo de javascript y esto genera toda la interfaz en el navegador luego a partir de aquí la interfaz hace peticiones al backend con los datos que requiera. El backend responde con los datos en formato Json y la interfaz hace uso de estos datos y actualiza la página, sin necesidad de cambiarla. Es decir todo el proyecto es una sola página y el resto simplemente esa actualización de datos. Es por esto, que las páginas creadas con este enfoque, se les llama single page applications o aplicaciones de una sola página. La ventaja de este enfoque es que la interacción del usuario, con la interfaz, es mucho más rápida. La experiencia de usuarios es más rápida porque los datos son más ligeros de enviar y solo se necesitan hacer peticiones al backend para que las interfaces cambian sin la necesidad de pedir páginas html al servidor. También es fácil de optimizar consultas en el backend ya que solo hay que responder datos Json sin nada de html. Se pueden crear aplicaciones más complejas, si se trata de un proyecto entero de frontend por separado. La desventaja es que, es más difícil mejorar el seo, como toda la interfaz se genera desde el frontend cuando carga una página en el navegador esta, al no un archivo html ya no sabe el contenido que está dentro, lo que significa que es más difícil que aparezcan los motores de búsqueda. El desarrollo también se divide en dos proyectos que se deben mantener backend y frontend. Cada uno puede tener distintos conjuntos de herramientas además si se tienen nociones de lenguaje como Python, PHP, Ruby, C Sharp y Java ahora también hay que tener nociones de Javascript para poder crear la interfaz en el frontend. En el despliegue  significa que se obtienen dos opciones para poder desplegar los proyectos.

Se pueden desplegar de forma conjunta o puedes desplegarlos por separado.Se puede seguir utilizando framework que se ha mencionado anteriormente, solo que ahora se usa para comunicarse con la base de datos, y enviar simplemente datos al cliente.

A este tipo de aplicaciones backend se les llama Rest Api. 

Las aplicaciones que usan este enfoque son básicamente las redes sociales y herramientas que usas a diario en la web como Facebook, Instagram, tiktok, YouTube y muchas otras más. 

Hay desarrolladores frontend que solo han estudiado frameworks de frontend y complementan el backend, con servicios como Firebase, Aws Amplify, o Supabase que permite crear el backend. Estos cobran mensualmente su uso. Hace muchos años atrás sucedían mucho las MPA para crear aplicaciones web junto a bibliotecas como Jquery. Actualmente este enfoque ya no es tan popular, debido a las mejoras constantes de los entornos web. Pero en un entorno laboral es posible que utilicen MPA unidos, que usan este enfoque. Aunque si se desea tener lo mejor de ambos mundos, también hay un término, que se llama Server Side Rendering pero utilizado en el frontend. Esto está relacionado a la primera carga de la aplicación, es decir si se envía un Javascript al frontend este ya no tan solo va a generar la interfaz sino que, trae un archivo html ya  preparado y esto sirve para que los buscadores puedan ver el contenido inicialmente.