Skip to content
Gallery
CodeWave Systems
Software STMF
Share
Explore

info

Base URL:
https://stmfapi.cwsystems.com.br/
⁠
⁠

SWAGGER:
https://stmfapi.cwsystems.com.br/
⁠
api
info

O objetivo da API deve ser disponibilizar todas as configs de permissão, enumeração, e modularização de sync

Basicamente a API deve disponibilizar para o APP tudo o que for necessário para conseguir funcionar sem internet, dependendo apenas de uma consulta de listagem de permissões do usuário logado, módulos a qual ele tem acesso, e configurações “gerais” de apresentação.
A primeiro momento não parece ter uma regra de negócio especifica que dependa da API. Se o APP faz a request é porquê deve ter permissão, as validações da API irão se restringir a garantir a consistência dos dados e autenticação.
error

Focos durante o desenvolvimento

Performance
Testes com faker
info

Estrutura do projeto

Linguagem: Node.js
Framework: NESTJS

Será aplicado um semi clean:
Camandas: Regras (UC), DB, Services, Framework
UC: Será a regra de negócio assim como cada ação da API, “cada rota um UC”
DB: Classes de conexão no banco utilizando o prisma como ORM
Services: Tudo o que for serviço externo a API, DEVE ser feita inversão de dependencia assinada por interface.
Framework: sem a camada do .service, apenas controller → UC → serviço. UC fica fora do framework.

Os testes unitários devem ser aplicados nas camadas de UC, DB, Services
Os testes 2e2 devem passar pelo framework, batendo em um DB real (DB de teste local)
Nem todo o teste unitário deve ter um faker apenas os mais importantes.
info

Notas de desenvolvimento

O código que será escrito tem a seguinte mentalidade:
UC consome os serviços, banco, CEP, PIX o que for, os serviços dão throw, mas o UC trata ex:
UC para salvar os dados de um user, se por alguma inconsistência da base deu um erro 500, o UC irá retornar para a controller apenas um “success” false, UC não deve dar throw, deve capturar o erro e tratar, salvar log o que for, mas a regra de negócio não pode morrer por inconsistencia de serviço externo a ela.
Implementação de serviço DEVE dar throw, serviço não trata o que deve acontecer caso der erro, serviço apenas garante que o processo dele mesmo não irá causar incosistencia, exemplo update de user seguido de alteração de tabela filha, se o update der erro deve ter um rollback de tudo, isso é responsabilidade da implementação do serviço, o serviço pode ter try catch, mas não deve ser ele que decide como deve ser tratado o catch em questão de sequencia do código, ainda mais lidando com sincronização, exemplo: não é porquê 1 registro deu erro ao tentar sincronizar, que deve morrer a sincronização como um todo, quem decide se deve continuar após um erro no código ou no serviço é o UC.
Quando um registro der erro de sync, separar ele na reponse dos que deram success, exemplo:
{
“success”: true,
“data”: [
{
“id”: 1,
“succes”: true
},
{
“id”: 2,
“success”: false,
“error”: “fabricante não encontrado.”
}
]
}

..
{
“error”: “fabricante não encontrado.”
}
Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.