5. Conclusão

Criámos a seguinte aplicação cliente/servidor:

Para chegar à versão final do código, tivemos de explicar muitos aspetos das estruturas AngularJS e Spring 4. Este documento pode, portanto, ser utilizado para aprender a utilizar estas duas estruturas. A secção 1.3 explica onde encontrar o código e como utilizá-lo.

Demonstrámos que a aplicação cliente/servidor é utilizável em vários ambientes:

• como uma aplicação web tradicional;
• como um binário executável em emuladores Android;

Mais uma vez, este tutorial não é exaustivo na sua abordagem das duas estruturas. No caso do Angular, seria certamente necessário abordar as ferramentas de teste que o acompanham. O teste é uma etapa essencial na criação de uma aplicação. As ferramentas associadas ao Angular permitem automatizar esses testes e incorporá-los num processo de integração contínua.

Deste trabalho, vou retirar dois pontos-chave:

• Escrever o serviço web Spring foi moderadamente complicado. Desde o início, estava familiarizado com os conceitos do Spring. Só encontrei dificuldades na segurança do serviço web e, mais tarde, na gestão dos cabeçalhos HTTP CORS — duas áreas com as quais não estava familiarizado;
• Escrever o cliente Angular foi muito mais complexo por várias razões:
  • Não tinha conhecimento suficiente da linguagem JavaScript e das suas capacidades;
  • Tive dificuldade em compreender como a programação assíncrona funciona no navegador. Estava a pensar nisso como num servidor, onde essa assincronia é alcançada através do uso simultâneo de múltiplas threads. No navegador, existe apenas uma thread, e as tarefas assíncronas são processadas sequencialmente, em vez de em paralelo. Mais especificamente, as tarefas assíncronas podem ser executadas em paralelo (múltiplas solicitações HTTP, por exemplo), mas os eventos que desencadeiam após a conclusão são processados sequencialmente. Não há, portanto, nenhuma execução simultânea para gerir, juntamente com as muitas questões que isso acarreta;
  • O Angular é um framework rico com muitos conceitos (MVC, diretivas, serviços, âmbito do modelo, etc.). Demora muito tempo a aprender;
  • O Angular não impõe um método de desenvolvimento específico. Assim, para alcançar o mesmo resultado, é possível utilizar diferentes arquiteturas. Isto é confuso. Sinto-me mais à vontade com frameworks fechados, onde todos utilizam os mesmos padrões de design. Por isso, tenho procurado constantemente replicar os padrões de design que utilizo no lado do servidor. Estou satisfeito com o resultado, porque acredito que é reproduzível. Era isso que procurava. Mas não faço ideia se me afastei ou não das «melhores práticas» do Angular;

Serge Tahé, julho de 2014.