5. Conclusión

Hemos creado la siguiente aplicación cliente/servidor:

Para llegar a la versión final del código, tuvimos que explicar numerosos aspectos de los marcos AngularJS y Spring 4. Por lo tanto, este documento puede utilizarse para aprender a usar estos dos marcos. El párrafo 1.3 explica dónde encontrar los códigos y cómo utilizarlos.

Hemos demostrado que la aplicación cliente/servidor se puede utilizar en diversos entornos:

• como una aplicación web convencional;
• como un binario ejecutable en emuladores de Android;

Una vez más, este tutorial no es exhaustivo en cuanto al estudio de ambos marcos de trabajo. En el caso de Angular, sin duda habría que presentar las herramientas de prueba que lo acompañan. Las pruebas son pasos indispensables al desarrollar una aplicación. Las herramientas relacionadas con Angular permiten automatizarlas e incluirlas en un proceso de integración continua.

De este trabajo, destacaré dos puntos:

• la programación del servicio web de Spring fue medianamente complicada. Desde el principio, conocía bien los conceptos de Spring. Solo tuve dificultades con la seguridad del servicio web y, más tarde, con la gestión de los encabezados HTTP CORS, dos áreas que desconocía;
• la programación del cliente Angular fue mucho más compleja por diversas razones:
  • No tenía suficiente conocimiento del lenguaje JavaScript y de sus posibilidades;
  • me costó entender cómo funcionaba la programación asíncrona dentro del navegador. Pensaba como si se tratara de un servidor, donde esa asincronía se logra mediante el uso simultáneo de varios hilos. En el navegador, solo hay un hilo, y las tareas asíncronas se procesan sucesivamente y no en paralelo. Más precisamente, las tareas asincrónicas pueden ejecutarse en paralelo (por ejemplo, múltiples solicitudes HTTP), pero los eventos que generan al finalizar se procesan de manera secuencial. Por lo tanto, no hay que gestionar una ejecución concurrente con los numerosos problemas que ello conlleva;
  • Angular es un marco de trabajo completo con numerosos conceptos (MVC, directivas, servicios, alcance de los modelos, etc.). Su aprendizaje lleva tiempo;
  • Angular no impone un método de desarrollo específico. Por lo tanto, para llegar al mismo resultado, se pueden utilizar diferentes arquitecturas. Esto resulta confuso. Me siento más cómodo con marcos cerrados en los que todos utilizan los mismos patrones de diseño. Por eso, he buscado constantemente reproducir los patrones de diseño que utilizo en el lado del servidor. Estoy satisfecho con el resultado porque creo que es reproducible. Eso es lo que buscaba. Pero no sé en absoluto si me he desviado o no de las «buenas prácticas» de Angular;

Serge Tahé, julio de 2014.