Autor: Iñigo Serrano

En este repaso a la arquitectura web de camino a soluciones como AngularJS la siguiente etapa después del DHTML fue el empleo de ajax y su correspondiente mofa fácil con el ajax pino…

Recordemos que pasamos de páginas web muy estáticas y muy influenciadas por marketing y diseño a páginas con un mayor grado de dinamismo .

Pero en este planteamiento se seguía yendo mucho al servidor y cada vez que se iba se devolvía toda la página. Había formas de hacer llamadas asíncronas, como utilizando applets o con frames, pero eran soluciones muy rudimentarias hasta que apareció ajax y puso el asincronismo de moda..

El empleo del ajax en estas primeras épocas permitió que ciertas tareas, normalmente auxiliares que hay que ser prudentes con las cosas nuevas, se hiciesen en segundo plano. Tareas como verificar unos datos, recargar combos, actualizar pequeñas áreas de la página, etc.

Se empezó a ganar algo mas de velocidad, ya que no se tenia que ir al servidor y regenerar toda la página. Se fue reduciendo así mismo las ocasiones en que se necesitaba gestionar el estado en el servidor. También se mejoró la percepción del usuario ya que no tenia una ventanita cada dos por tres indicándole que esperase que se estaba trabajando, porque se habia enviado la petición y el servidor le estaba devolviendo toda la página.

Pero había una pega, como toda tecnología nueva, estaba poco arropada, y había que andar lidiando con el objeto xmlrequest a mano, a bajo nivel y pegándose con las peculiaridades del javascript y del propio objeto de cada navegador. Y cuanto más lógica de presentación trasladas al navegador, más código javascript tienes…

En esta serie de entradas sobre la evolución de la arquitectura web, por lo menos la que yo he vivido, conté los inicios, estáticos mayormente, para ir entendiendo porque me parece interesante las soluciones estilo AngularJS.

Todavía muy influenciados por la parte de marketing y de diseño, la siguiente evolución grande que hubo fue el empleo de DHTML, es decir hacer un poco más dinámicas las webs, introduciendo más javascript y sobre todo las capas.

Esto permitía que las páginas/aplicaciones web empezasen a no necesitar el recurrir tanto al servidor. Podías presentar ciertas ventanas de confirmación o de pregunta mediante capas. Existía de antes la posibilidad de hacerlas en javascript, pero normalmente los clientes querían versiones más bonitas, que el cuadro que sacaban los navegadores.

Se había empezado a trasladar cierta lógica de presentación a donde se realiza la presentación, es decir al navegador. Esto hacia, que aparte de tener una mayor velocidad, por no ir a regenerar la página al servidor, la programación fuese más sencilla, ya que no había que mantener el estado en la presentación de esas ventanas.

Pero seguía habiendo mucha lógica de presentación que se realizaba en el servidor.

Hoy toca una entrada de abuelo cebolleta, porque en este proceso de actualización de planteamientos de arquitectura web que me ha permitido mi actual situación laboral, hay uno (AngularJS) que me está atrayendo bastante. Pero para entender el porque me parece interesante ir hacia ahí creo que es importante saber de donde venimos.

Originalmente, estoy hablando de finales del siglo pasado, no se manejaba el concepto de aplicaciones web, sino de páginas web. Es decir lo que se hacia eran páginas con cierto contenido dinámico. De hecho en esas épocas casi tenia más importancia la parte de márqueting y diseño que la programación.

Poco a poco se fue añadiendo cada vez más dinamismo a esas páginas.

Algunas de las características de ese tipo de «aplicaciones» Web:

– La lógica se manejaba en el servidor, porque había bastantes problemas con las compatibilidades entre navegadores, tanto a nivel de HTML como de Javascript. Así que se solía ir a lo seguro que era el servidor.

– Como la web estática empezó como una extensión del marketing de las empresas los clientes/usuarios se habían acostumbrado a interfaces bonitas, pero no había capas ni DHTML nada por el estilo. Así que todo iba al servidor.

– Cada vez que se necesitaba algo del servidor se devolvía toda la página actualizada, nada de enviar cachos. Eso hacia que el consumo de ancho de banda fuese alto. Tampoco era un problema excesivo porque solían ser aplicaciones auxiliares.

– El estado se mantenía en el servidor, porque como hemos comentado cada petición al servidor implicaba la regeneración de toda la página.

Hace unos meses empecé un proyecto personal para ir introduciéndome en el mundo del BigData/NoSQL y la nube.

Era una Prueba de Concepto (PoC) con intenciones de ver la viabilidad de la idea.

