Experiencias en el desarrollo de aplicaciones SPA corporativas

En la creación de aplicaciones corporativas al puro estilo ERP, la evolución de las diferentes capas del framework empleado deben sostenerse siempre y en todo momento actualizadas y consistentes (lease framework como conjunto de tecnologías y arquitectura empleada).

El inconveniente primordial es que las aplicaciones desarrolladas en este ambiente tienen un ciclo vital larguísimo y deben continuar lo más agnósticas posible a los cambios tecnológicos y la obsolescencia de muchas de las tecnologías actuales.

Cuando charlamos de desarrollo frontend, este propósito no es tan simple, puesto que el ecosistema medra y cambia a una velocidad mareante. Es precisamente por esto que la elección de una tecnología de frontend que resulte aproximadamente estable y que prosiga una evolución sana es esencial. A mi juicio, si hacemos aplicaciones ricas siguiendo los principios de las Single Page Applications, la resolución hoy no es para nada fácil.

Quizás en el trascurso de estos últimos años hayas evaluado para estos ambientes diferentes
soluciones con aproximadamente suerte, conque muchas de las opciones seguro te sonarán :)

El estado del arte

Para comprender los motivantes en el momento de escoger, podemos valorar diferentes escenarios (soy siendo consciente de que en estos escenarios nombraré solo una parte pequeñísima de los frameworks
que hay libres, conque no te ofendas si tu preferido no se halla entre ellos en tanto que
sencillamente cuento ciertos para dar contexto):

HTML ligero. Basado eminentemente en un maquetado HTML con o bien sin framework CSS adaptable que nos asista en el proceso (en esta parte hemos mejorado bastante merced a flexbox y un principio de grid css). Como ventaja tenemos la simplicidad y la dependencia de estándares de hecho y no de frameworks o bien implementaciones concretas. Por otro lado, en esta alternativa partimos de un binding bastante limitado con el DOM, en tanto que precisamos alguna capa que nos abstraiga de este acceso, haciéndolo menos explícito y más declarativo. Para la integración con componentes ricos y prácticamente para cualquier cosa, debemos usar librerías auxiliares.
Single Page Application ligero. Muy en la línea de la primera opción, mas con una mejor
integración con el DOM, del que ya no debemos preocuparnos. Perdemos el contacto directo con los
estándares y pasamos a fundamentarnos en algún género de framework. Un ejemplos de esta estructura podrían
ser librerías expertas en el manejo de la vista (V en MVC) como son React o bien Vue.js.
En cualquier de estos estos casos, la integración con componentes ricos, el routing en la aplicación, la carga de de módulos y muchas otras funcionalidades quedan fuera de la ecuación.
Single Page Application completo. Aparte de la integración con el DOM, en este escenario
disponemos de otros aspectos precisos en aplicaciones complejas como es el routing. Si charlamos de frameworks como Angular 1.X o bien 2.X, la una parte de contar con componentes ricos asimismo quedaría fuera del alcance del framework.
Single Page Application completo con componentes ricos. Recuerdo en un inicio opciones muy viejunas como qooxdoo, Dojo, SmartGWT o bien YUI. Ya hoy, estaríamos hablando de opciones como Sencha ExtJS.

En su instante y examinando las opciones libres para nuestro ambiente corporativo que estaba
más orientado a datos que otra cosa, apostamos por ExtJS tres.X allí por el dos mil nueve. Este framework venía de la evolución de YUI y reunía los componentes básicos que precisábamos en nuestro ambiente con una visión de uniformidad y soporte que hacía meditar en que su estabilidad y frecuencia de cambio iba a ser más fácil de administrar. Que inocentes éramos entonces …

La realidad

Aun escogiendo una solución muy enfocada al desarrollo de aplicaciones corporativas con todos
los aspectos que esto acarrea con respecto a estabilidad en el tiempo y demás, Sencha ExJS ha
sufrido una evolución trágica en los últimos tiempos, motivando cambios de gran calado en el paso a su versión cuatro, cinco y ahora seis, cosa que no ha sido nada simple de llevar ante multitud de aplicaciones desarrolladas en diferentes versiones y mucho trabajo de actualización entre exactamente las mismas.

Esta experiencia nos ha llevado a proseguir en la una parte del frontend uno de los mantras que tenemos
bien aprendidos en la una parte del backend: Defendámonos de los frameworks!!!

¿Qué estrategias hemos venido siguiendo para lograr defendernos de los cambios arbitrarios en los frameworks?

