5. Conclusión

Hemos creado la siguiente aplicación cliente/servidor:

Para llegar al código final version, hemos tenido que explicar numerosos aspectos de los frameworks AngularJS y Spring 4. Por lo tanto, este documento puede utilizarse para formarse en el uso de estos dos frameworks. El apartado 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 clásica;
• como un binario ejecutable en emuladores de Android;

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

De este trabajo, destacaré dos puntos:

• la escritura del servicio web Spring resultó 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 ámbitos que desconocía;
• la programación del cliente Angular fue mucho más compleja por diferentes razones:
  • no tenía suficientes conocimientos del lenguaje Javascript y de sus posibilidades;
  • me costó entender cómo funcionaba la programación asíncrona dentro del navegador. Razonaba como si se tratara de un servidor, donde esta asincronía se consigue mediante el uso simultáneo de varios subprocesos. En el navegador, solo hay un subproceso, y las tareas asíncronas se procesan sucesivamente y no en paralelo. Más concretamente, las tareas asíncronas pueden ejecutarse en paralelo (por ejemplo, múltiples solicitudes HTTP), pero los eventos que producen al finalizar se procesan secuencialmente. 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, ámbito de los modelos, etc.). Su aprendizaje es long;
  • Angular no impone ningún método de desarrollo. Así, para llegar al mismo resultado, se pueden utilizar diferentes arquitecturas. Esto resulta desconcertante. Me siento más cómodo con marcos cerrados en los que todo el mundo utiliza los mismos patrones de diseño (design pattern). Por lo tanto, 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. 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.