\section{Conclusão}
Na elaboração deste trabalho foram surgindo várias questões. Inicialmente decidimos montar um ambiente de desenvolvimento um pouco diferente do que foi falado nas aulas da cadeira. Como já tínhamos algum conhecimento prévio de algumas ferramentas como o Webpack, Gulp e NPM decidimos que eram uma boa opção para este contexto. 

Na primeira fase do projeto o proposto era implementar apenas o lado do cliente com o uso do React. Para adiantar algum trabalho e preparar a estrutura do cliente foi decidido que iríamos implementar uma base de dados em memória do lado do servidor e implementar um controlador para podermos obter informação que viria a ser apresentada na interface. 

Na segunda parte do projeto, uma vez que já tínhamos grande parte das classes criadas foi mais rápido fazer a transição. Depois de decidirmos qual era o modelo de dados mais adequado passamos por fazer as anotações em JPA para que fosse de acordo com o planeado. 

Concluídas as entidades necessárias, o passo seguinte passou por criar os controladores necessários e os respetivos repositórios. Decidimos que primeiro íamos deixar o lado do servidor funcional e só depois fazer as alterações necessárias do lado do cliente para ficarem consistentes. 

À medida que os pedidos iam sendo feitos, recorremos a ferramenta Postman para irmos testando se estavam de acordo com o que era necessário no cliente. 

Uma vez concluídas algumas das funcionalidades mais importantes, começamos por fazer as devidas alterações no lado do cliente. O que se mostrou ser razoavelmente rápido devido ao trabalho feito na primeira fase.

No desenrolar do projeto, como a quantidade de código e classes já existiam em número razoavelmente grande decidimos parar e estruturar todo o servidor. Daqui surgiu a arquitetura apresentada no capitulo 4. Separámos melhor os componentes, dando contexto e funcionalidades diferentes a cada um. 

Neste momento surgiu também um outro problema. As respostas ao cliente nem sempre eram aquilo que era pretendido. Ou seja, em caso de tudo funcionar corretamente a resposta apresentada era o esperado mas em caso de erro não havia consistência no que era enviado nos diversos pedidos, em alguns casos retornava \textit{null} , noutros era retornado uma exceção. Surgiu então a necessidade de criar vários tipos de exceção. Isto para sabermos do lado do cliente o que tinha falhado e assim poder apresentar uma mensagem consistente com o erro ocorrido. Estas mensagens são enviadas pelo servidor no caso de alguma exceção ter ocorrido.

O maior desafio no projeto foi a incorporação da camada de segurança na aplicação. Primeiro a questão da autenticação por termos feito um formulário em React e não através da \textit{view engine} usada no projeto. Em segundo por não estarmos a conseguir implementar as medidas de segurança que à partida tínhamos em mente. Para resolver estes problemas fizemos alguma consulta pela documentação do Spring e algums fóruns, para ter uma ideia de como iríamos abordar este problema. Como solução chegámos ao que foi descrito no capitulo 5. 

Embora tenhamos tido desafios e problemas no desenrolar do projeto, aprendemos sobre uma nova tecnologia. E apesar de já existirem algumas ferramentas semelhantes ao Spring, que nos proporcionam o desenvolvimento de aplicações com esta estrutura e o uso da técnica ORM (\textit{Object Relational Model}) como é o caso do \textit{Laravel} ou \textit{NodeJS + MongoDB}, gostámos de aprender sobre Spring e achamos que é uma boa adição ao nosso \textit{skill set}.