... | @@ -28,3 +28,42 @@ Devem ser apresentados das seguintes formas: |
... | @@ -28,3 +28,42 @@ Devem ser apresentados das seguintes formas: |
|
|
|
|
|
## Arquitetura App Proprietário
|
|
## Arquitetura App Proprietário
|
|
![](http://tools.ages.pucrs.br/onyva/onyva-wiki/raw/master/Arquitetura_Onyva.png)
|
|
![](http://tools.ages.pucrs.br/onyva/onyva-wiki/raw/master/Arquitetura_Onyva.png)
|
|
|
|
|
|
|
|
## Arquitetura Back-end
|
|
|
|
Este projeto adota uma arquitetura baseada em [camadas](http://wiki.c2.com/?FourLayerArchitecture), onde cada camada tem sua responsabilidade, e sempre a camada mais alta irá se comunicar com a camada mais baixa.
|
|
|
|
|
|
|
|
|
|
|
|
### Camada de interfaces de entrada (pasta `interfaces`)
|
|
|
|
|
|
|
|
Esta pasta contém todos os pontos de entrada para a aplicação. É o início, é aqui que estarão os controllers e rotas do Express.
|
|
|
|
|
|
|
|
|
|
|
|
### Camada de aplicação (pasta `app`)
|
|
|
|
|
|
|
|
A camada de aplicação é responsável por fazer o intermédio entre a interface e a lógica de negócio. Nesta camada podemos criar operações e serviços que se comunicarão com a infraestrutura (Banco de dados ou outros serviços externos).
|
|
|
|
|
|
|
|
### Camada de infraestrutura (pasta `infra`)
|
|
|
|
|
|
|
|
Esta é a camada mais baixa. Na camada de infraestrutura sempre terá a comunicação com o que está fora da aplicação, como banco de dados, serviços de email e comunicação direta com frameworks.
|
|
|
|
|
|
|
|
## Injeção de Dependência
|
|
|
|
|
|
|
|
Ideia central desse padrão é que cada dependência de um objeto que pode (e faz sentido) ser desacoplada deve ser injetada para torná-la mais flexível, reutilizável e facilmente testável. Neste projeto a injeção de dependências funciona usando a biblioteca [Awilix](https://www.npmjs.com/package/awilix). Artigo sobre esta biblioteca (escrito pelo autor), [parte 1](https://medium.com/@Jeffijoe/dependency-injection-in-node-js-2016-edition-f2a88efdd427) , [parte 2](https://medium.com/@Jeffijoe/dependency-injection-in-node-js-2016-edition-part-2-aedc5fd6eed0) e [parte 3](https://medium.com/@Jeffijoe/dependency-injection-in-node-js-2016-edition-part-3-c01471c09c6d) . Para as injeções nos controladores, usamos o adaptador [Express Awilix](https://www.npmjs.com/package/awilix-express).
|
|
|
|
|
|
|
|
## Repository
|
|
|
|
|
|
|
|
Este padrão parte do princípio de que não devemos tocar diretamente no banco de dados. Então temos repositórios que tratam da persistência internamente e os injetamos nas instâncias de operações e serviços que desejam utiliza-la. [Referência](https://martinfowler.com/eaaCatalog/repository.html).
|
|
|
|
|
|
|
|
## Notificações
|
|
|
|
|
|
|
|
O projeto utiliza o serviço de Cloud Messaging do Firebase para enviar push notifications aos usuários. Para isso, foi criado uma conta com os dados:
|
|
|
|
- email: [email protected]
|
|
|
|
- senha: onyva2020
|
|
|
|
|
|
|
|
### Ponto de atenção
|
|
|
|
|
|
|
|
O projeto possui rotas que permite o envio de notificação para múltiplos usuários. Porém, o serviço do Firebase possui uma limitação de 500 usuários por notificação. Em fase de desenvolvimento e testes isso não é um problema, porém quando em produção, isso pode causar erros. Uma possível solução é dividir os usuários alvos em grupos de 500 e chamar o serviço de notificação para cada grupo.
|
|
|
|
|
|
|
|
### Notificação mensal
|
|
|
|
|
|
|
|
O sistema possui uma notificação mensal, onde pede-se ao usuário proprietário que ele atualize a kilometragem do veículo. O dia do mês e o horário dessa notificação são definidos através de uma expressão cron no arquivo schedulerOperation.js. [Aqui está um guia para expressões cron](https://www.baeldung.com/cron-expressions) |