/SAP010-burger-queen-api

Primary LanguageJavaScript

Burger Queen - API com Node.js

Índice

1. Prefácio

Node.js logo

Um pequeno restaurante de hamburgueres, que está crescendo, necessita de um sistema para realizar pedidos usando um tablet, e que os enviem à cozinha para que sejam preparados de forma ordenada e eficiente.

Este projeto tem duas áreas: interface (cliente) e API (servidor). Nosso cliente nos solicitou que desenvolvêssemos uma API que pode integrar com a interface, que outra equipe de desenvolvedores está trabalhando simultaneamente

2. Resumo do projeto

Como API, nesse caso nos referimos a um servidor web, que é basicamente um programa que ouve o que acontece na aplicação através de uma porta de rede, pela qual podemos enviar requisições (requests) e obter respostas (responses) usando o protocolo HTTP (o HTTPS).

Um servidor web deve lidar com as requisições que chegam e devolver respostas, que serão enviadas de volta ao cliente. Quando falamos de aplicações de servidor, isso implica uma arquitetura de cliente/servidor, onde o cliente é um programa que faz requisições através de uma rede (por exemplo o navegador, o cURL, etc) e o servidor é o programa que recebe essas requisições e as responde.

O Node.js nos permite criar servidores web super eficientes de maneira relativamente simples, tudo isso usando JavaScript!

Neste projeto partimos de um boilerplate que já contém uma série de endpoints (pontos de conexão ou URLs) e nos pedem para completar a aplicação. Isto implica que teremos que começar a ler a implementação existente, e familiarizar-nos com a stack escolhida (Node.js e Express) e complementá-la com um motor de banco de dados, no qual escolhemos o PostgreSQL.

O cliente nos deu um link para a documentação que especifica o comportamento esperado da API que iremos expor por HTTP. Lá podemos encontrar todos os detalhes que os endpoints deve implementar na aplicação, que parâmetros esperam, o que devem responder, etc.

O objetivo de aprendizagem principal foi adquirir experiência com o Node.js como ferramenta para desenvolvimento de aplicações de servidor, junto com uma série de outras ferramentas comumente utilizadas nesse contexto (Express como framework, MongoDB, PostgreSQL ou MySQL como base de dados, containers de docker, etc).

Neste projeto, desenvolvemos um servidor web que deverá servir JSON através de uma conexão HTTP, e implantá-lo em um servidor na nuvem.

Neste, projeto, tivemos familiarização com conceitos como rotas (routes), URLs, HTTP (verbos, request, response, headers, body, status codes, etc), JSON, JWT (JSON Web Tokens), conexão com uma base de dados (PostgreSQL), variables de ambiente, deployment, containers de docker, etc.

3. Objetivos de aprendizagem

Node.js

JavaScript

  • Uso de linter (ESLINT)

  • Uso de identificadores descritivos (Nomenclatura e Semântica)

Controle de Versões (Git e GitHub)

  • Git: Instalação e configuração

  • Git: Controle de versão com git (init, clone, add, commit, status, push, pull, remote)

  • Git: Integração de mudanças entre ramos (branch, checkout, fetch, merge, reset, rebase, tag)

  • GitHub: Criação de contas e repositórios, configuração de chave SSH

  • GitHub: Implantação com GitHub Pages

    Links

  • GitHub: Colaboração pelo Github (branches | forks | pull requests | code review | tags)

  • GitHub: Organização pelo Github (projects | issues | labels | milestones | releases)

Express.js

  • Gerenciamento de rotas

  • Uso e criação de middleware

Sequelize

HTTP

Autenticação

  • JWT (JSON Web Token)

  • Armazenamento e acesso de senhas

WebOps

  • Variáveis de ambiente

  • Containers (Docker)

  • Docker compose

  • Cloud Functions

PostgreSQL

Bases de dados

  • Modelagem de dados

  • Conexão

SQL

4. Considerações gerais

O projeto pode estar integrado com o projeto Burger Queen API client, parte Frontend.

A lógica do projeto foi implementada totalmente em JavaScript (ES6).

Outro requisito da equipe de QA do nosso cliente é realizar testes end-to-end, que usaremos para verificar o comportamento desde o ponto de vista de HTTP, desde fora do servidor.

O boilerplate já contém o setup e configuração necessária para executar todos os tests end-to-end com o comando npm run test:e2e.

5. Critérios de aceitação mínimos do projeto

5.1 API

