5. Conclusão

Criamos o seguinte aplicativo cliente/servidor:

Para chegar à versão final do código, tivemos que explicar vários pontos dos frameworks AngularJS e Spring 4. Portanto, este documento pode ser usado para aprender a utilizar esses dois frameworks. O parágrafo 1.3 explica onde encontrar os códigos e como utilizá-los.

Mostramos que a aplicação cliente/servidor pode ser utilizada em diversos ambientes:

• como um aplicativo web clássico;
• como um binário executável em emuladores Android;

Mais uma vez, este tutorial não é exaustivo no que diz respeito ao estudo das duas estruturas. Para o Angular, certamente seria necessário apresentar as ferramentas de teste que o acompanham. Os testes são etapas indispensáveis durante a criação de um aplicativo. As ferramentas relacionadas ao Angular permitem automatizá-los e incluí-los em um processo de integração contínua.

Deste trabalho, vou destacar dois pontos:

• a criação do serviço web Spring foi moderadamente complicada. Desde o início, eu já conhecia bem os conceitos do Spring. Encontrei dificuldades apenas com a segurança do serviço web e, posteriormente, com o gerenciamento dos cabeçalhos HTTP e CORS, duas áreas que eu não conhecia;
• a criação do cliente Angular foi muito mais complexa por diversos motivos:
  • eu não tinha conhecimento suficiente da linguagem JavaScript e de suas possibilidades;
  • tive dificuldade em entender como funcionava a programação assíncrona no navegador. Eu raciocinava como se estivesse em um servidor, onde essa assincronia é obtida com o uso simultâneo de várias threads. No navegador, há apenas uma thread, e as tarefas assíncronas são processadas sucessivamente, e não em paralelo. Mais precisamente, tarefas assíncronas podem ser executadas em paralelo (múltiplas solicitações HTTP, por exemplo), mas os eventos que elas geram ao serem concluídas são processados sequencialmente. Portanto, não há execução simultânea para gerenciar, com os inúmeros problemas que isso acarreta;
  • O Angular é um framework robusto, com diversos conceitos (MVC, diretivas, serviços, escopo de modelos, etc.). Sua aprendizagem é demorada;
  • O Angular não impõe um método de desenvolvimento específico. Assim, para chegar ao mesmo resultado, é possível utilizar diferentes arquiteturas. Isso é confuso. Sinto-me mais à vontade com frameworks fechados, nos quais todos utilizam os mesmos padrões de design (design pattern). Por isso, procurei constantemente reproduzir os padrões de design que utilizo no lado do servidor. Estou satisfeito com o resultado, pois acredito que ele seja reproduzível. Era isso que eu buscava. Mas não tenho a menor ideia se me afastei ou não das “boas práticas” do Angular;

Serge Tahé, julho de 2014.