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 a toda maquina, claro depende mucho de la arquitectura pero creo que hoy en día hablar de net, java, php etc etc es como hablar de lotus, pascal en tiempos de los antes mencionados cambia el chip compadre y has upgrade.
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 de JavaScript por problemas de escalar el código, los que usaron Angular JS o Angular con una burrada de código me pregunto cómo pensarán cambiar a Angular 4, mientras JSF sigue vigente vuestra app de un año a otro hizo deprecated.
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 con arquitecturas modernas, todas tienen una utilidad por muy viejas o nuevas que sean y por cierto JSF se utiliza en Ebay y Amazon, su última versión no es precisamente una tecnología antigua…, esto no es una pasarela de moda :), si tienes datos conocidos de antemano sin necesidad del servidor, el cliente tiene sentido, al contrario será si necesitas datos que deben estar actualizados y dependan del servidor.
No obstante para webs que necesita SEO y una carga rápida, Twitter renderiza en el servidor 1/5 de lo que tardaría si pusiera la carga en el cliente, por no decir que Google indexa HTML al 100%, hay queda eso.
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 nuestra razón principal, la cual es que dividimos el trabajo del desarrollo, podemos tener dos aplicaciones diferentes con equipos diferentes para hacer desarrollo y mantenimiento, es más fácil conseguir desarrolladores que sean capaces de abordar uno de los dos escenarios, además podemos reutilizar tanto nuestro back como front mejor, en jsf por ejemplo no tengo como reutilizar mi lógica del back cor otros, a menos que ingrese nuevos paradigmas y esto se desviaría un poco de la tecnología, en realidad podría dar muchas más razones, pero creo que es suficiente para explicar que aunque no creo que en entornos normales sea verdad que renderizar en el cliente se mas lento que en back, si así fuera, aun así lo escogería.
Salim Castellanos.
Saludos.
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 web, el servidor simplemente puede utilizar Ajax para las partes dinámicas y sin necesidad de hacer cargas en JavaScript en el cliente, por no decir que con Angular estás jodiendo el SEO de una web.
La capacidad de los servidores es algo que puedes controlar, en que dispositivo se conecta el usuario no, actualmente todos conectamos con smartphone o laptop y generalmente un laptop suele ir en modo de ahorro de energía y se nota la diferencia, los usuarios no tienen paciencia para web lentas y menos esperar que ellos tengan el hardware que tú no estás dispuesto a poner.