This is a backend of a store. It was developed with Node.js
Go to file
2021-11-18 07:07:42 -03:00
.github Alterando env do Store-Evaluation 2021-10-18 16:39:16 -03:00
.trybe Initial commit 2021-10-15 17:58:04 -03:00
.vscode Reconfigura models/connection.js 2021-10-23 16:52:46 -03:00
controllers Corrige comentario rascunho 2021-10-24 02:42:29 -03:00
models chore: Atualiza variavel de ambiente 2021-11-18 02:40:25 -03:00
public Initial commit 2021-10-15 17:58:04 -03:00
services Corrige ortografia de alguns cometarios 2021-10-24 02:29:14 -03:00
utils chore: Deleta utils/validMidds 2021-11-18 02:28:23 -03:00
.editorconfig Initial commit 2021-10-15 17:58:04 -03:00
.eslintignore Initial commit 2021-10-15 17:58:04 -03:00
.eslintrc.json Initial commit 2021-10-15 17:58:04 -03:00
.gitignore chore: Atualiza gitignore 2021-11-18 07:07:42 -03:00
index.js chore: Atualiza Readme 2021-11-18 03:58:39 -03:00
package-lock.json Reconfigura models/connection.js 2021-10-23 16:52:46 -03:00
package.json chore: Atualiza Readme 2021-11-18 02:27:13 -03:00
README.md fix: Ortografia no Readme 2021-11-18 07:04:55 -03:00

Boas vindas ao repositório do Store Manager

Esse projeto é uma API de um sistema de gerenciamento de vendas, onde será possível criar, visualizar, deletar e atualizar os produtos e as vendas. Ou seja, um CRUD.


Sumário

Habilidades

Esse projeto teve como objetivo praticar as seguintes hardskills:

  • Estruturação de uma aplicação em camadas (Arquitetura MSC);
  • Delegação de responsabilidades específicas para cada parte do app;
  • Melhora da manutenibilidade e reusabilidade do código;
  • Aplicação dos padrões REST;
  • Implementação de uma API intuitiva e facilmente entendível.

Arquitetura e Padrões

Sumário

  • Arquitetura MSC
  • API RESTfull.

Tecnologias utilizadas

Sumário

  • Node.js
  • Express
  • MongoDB
  • ESLinter

Futuras implementações

Sumário

  • Implantar a aplicação na plataforma (PaaS) do Heroku, para que possa ser consumida e testada externamente.
  • Implantar um Banco de Dados na nuvem do MongoDB Atlas para que possa ser utilizado via Heroku.

Requisitos para execução e consumo da API:

Sumário

  1. Node.js
  2. MongoDB
  3. Porta 3000 disponível, ou configurar outra.
  4. Algum cliente de teste de API (ex.: Postman, Insomnia e etc) caso queira testar as requisições.

Dependências:

Sumário

No arquivo package.json é listado as dependências necessárias. Para instalar essas dependências, estando conectado a internet e dentro da pasta do repositório, basta digitar o seguinte comando:

`npm install`

Como Executar

Instalado os requisitos e as dependências necessárias, basta seguir as seguintes etapas:

  1. Dentro pasta do projeto, execute o comando: npm start.
  2. Em seguida, abra algum cliente de API (ex.: Postman, Insomnia e etc) e faça as requicições para as rotas de http://localhost:3000 (A porta 3000 está como padrão alternativo na ausência de variável de ambiente).

ENDPOINTS: Shape dos retornos das requisições

Sumário

  • Caso o recurso não seja encontrado, a API deve retornar o status HTTP adequado com o body { message: '<recurso> não encontrado' }.
  • Em caso de erro, a API deve retornar o status HTTP adequado com o body { err: { message: <mensagem de erro>, code: <código do erro> } }.
    • O código de erro implementado deve deve seguir o mesmo padrão para toda a aplicação. Por exemplo: 'not_found', 'invalid_data' e afins.
  • Em caso de dados inválidos, a API deve retornar o status HTTP adequado, com o body { err: { message: 'Dados inválidos', code: <código do erro> } }.
  • Todos os retornos de erro devem seguir o mesmo formato. Para erros que requerem dados adicionais (por exemplo, para informar quais campos estão incorretos) é utilizado a propriedade data dentro do objeto err.

Banco de dados: Shape dos Documentos (Registros)

Sumário

O banco deve duas collections para: uma para os produtos e outra para as vendas

A tabela terá o seguinte nome: products

Os campos da collection products terão esse formato:

{ "name": "Produto Silva", "quantity": 10 }

A resposta retornada após um insert (criação) no banco precisa ter o seguinte shape:

{ "_id": ObjectId("5f43cbf4c45ff5104986e81d"), "name": "Produto Silva", "quantity": 10 }

(O _id é gerado automaticamente)

A tabela de vendas terá o seguinte nome: sales

Os campos da tabela sales terão esse formato:

{ "itensSold": [{ "productId": "5f43cbf4c45ff5104986e81d", "quantity": 2 }] }

A resposta retornada após um insert (criação) no banco precisa ter o seguinte shape:

{
  "_id": ObjectId("5f43cc53c45ff5104986e81e"),
  "itensSold": [{ "productId": "5f43cbf4c45ff5104986e81d", "quantity": 2 }]
}

(O _id é gerado automaticamente)

Linter

Sumário

Foi usado ESLint para fazer a análise estática do código, afim de manter padrões de indentação e espaçamento dos trechos de códigos. No entanto, para usá-lo de forma mais manual, o projeto já vem com as dependências relacionadas ao ESLint configuradas no arquivos package.json.

Para executá-lo basta usar --- dentro da pasta do projeto --- o comando npm run lint. Se a análise do ESLint encontrar problemas no código, tais problemas serão mostrados no seu terminal. Se não houver problema no seu código, nada será impresso no seu terminal.

ESLint de foram automática

Particulamente eu preferi utilizar o plugin ESLint pela extensão do VSCode, em favor da produtividade.


Regras de negócio

Sumário

Para entender melhor a lógica da API, pode ser interessante olhar a regra de negócio do projeto. Tratamos sobre isso no Wiki.