damews / blueapifunctions Goto Github PK

No futuro, a API deverá ser utilizada por outros pesquisadores para busca de dados respiratórios dos jogadores.

Atualmente, os dados enviados (da calibração, plataforma e minigames) incluem apenas dados respiratórios do PITACO. A API deverá conter uma rota para enviar os dados da CINTA e MANOVACUMÔMETRO separadamente, como já ocorre ao gravar dados em CSV.

Estas rotas deverão gravar os registros similares ao que já é feito com arquivos CSV. Deverá conter rotas para calibração, plataforma e minigames de forma com que 1 registro possua os dados dos dois dispositivos.

O teste de unidade deve cobrir a execução da funções de validação de entrada, ou seja, a parte inicial do recebimento da requisição antes de ser efetuado o processamento.

Esta separação visa melhorar as manutenções futuras e permitir que sejam realizados os testes unitários com as regras de negócio/manipulações e da camada de dados. Este issue está limitada a:

• Realizar a separação de código que contenham regras de negócio/manipulações de dados;
• Realizar a separação de código que contenham chamadas a camada de dados (construção de consultas, chamadas a banco de dados, etc)

As inclusões do README devem conter a documentação do projeto, requisitos necessários para uma execução local e documentação da API.

Atualmente, os dados que são enviados para as rotas de minigames e plataforma contém apenas os dados do dispositivo PITACO. Para facilitar a inserção de novos dispositivos que irão gerar dados para o jogo e que serão utilizados para análise, os dados dos dispositivos devem ser guardados em coleções separadas e mantidas as referencias na coleção da plataforma/minigames.

Desta forma, um registro de minigame/plataforma poderá conter diversos registros de dispositivos que podem ser analisados.

Ex do modelo:

PlataformOverview:
[...]
FlowDataDevices:
{deviceName: PITACO, flowDataId: 5523knl(...)}

Deverão ser executados a cada Pull Request realizados dentro do repositório os testes de unidade implementados, barrando o merge caso o teste falhe. E caso o teste tenha sucedido, fazer a devida integração do código.

Após a integração do código, deverá ser feito a implantação automática das funções no ambiente do Azure Functions.

Os arquivos contidos na pasta shared possuem definições que são utilizadas nas funções declaradas do projeto. Estes arquivos contém definições dos schemas das collections para o banco utilizado, além de funções auxiliares para validação de modelos de entrada (a partir da requisição HTTP recebida), validações de headers, validações de chaves, criação de responses e envios de email.

Para melhorar manutenção futura do código, separar cada responsabilidade em seus devidos arquivos/pastas.

A separação ficaria melhor se:

• Os schemas ficassem dentro de uma mesma pasta;
• As funções dentro da classe utils fossem quebradas em unidades menores que possuem um mesmo contexto
• As funções de validação fossem quebradas pelo modelo de validação