Conforme estabelecido pela documentação entregue pelo nosso cliente, a API expõe os seguintes endpoints:

5.1,1 /

  • GET /

5.1.2 /auth

  • POST /auth

5.1.3 /users

  • GET /users
  • GET /users/:uid
  • POST /users
  • PATCH /users/:uid
  • DELETE /users/:uid

5.1.4 /products

  • GET /products
  • GET /products/:productid
  • POST /products
  • PATCH /products/:productid
  • DELETE /products/:productid

5.1.5 /orders

  • GET /orders
  • GET /orders/:orderId
  • POST /orders
  • PATCH /orders/:orderId
  • DELETE /orders/:orderId

5.2 CLI

O cliente solicitou que a aplicação tenha um comando npm start que deve ser responsável por executar nossa aplicação node e que também possa receber informações de configuração, como a porta a ser escutada, qual banco de dados conectar, etc. Esses dados de configuração serão distintos entre os diferentes ambientes (desenvolvimento, produção, ...). O boilerplate já implementa o código necessário para ler esta informação dos argumentos de invocação e o ambiente.

5.2.1 Argumentos de linha de comando

Podemos especificar a porta onde a aplicação deve iniciar, passando um argumento ao invocar nosso programa:

# Inicia a aplicação na porta 8888 usando npm
npm start 8888

5.2.2 Variáveis de ambiente

Nossa aplicação usa as seguintes variáveis de ambiente:

  • PORT: Se nenhuma porta for especificada como argumento da linha de comando podemos usar a variable de ambiente PORT para especificar a porta. Valor por padrão 8080.
  • DB_URL: A string de conexão de MongoDB, PostgreSQL ou MySQL. Quando executemos a aplicação em nosso computador (em ambiente de desenvolvimento), podemos usar um banco de dados local, mas em produção deveremos usar as instâncias configuradas com docker-compose (mais sobre isso na seção de Deployment).
  • JWT_SECRET: Nossa aplicação implementa autenticação usando JWT (JSON Web Tokens). Para assinar (criptografar) e verificar (descriptografar) os tokens, nossa aplicação precisa de um segredo. Localmente, pode usar o valor padrão (xxxxxxxx), mas é muito importante usar um segredo real na producção.
  • ADMIN_EMAIL: Opcionalmente podemos especificar um email e password para o usuario admin (root). Se esses detalhes estiverem presentes, a aplicação se certificará que exista o usuário e que tenha permissões de administrador. Valor por padrão admin@localhost.
  • ADMIN_PASSWORD: Se for especificado um ADMIN_EMAIL, devemos passar também uma senha para o usuário admin. Valor por padrão: changeme.

5.3 Implantação (Deployment)

Banco de dados: Postgresql

A aplicação esta configurada com docker-compose para que possa ser implantada sem dificuldades em qualquer ambiente.

Por outro lado, em relação a implantação, não é obrigatório usar docker-compose, você pode escolher o provedor (ou provedores) que preferir junto com o mecanismo de implantação e estratégia de hospedagem. Te recomendamos explorar as seguintes opcões:

  • Glitch é provavelmente a opção mais simples (requer menos configuração) e nos permite hospedar o servidor web Express importando nosso repositório do GitHub.
  • Vercel é uma opção semelhante ao Glitch, mas focada em aplicativos web estáticos (como os construídos com React). No entanto, o Vercel também nos permite implantar aplicativos node usando Serverless Functions
  • Se quiser explorar opções mais personalizadas e ver o docker do lado do servidor, pode considerar provedores como AWS (Amazon Web Services) ou GCP (Google Cloud Platform), ambos possuem algum tipo de serviço experimental gratuito (free tier) assim como instâncias de servidores virtuais (VPS), onde configuramos nosso próprio Docker ou serviços para implantar aplicações em contêineres (por exemplo Compute Engine de GCP ou Elastic Container Service de AWS).
  • Se quiser trabalhar com MongoDB, MongoDB Atlas é uma opção muito boa para hospedar a base dados de produção, que podemos usar em conjunto com qualquer uma das opções mencionadas acima.
  • Se quiser trabalhar com MySQL, ClearDB é uma boa opção para hospedar a base de dados de produção, que podemos usar em conjunto com qualquer uma das opções mencionadas acima.

6. Desenvolvedoras

Desenvolvido por:
Myllena M. Martins
Linkedin | Github
Renata Ribeiro
Linkedin | Github


git Rafa-Js vscode Jest Node Swagger Express PostgreSQL Sequelize