Arquitecturas Web y su evolución

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.

arquitecturas web spaguetti

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.

arquitecturas web modelo1

 

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.

arquitecturas web modelo2

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 modelo mvc2

 

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 ajax

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 web spa simple

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 web spa2

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 spa componentes

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.

arquitecturas web isomorfica

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

About Cecilio Álvarez Caules

Cecilio Álvarez Caules Sun Certified Enterprise Architech (J2EE/JEE).

9 Responses to Arquitecturas Web y su evolución

  1. Jesús Perales 30 septiembre, 2016 at 16:52 #

    A mi me toco desde el modelo MVC 2 con JSF, descance en paz richfaces (cuando lo desconecten)

    • Cecilio Álvarez Caules 30 septiembre, 2016 at 19:32 #

      JSF siempre ha sido duro , ahora mismo deben quedar prime faces como lo más utilizado dentro de ese enfoque

      • Polymer 2 octubre, 2016 at 23:09 #

        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.

        • Cecilio Álvarez Caules 3 octubre, 2016 at 17:04 #

          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

        • Salim Castellanos 6 octubre, 2016 at 17:50 #

          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.

          • Polymer 23 octubre, 2016 at 4:49 #

            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.

  2. wicope 1 octubre, 2016 at 19:48 #

    Hola, muy bueno el articulo.

    Me preguntaba.., porque no esta la arquitectura basada en microservicios.

    Muchas gracias.

    • Cecilio Álvarez Caules 2 octubre, 2016 at 17:58 #

      Si que debería haberla incluido , es cierto que no aporta patrones directos directos pero es un cambio de paradigma 🙂

  3. Hendrick 2 enero, 2017 at 15:13 #

    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.

Deja un comentario

Uso de cookies

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.plugin cookies