5. Conclusión

Hemos creado la siguiente aplicación cliente/servidor:

Para llegar a la versión final del código, tuvimos que explicar muchos aspectos de los marcos AngularJS y Spring 4. Por lo tanto, este documento puede utilizarse para aprender a utilizar estos dos marcos. La sección 1.3 explica dónde encontrar el código y cómo utilizarlo.

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

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

Una vez más, este tutorial no es exhaustivo en su tratamiento de los dos marcos de trabajo. En el caso de Angular, sin duda tendríamos que abordar las herramientas de pruebas que lo acompañan. Las pruebas son un paso esencial a la hora de escribir una aplicación. Las herramientas asociadas a Angular permiten automatizar estas pruebas e incorporarlas a un proceso de integración continua.

De este trabajo, me quedo con dos puntos clave:

• Escribir el servicio web de Spring fue moderadamente complicado. Desde el principio, estaba familiarizado con los conceptos de Spring. Solo encontré dificultades a la hora de proteger el servicio web y, más tarde, con la gestión de los encabezados HTTP CORS, dos áreas con las que no estaba familiarizado;
• Escribir el cliente Angular fue mucho más complejo por varias razones:
  • No tenía suficientes conocimientos del lenguaje JavaScript y sus capacidades;
  • Me costaba entender cómo funciona la programación asíncrona dentro del navegador. Lo concebía como en un servidor, donde esta asincronía se logra mediante el uso simultáneo de múltiples subprocesos. En el navegador, solo hay un subproceso, y las tareas asíncronas se procesan secuencialmente en lugar de en paralelo. Más concretamente, las tareas asíncronas pueden ejecutarse en paralelo (múltiples solicitudes HTTP, por ejemplo), pero los eventos que desencadenan al completarse se procesan secuencialmente. Por lo tanto, no hay que gestionar ninguna ejecución concurrente, ni los numerosos problemas que ello conlleva;
  • Angular es un marco de trabajo muy completo con muchos conceptos (MVC, directivas, servicios, ámbito del modelo, etc.). Se tarda mucho tiempo en aprenderlo;
  • Angular no impone un método de desarrollo específico. Por lo tanto, para lograr el mismo resultado, se pueden utilizar diferentes arquitecturas. Esto resulta confuso. Me siento más cómodo con marcos cerrados en los que todo el mundo utiliza los mismos patrones de diseño. Por eso, he buscado constantemente replicar 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 tengo ni idea de si me he desviado o no de las «buenas prácticas» de Angular;

Serge Tahé, julio de 2014.