Lo hice con un planteamiento muy Google, es decir, la nube de Google y los frameworks de Google, con el GWT a la cabeza.

Pero últimamente estoy planteándome otros escenarios no tan «radicales» y que sean un poco más una evolución de los planteamientos ya conocidos. Sigo creyendo en que hay que seguir a los mejores pero también sin pasarse de frenada. Aunque me gusta mucho el planteamiento del GWT, no se que le veo, quizá un poco complejo de entender, sobre todo con el soporte de los históricos y las diferentes vistas.

Existe otro planteamiento, que en vez de ir a un modelo de componentes como GWT o JSF utiliza el planteamiento más tradicional del MVC, estilo Struts, vitaminado en la parte de presentación con librerías como jQuery o AngularJS.

La parte MVC es más conocida y el planteamiento de AngularJS me parece muy interesante como para hacer una prueba de concepto.

Además creo que es labor de un buen arquitecto plantear una solución acorde al problema, y no tanto dejarse llevar por modas o fanatismos tecnológicos.

Sigo con mi cruzada anti interfaces en proyectos normales Java con un consejo.

Si has hecho una interface y solo tienes una clase que implemente esa interface, quizá debieras reconsiderar si realmente necesitas una interface.

Dejo algunas reflexiones:

El recurso más utilizado para justificar estas prácticas tienen cierta relación con la adivinación. Pongo una interface y así en el futuro puedo cambiar la implementación.

Pero pregúntate. ¿Que posibilidad hay de que en el futuro se cambie esa implementación? ¿Cuanto te va a suponer de coste hoy esa flexibilidad futura? ¿Es previsible que tu organización cambie, por ejemplo de Oracle a MySQL?

Probablemente te des cuenta de que estás pagando un sobrecoste a día de hoy sin tener ninguna seguridad de que en el futuro lo vayas a recuperar.

Si aun así ves que es probable que pueda cambiar, hazte otra pregunta. ¿Necesito tener las dos implementaciones a la vez?

Lo normal es que no. Así que incluso con el empleo de la interface vas a tener que abrir el código para codificar una nueva implementación. ¿Que diferencia hay con simplemente coger la implementación vieja y cambiarla? Tienes una gestión de la configuración para no perder la versión vieja.

Si aun así en el futuro necesitases la interface y varias implementaciones, los entornos de desarrollo actuales soportan la refactorización y una de ellas suele ser el sacar interfaces de clases.

Así que ten en cuenta, a las interfaces les gustan las multitudes.

En las últimas entradas he hablado sobre el cacheo de datos con memcached y de ciertas flexibilidades en arquitecturas que no me gustan.

Pero con respecto a estos dos temas si hay una flexibilidad que me gustaba, aunque no he podido ponerla en práctica, por incompatibilidades de producto o más bien versiones de producto.

Uno de lo problemas que tiene el empleo de memcached, y otras soluciones similares, es que debes codificar el acceso a la caché. Eso implica que si quieres cambiar de opinión tienes que modificar el código y pasar por el consiguiente ciclo de pruebas.

En cambio con tecnologías como hibernate y JPA es posible hacer que ese cache sea transparente a nivel de código fuente, simplemente indicando en el fichero de configuración que tablas quieres cachear.

Esto permite cambiar de opinión con mucha mayor facilidad y cachear o descachear ciertas tablas según va evolucionando el uso de la aplicación.

En general me revienta las aplicaciones que tienen el doble de clases, una para la interface (llamemosla aaaaa) y otra para la implementación (dichosa aaaaaImpl). Cuesta horrores seguir el código. Y ni tan mal si ponen las dos clases en el mismo paquete, así están juntitas…

No es que esté en contra de este tipo de prácticas de IoC, que te dotan de más flexibilidad. De hecho he construido aplicaciones usándolas que mis compañeros de proyecto valoraron como muy buena idea.

Lo que me parece es que se están usando indiscriminadamente. Si, es otra entrada de arquitectura web y CRITERIO.

En una ocasión tuve que meterle mano a una aplicación, relativamente sencilla, pero que no me gustó nada como estaba hecha. Estaba realizada con spring y los consabidos Impl, muy flexible todo. Solo tenia un defecto, en mi opinión. Que donde realmente el usuario necesitaba flexibilidad, (recordamos: objetivo aportar valor al cliente) porque cada año cambia el funcionamiento, era para pegarse un tiro, absolutamente inmantenible. Solo un dato, para hacerse una idea, métodos de 17.000 líneas de código. Si, has leído bien y no, no se me ha colado un cero.

Pues eso CRITERIO.