Muitas pessoas tem interesse em fazer doações, mas as vezes não tem o tempo necessário para encontrar onde doar ou como doar. Como sabemos, vivemos em um país em que a desigualdade social ainda existe e por isso há várias pessoas necessitadas, às vezes grupos de pessoas com um problema em comum. Precisamos de um sistema para apoiar essa rede de doações: o eDoe.com.
- Faça o clone do projeto na sua máquina usando
git clone https://github.com/lucasanthony/edoe.git - Utilize o comando
mvn spring-boot:runpara iniciar o servidor - Teste/Utilize as rotas em um cliente REST de sua preferência, sugerimos o postman
| Método | Url | Body | Params |
|---|---|---|---|
| GET | /usuario/{nome} | ||
| GET | /item/{id} | ||
| POST | /usuario/doador | {} | |
| DELETE | /usuario/{id} | ||
| PUT | /usuario/{idUsuario} |
Para desenvolver a API provedora dos serviços com uma certa agilidade, usamos o Spring Boot. O padrão que aderimos é semelhante ao que é usado na parte do cliente, que é o padrão MVC, possuindo divisões do formato de Models, Repositories, Services e Controllers. Usamos o banco de dados não-relacional MongoDB, devido a escalabilidade horizontal que obtemos com ele, além também de facilitar o formato dos dados enviados ao Cliente, pelo fato de serem inseridos em JSON, conseguindo uma boa performance.
O modelo de segurança escolhido foi o JSON Web Token (jwt) e para implementação do mesmo se faz necessário um mecanismo de geração e validação de tokens, por meio de bibliotecas existentes.
- Faça o cadastro de um usuário
POST https://www.edoe.herokuapp.com/usuario/doador - Realize login
POST https://www.edoe.herokuapp.com/edoe/auth/loginpara receber um token válido - Utilize as rotas em um cliente REST de sua preferência, agora passando o token recebido no header de authorization
Bearer TOKEN
A estrutura utilizada para melhoramento do desempenho foi uma abstração de memória cache, que apresenta benefícios no tempo de respostas das requisições, torna o sistema mais escalável(menos consultas no banco) e oferece uma economia de disco. Os endpoint escolhidos para serem voltados a essa memória temporária foram os métodos HTTP do tipo GET, isso porque os demais precisariam efetivamente de um acesso direto ao banco, pois resultam em modificações no mesmo.
- Comparação de resultados, CACHE vs SEM CACHE
O fluxo de execução das requisições que utilizam cache se caracterizam por um armazenamento temporário de respostas de requisições, o que diminui a quantidade de vezes que o banco é consultado, diminuindo assim o tempo de resposta. Para testar, utilizamos uma função para paralizar a execução da thread responável pela requisição, assim, quando a cache entrava em prática, essa pausa era ignorada, pois a requisição já buscava a resposta na memória temporária, os resultados obtidos foram expostos nos gráficos acima. Em testes no Postman, observamos uma melhora de 80% aproximadamente no tempo de resposta, confirmando a eficácia da utilização de cache nesses tipos de requisições HTTP.
