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
• Descrição
• Requisitos de usuário
• Arquitetura e padrões
• Tecnologias utilizadas
• Futuras implementações
• Requisitos para execução e consumo da API
• Como executar
• Linter
• Observações
• Requisitos funcionais

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.

---

Descrição

Se trata de uma API de gerenciamento de vendas que manipula produtos e vendas. Basicamente é um modesto controle de estoque em forma de CRUD para lidar tanto com produtos como com as vendas .

Começando pela API, foi desenvolvido alguns ENDPOINTS seguindo os princípios do REST que se conectam a um banco de dados NÃO relacional.

Depois, foi criado uma Collection para os produtos (products) que desejam se cadastrar na aplicação, afim de ser possível fazer vendas com esses produtos. Após isso, uma Collection para vendas (sales) também foi criada. As vendas são realizadas conforme a quantidade de produtos disponíveis em estoque.

Requisitos de Usuário

• Deve ser possível que a pessoa usuária, independente de cadastramento ou login, possa adicionar, ler, deletar e atualizar produtos no seu estoque.
• O usuário deve poder também enviar vendas para o sistema. Essas vendas devem validar se o produto em questão existe.
• Deve, também, ser possível ler, deletar e atualizar vendas.

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 requisições para os ENDPOINTs de http://localhost:3000 (A porta 3000 está como padrão alternativo na ausência de variável de ambiente).

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 forma automática

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

---

Observações

Sumário

Estrutura da lista de requisitos funcionais

• Em cada requisito você encontrará uma imagem de um protótipo de como sua aplicação deve ficar.

Estrutura do banco de dados:

• Observação: O _id é gerado automaticamente.

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

  • A tabela de produtos terá o seguinte nome: products

    • Os campos da collection products terão esse formato:

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

  • A tabela de vendas terá o seguinte nome: sales

    • Os campos da tabela sales terão esse formato:

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

Shape de retorno após "insert" no banco:

• A tabela de produtos

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

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

• A tabela de vendas

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

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

Requisitos funcionais

Sumário

Para entender melhor a lógica por trás do código de desenvolvimento da API, é interessante olhar a Requisitos funcionais do projeto. Acesse aqui o readme desses Requisitos Funcionais.