La historia de las Arquitecturas web es ya muy amplia . Hemos pasado por muchos posibles enfoques y soluciones sobre como construir una aplicación web y siempre llegan nuevas ideas que hacen al sector evolucionar. Vamos a echar un vistazo a los diferentes enfoques que se han producido en los últimos 20 años.
El Modelo cero y el código spaguetti
Esta es una forma de llamar a las soluciones iniciales cliente/servidor en las que tenemos una página JSP/ASP/PHP que se conecta a una base de datos y genera un nuevo contenido html. Es código spaguetti, el que nadie quiere tener que pero que en su momento se usó mucho. A día de hoy lo puedes encontrar en más sitios de los que se piensa. Como ventaja fundamental destaca su sencillez a nivel de arquitectura y como desventaja su poca flexibilidad y nula capacidad de reutilización.
El Modelo 1
Este fue un salto importante , promueve la modularización y el uso de componentes a través de la programación orientada a objeto. Fue desde mi punto de vista un gran salto. Hay enfoques tipo Rails que se apoyaron más en un patrón tipo Active Record y otros en Servicios y Repositorios como Spring. La clave fundamental es generar componentes en la capa de backend y aumentar la reutilización de esa parte.
El modelo 2 ( MVC)
Quizás para mucha gente el modelo más importante, se apuesta por la separación de responsabilidades entre Vista , Controlador y Modelo. Prácticamente todos los frameworks web han implementado este enfoque de una forma u otra. Ejemplos son: Struts en Java , ASP.NET en Microsoft o Laravel en PHP.
El Modelo MVC 2 FrontController/Enrutador
Una evolución importante del modelo MVC fue el modelo MVC 2 o de FrontController que apuesta por una arquitectura en la que únicamente hay un controlador principal y gestiona todo a través de acciones. Esta es un poco la idea de muchos de los frameworks modernos con el concepto de router en la capa de presentación. El enfoque más clásico puede ser Struts en el lado del servidor o Spring MVC.
Arquitecturas Web y Ajax
Hasta ese momento todas las evoluciones se produjeron del lado del servidor. El lado cliente tenía pocas novedades. Es en esta situación cuando surge AJAX como tecnología para mejorar el rendimiento entre cliente y servidor. Esto supuso una verdadera revolución a la forma de programar.
Arquitecturas Web y SPA
Con la llegada del mundo móvil y la necesidad de tener las aplicaciones web cada vez más desconectadas surgen las arquitecturas SPA (Simple Page Application) . Su propuesta principal es dar mayor responsabilidad al navegador y que el se encargue de cargar las vistas y datos utilizando AJAX.
Arquitecturas SPA MVC
Poco a poco el lado cliente comienza a tener más peso en los desarrollos y se necesita organizar mejor el código de JavaScript . Aparecen los primeros frameworks MVC de cliente como Backbone.js que permiten dividir las responsabilidades de la misma forma que en el servidor.
Arquitecturas SPA MVC y uso de componentes
Estas arquitecturas empiezan a madurar rápidamente y aparecen tecnologías como Angular.js que promueve el uso del modelo MVC y la utilización de componentes en capa de presentación . Aparecen librerías complementarias como React que se centran en estos últimos.
Arquitecturas Web Isomórficas
Ahora mismo estamos entrando en otra fase , comienza a llegar el JavaScript Isomórfico . Si nos fijamos en el último diagrama la parte cliente y la parte servidor son muy parecidas. ¿Qué sucedería en el caso de que ambas partes estuvieran implementadas en JavaScript? . Pues que probablemente mucho código se podría compartir y según se ejecutara la aplicación en cliente o en servidor el comportamiento variaría.
Este es un pequeño resumen de las diferentes arquitecturas que hemos estado usando a la hora de desarrollar aplicaciones web y las que usaremos.
Otros artículos relacionados : Java y su evolución , Arquitecturas SPA
hola me pueden explicar lo de ajax y lo de arquitectura web
Ajax es la tecnología que permite cargar dinamicamente contenido en una pagina html, es decir la pagina varía su contenido sin ser recargada
A veces me da un poco de risa leer estos comentarios, polymer se nota que lo unico que sabes es jsf y eso te va a costar mucho al cambio, he trabajado en verizon por 5 años en proyectos con desarrolladores en la India, digamos que era una competencia, los mejores resultado obtenidos en nuestras aplicaciones han sido utilizando javascript, hablando de javascript independientemente que sea angular, react, ext, etc, lo mejor que ahora hacemos es aprovechar el procesamiento del lado del cliente eso disminuye enormemente tus costos aparte que si usas una buena arquitectura de cache tus app van… Read more »
De la India ya me dirás el nivel de ingeniería del sofware que hay detrás de outsourcing en la India.. Por cierto JSF hace lo mismo que Angular en su versión 2.2, es decir te permite actualizar la web por AJAX además lo hace de una forma más elegante y con mejor rendimiento ya que Angular mantiene una cola de eventos de todo lo que puede actualizarse y comprueba cada vez que el usuario interactua, en JSF simplemente indicas donde quieres que ocurra eso más latoso en código pero más eficiente. Lo mejor de todo que Angular cambio radicalmente separandose… Read more »
Genial tu artículo. Gracias por compartirlo con todos nosotros.
Hola, muy bueno el articulo.
Me preguntaba.., porque no esta la arquitectura basada en microservicios.
Muchas gracias.
Si que debería haberla incluido , es cierto que no aporta patrones directos directos pero es un cambio de paradigma 🙂
A mi me toco desde el modelo MVC 2 con JSF, descance en paz richfaces (cuando lo desconecten)
JSF siempre ha sido duro , ahora mismo deben quedar prime faces como lo más utilizado dentro de ese enfoque
Mirando Google trends Primefaces está muy por encima y en alza… , con respecto a JavaScript todo el mundo piensa que renderizar en el cliente con Angular va a ser rápido y no lo es, requiere más JavaScript en el cliente para cargar la web, lo que la hace más lenta y no sólo eso ejecutar JavaScript para cargar los datos del servidor y renderizarlos utilizando más JavaScript, por no decir que Google aún no es muy bueno leyendo JavaScript y en móviles no existe un engine optimizado para que JavaScript se ejecute de una manera fluida. Cuidadito con abusar… Read more »
Muchas gracias por el aporte 🙂 , muy interesante la verdad, siempre se agradecen otros puntos de vista y si que creo que primefaces es la tecnología que destaca más de todas las implementaciones de JSF
Es un buen comentario Polymer, pero creo que se nota un poco esa resistencia al cambio, nosotros en nuestra empresa por ejemplo no cambiamos a desarrollar con Angular o algún otro framework MVC en la vista porque lo hiciera más rápido, aunque si creemos que trae un montón de beneficios en esa parte, por ejemplo, no necesitamos servidores tan potentes porque se deja buena responsabilidad al cliente, y aunque fuera algunos milisengundos más lento en el cliente, este no lo notaria, pero ese tiempo multiplicado por millones en el servidor si que lo notarían los clientes. Pero bueno volviendo a… Read more »
Estás presuponiendo limitaciones en los desarrolladores, está claro que para una empresa es más fácil utilizar JavaScript en el cliente y el servidor, que buscar programadores expertos en Java y con buena capacidad para diseñar aplicaciones OO. Respecto a servidores también presupones limitaciones en el servidor pero las soluciones son erróneas yo no puedo creer que trasladar tiempo de cómputo en la parte cliente hará que la web sea más rápida, al contrario, el cliente no tiene motivos 1º para tener un PC potente, 2º seguramente esté en algún smartphone o laptop, renderizar en JavaScript hace muy muy pesada una… Read more »