La primera de todas y cada una y en mi entender la más esencial, ha sido hacer que el desarrollo de
nuestras aplicaciones sea más fácil y productivo, desarrollando con el tiempo un set de componentes comunes que emplear en los diferentes proyectos. Cuanto más rico sea este set y menos utilicemos los componentes proveídos por el framework directamente, más fácil va a ser incorporar
funcionalidad nueva y actualizar las aplicaciones ante cambios de versiones.

Esta práctica va un tanto en la línea del principio de diseño que nos afirma reduce your API surface, y es que cuanto más nos resguardamos de los cambios de una librería de terceros con abstracciones y/o wrappers, más estables son los aplicativos que desarrollamos sobre esta y más controlada está su evolución. Podéis ver una charla interesante sobre el tema aquí:

Tras la reutilización, la segunda línea de defensa debe pasar por procurar eludir que la
propia arquitectura del framework fagocite tu aplicación. Si esto sucede, no vas a poder mudar ya
jamás ni evolucionar su diseño, estando siempre y en todo momento a cargo de las resoluciones que se tomen en el
contexto del framework de elección. Este caso es singularmente sangrante con ExtJS, el que pasó de no tener nada de arquitectura, a incorporar MVC en la versión cuatro y después más tarde MVVM en la cinco. Una insensatez en los evolutivos de los diferentes aplicativos!!

Para finalizar, lograr mantenibilidad pasa por supervisar el set de tecnologías y herramientas
empleadas por tu frameworks. Si son bastante estándares y el ecosistema evoluciona, no va a haber
inconveniente, mas si como en el caso de ExtJS en vez de emplear NPM o bien Webpack o bien Grunt o bien Gulp se usa un builder propio basado en Apache Ant como es Sencha Cmd, entonces estás meridianamente en la ruta del dolor.

Como veis, no siempre y en toda circunstancia es posible prever los caminos por los que te va a llevar tu framework, de esta manera
que siguiendo con el principio precedente, no dejes nada en sus manos y prosigue siempre y en todo momento la línea de la reusabilidad y de la flexibilidad de cambio.

Siguientes pasos

En nuestra situación actual y siguiendo los principios expuestos, estamos valorando como lograr que ExtJS pueda ser empleado solamente como un toolkit de componentes ricos, sin precisar comprometer la arquitectura completa de nuestra aplicación.

Con la versión seis y siguientes, ya vamos a contar con soporte para transpilado de ES6, diseño responsivo y separación de la una parte de componentes ricos en comparación con resto del framework. No os perdáis la SenchaCon del actual año donde se anunció el proyecto Sencha Reactor que deja el empleo de los componentes ricos de ExtJS en otros frameworks mediante un bridge singular (en un caso así facilitando la integración con React):

Así logramos separar los componentes del binding con el DOM, el routing en la aplicación o bien la propia definición de la arquitectura cliente del servicio por lo general. Esta solución ya empieza a ir un tanto más en la línea deseada.

Conclusiones

No creo que nuestro escenario sea en especial poco afortunado, en tanto que desgraciadamente los cambios que rompen compatibilidad son más frecuentes de lo que nos agradaría viendos casos como el de Angular2. No es moco de pavo. Lo que está claro es que estos frameworks de componentes deberían padecer una transformación en el futuro tras la aparición disruptiva de los Web Components, de manera que la forma de definirlos, reusarlos, integrarlos y poder utilizarlos en diferentes dispositivos fuera siempre y en todo momento predecible y estándar, con independencia de su aspecto final y funcionalidad.

Por desgracia incluso nos queda mucho camino que caminar hasta el momento en que los navegadores integren de base
tecnologías como HTML imports o bien Shadow DOM, conformándonos mientras que con sets de polyfills que nos sirven como punto de inicio. Tal vez en un futuro podamos ver una integración más clara en frameworks como Angular o bien ExtJS que trabajan con directivas y componentes, de manera que puedan desamparar sus sistemas de definición dueños en pro de la estandarización.

Como siempre y en todo momento, el planeta frontend nos depara interesantes movimientos. Habremos de estar atentos y no
perder jamás el control de nuestros desarrollos.

Asimismo te invitamos a

uno imágenes espectaculares hechas con un móvil con las que aprender los mejores trucos fotográficos

Bootstrap tres RC1 ya está acá

Los uno Frameworks/Librerías más populares de Javascript

– La nueva

Experiencias en el desarrollo de aplicaciones SPA corporativas

fue publicada originalmente en

turincon.net

por
Ricardo Borillo

.