Skip to content

Luzapedreira/SAP011-burger-queen-api

BranchesTags
 
 

Repository files navigation

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 você deverá escolher entre MongoDB, PostgreSQL e MySQL.

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 é 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, você desenvolverá um servidor web que deverá servir JSON através de uma conexão HTTP, e implantá-lo em um servidor na nuvem.

Ao final do projeto, você deverá estar familiarizada 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 (MongoDB, PostgreSQL ou MySQL), variables de ambiente, deployment, containers de docker, etc.

3. Objetivos de aprendizagem

Reflita e depois enumere os objetivos que quer alcançar e aplique no seu projeto. Pense nisso para decidir sua estratégia de trabalho.

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

HTTP

Autenticação

  • JWT (JSON Web Token)

  • Armazenamento e acesso de senhas

WebOps

  • Variáveis de ambiente

  • Containers (Docker)

  • Docker compose

  • Cloud Functions

MongoDB

PostgreSQL

MySQL

Bases de dados

  • Modelagem de dados

  • Conexão

SQL

4. Considerações gerais

Este projeto será realizado em duplas e pode estar integrado com o projeto Burger Queen API client que a equipe de Frontend developers do seu squad desenvolve simultaneamente.

A lógica do projeto deve estar implementada totalmente em JavaScript (ES6). Neste projeto está permitido usar bibliotecas ou frameworks, assim como extensões para a linguagem com babel (neste caso você incluir um comando npm build).

Os testes deven cobrir um mínimo de 90% de statements, functions, lines e branches. Embora o boilerplate não inclua as configurações para testes unitários, estes são obrigatórios.

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. Estes testes, diferente dos testes unitarios, não testam cada parte separadamente, mas testam a aplicação completa, do princípio ao fim. Esses testes, por não fazerem uso direto do código-fonte da aplicação, podem ser executados diretamente em uma URL remota, pois a interface em teste é HTTP.

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.

# Execute testes e2e na instância local. Isso levanta a aplicação com npm
# start e execute os tests na URL desta instancia (por padrão
# http://127.0.0.1:8080).
npm run test:e2e

# Execute testes e2e em URL remoto
REMOTE_URL=<TODO: colocar URL> npm run test:e2e

Os testes end-to-end já estão concluidos no boilerplate, então pode usá-los como um guia de implementação e lista de verificação de integridade.

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

5.1 API

Conforme estabelecido pela documentação entregue pelo nosso cliente, a API deve expor 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)

Nosso cliente nos informou que a sua equipe de devops está sempre com muitas tarefas, portanto, pediu como requesito que a aplicação esteja configurada com docker-compose para que possa ser implantada sem dificuldades em qualquer ambiente.

O boilerplate já conta com uma configuração incial de docker-compose para a aplicação de node, sua tarefa será estender essa configuração para incluir a configuração do banco de dados escolhido. Leve em consideração que como terá dois servidores rodando sobre uma mesma configuração, deverá colocar os serviços em diferentes portas.

Para este projeto te recomendamos a usar docker-compose localmente (em seu computador) para executar a aplicação junto com a base de dados selecionada. 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.

Se tiver dúvidas sobre as diferentes (e múltiplas) opções de implantação, não hesite em consultar seus colegas e mentores.

6. Pistas, tips e leituras complementares

7 HTTP API Checklist

7.1 /

  • GET /

7.2 /auth

  • POST /auth

7.3 /users

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

7.4 /products

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

7.5 /orders

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

About

No description, website, or topics provided.

Resources

Readme
Activity

Stars

0 stars

Watchers

0 watching

Forks

0 forks
Report repository

Releases

No releases published

Packages

No packages published

Languages

  • JavaScript 100.0%