Burger Queen - API com Node.js

# Burger Queen - API com Node.js ## Índice - [1. Preâmbulo](#1-preâmbulo) - [2. Resumo do projeto](#2-resumo-do-projeto) - [3. Objetivos de aprendizagem](#3-objetivos-de-aprendizagem) - [4. Considerações gerais](#4-considerações-gerais) - [5. Critérios de aceitação mínimos do projeto](#5-critérios-de-aceitação-mínimos-do-projeto) - [6. Dicas e leituras complementares](#6-dicas-e-leituras-complementares) - [7 HTTP API Checklist](#7-http-api-checklist) ## 1. Preâmbulo Um pequeno restaurante de hambúrgueres, que está crescendo, precisa de um sistema através do qual ele possa receber pedidos usando um _tablet_ e enviá-los para a cozinha para que eles sejam preparados de forma eficiente. Nossa cliente nos pediu para desenvolver uma API que possa ser integrada com uma interface, na qual outra equipe de desenvolvedoras está trabalhando. ## 2. Resumo do projeto Por uma API, neste caso, nos referimos a um _servidor web_, que é basicamente um programa que _escuta_ uma porta de rede, através da qual podemos enviar _requisições_ (_request_) e obter _respostas_ (_response_). Um servidor web deve _gerenciar_ as requisições recebidas e produzir respostas àquelas requisições que serão enviadas de volta para o _cliente_. Quando falamos sobre _aplcações de servidor_, isso implica uma arquitetura _cliente / servidor_, onde o cliente é o programa que faz as requisições através de uma rede (por exemplo, o navegador, cURL, etc), e o _servidor_ é o programa que recebe essas requisições e respostas. O [Node.js](https://nodejs.org/) nos permite criar servidores Web super eficientes de uma forma relativamente simples, tudo isso usando JavaScript! Neste projeto começamos com um _boilerplate_ que já contém uma série de _endpoints_ (pontos de conexão ou URLs) e o objetivo é completar o aplicativo. Isso implica em ter que começar lendo as implementações existentes, familiarizar-se com a _stack_ escolhida ([Node.js] (https://nodejs.org/) e [Express] (https://expressjs.com/)) e complementá-las com uma base de dados, que para este projeto será utilizado o [PostgreSQL] (https://www.postgresql.org/). A cliente nos deu um [link para a documentação](https://documenter.getpostman.com/view/1721181/RWgozeom) que especifica o comportamento esperado da API que iremos disponibilizar por HTTP. Lá você pode encontrar todos os detalhes de quais _endpoints_ você deve implementar na aplicação, quais parâmetros são esperados, o que eles devem responder, etc. ## 3. Objetivos de aprendizagem O principal objetivo de aprendizagem é ganhar experiência com o **Node.js** como uma ferramenta para desenvolver _aplicações de servidores_, junto com uma série de ferramentas comuns usadas neste tipo de contexto (Express como framework, MongoDB ou MySQL como banco de dados, ferramentas de autenticação, etc).  Neste projeto você irá construir um servidor web que deve _servir_ `JSON` via `HTTP` e implementá-lo em um servidor na nuvem. Para completar o projeto, você terá que se familiarizar com conceitos como **rotas** (_routes_), **URLs**, **HTTP** e **REST** (verbs, request, response, headers, body, status codes...), **JSON**, **JWT** (_JSON Web Tokens_), **conexão com um banco de dados** (`MongoDB` ou` MySQL`), **variáveis de ambiente**, **deployment**, etc. ## 4. Considerações gerais  A lógica do projeto deve ser totalmente implementada em JavaScript (ES6). Neste projeto, é permitido usar bibliotecas ou frameworks, bem como extensões como `babel` (caso em que você deve incluir um comando `npm build`). Os testes devem cobrir um mínimo de 90% das _statements_, _functions_, _lines_ e _branches_. Mesmo que o _boilerplate_ não inclua a configuração para testes unitários, estes são obrigatórios. Outra exigência da equipe de QA do nosso cliente é realizar **testes _end-to-end_**, que usaremos para verificar o comportamento do ponto de vista HTTP. Esses testes, ao contrário dos testes unitários, não testam cada parte separadamente, mas testam a aplicação completa, do início ao fim. Estes testes, por não fazerem uso direto do código-fonte do aplicativo, podem ser executados diretamente em uma URL remota, já que a interface sob teste é HTTP. O _boilerplate_ já contém o _setup_ e configurações necessárias para executar todos os testes _end-to-end_ com o comando `npm run test: e2e`. ```sh # Execute testes e2e na instância local. # Inicie e execute os testes com o URL dessa instância (por padrão # http://127.0.0.1:8080). npm run test:e2e # Execute testes do e2e na URL remota REMOTE_URL=<TODO: inserir URL> npm run test:e2e ``` Os testes _end-to-end_ já estão completos no _boilerplate_, então você pode usá-los como um guia para a lista de implementação e completude do projeto. ## 5. Critérios mínimos de aceitação do projeto ### 5.1 API Segundo o estabelecido pela [documentação](https://documenter.getpostman.com/view/1721181/RWgozeom) entregue por nossa cliente, a API deve conter os seguintes endpoints: #### 5.1,1 `/` * `GET /` #### 5.1.2 `/auth` * `POST /auth` #### 5.1.3 `/users` * `GET /users` * `GET /users/:uid` * `POST /users` * `PUT /users/:uid` * `DELETE /users/:uid` #### 5.1.4 `/products` * `GET /products` * `GET /products/:productid` * `POST /products` * `PUT /products/:productid` * `DELETE /products/:productid` #### 5.1.5 `/orders` * `GET /orders` * `GET /orders/:orderid` * `POST /orders` * `PUT /orders/:orderid` * `DELETE /orders/:orderid` ### 5.2 CLI A cliente solicitou que o aplicativo tenha um comando **`npm start`** que deve ser utilizado para executar a nossa aplicação node e que também pode receber informações de configuração, como a porta na qual ouvir, em que banco de dados conectar, etc. Estes dados de configuração serão diferentes entre ambientes diferentes (desenvolvimento e produção, por exemplo). O _boilerplate_ já implementa [o código necessário](config.js). Para ler esta informação dos [argumentos de chamada](https://nodejs.org/docs/latest/api/process.html#process_process_argv) e [ambiente](https://nodejs.org/docs/latest/api/process.html#process_process_env). #### 5.2.1 Argumentos da linha de comando Podemos especificar a porta na qual o aplicativo deve iniciar, passando um argumento ao rodar nosso programa: ```sh # Execute a aplicação na prta 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 uma porta não foi especificada como um argumento de linha de comando, podemos usar a variável de ambiente `PORT` para especificar a porta. Valor padrão `8080`. * `DB_URL`: A conexão _string_ de _MongoDB_ ou _MySQL_. Quando executamos a aplicação em nosso computador (em ambiente de desenvolvimento), podemos usar o um banco de dados local, mas na produção teremos que usar as instâncias configuradas com `docker-compose` (mais sobre isso na próxima seção * `JWT_SECRET`: Nosso aplicativo implementa a autenticação usando o JWT (JSON Tokens da Web). Para poder assinar (criptografar) e verificar (descriptografar) os tokens, Nosso aplicativo precisa de um segredo. No local você pode usar o valor default (`xxxxxxxx`), mas é muito importante que você use um _secret_ de verdade em produção. * `ADMIN_EMAIL`: Opcionalmente, podemos especificar um email e uma senha para o usuário admin (root). Se esses detalhes estiverem presentes, o aplicativo irá garantir que o usuário exista e que ele tenha permissões de administrador. Valor padrão `admin @ localhost`. * `ADMIN_PASSWORD`: se tivermos especificado um` ADMIN_EMAIL`, devemos passar também uma senha para o usuário admin. Valor padrão: `changeme`. OBS: VAMOS ALTERAR O BOILERPLATE PARA FAZER SEM DOCKER?   ## 6. Dicas e leituras complementares * [Express](https://expressjs.com/) * [MongoDB](https://www.mongodb.com/) * [MySQL](https://www.mysql.com/) * [docker](https://docs.docker.com/) * [docker compose](https://docs.docker.com/compose/) * [Postman](https://www.getpostman.com) * [Variáveis de ambiente - Wikipedia](https://pt.wikipedia.org/wiki/Vari%C3%A1vel_de_ambiente) * [`process.env` - Node.js docs](https://nodejs.org/api/process.html#process_process_env) * TODO: providers de VPS recomendados. * [ssh](https://pt.wikipedia.org/wiki/Secure_Shell) *** ## 7. HTTP API Checklist ### 7.1 `/` * [ ] `GET /` ### 7.2 `/auth` * [ ] `POST /auth` ### 7.3 `/users` * [ ] `GET /users` * [ ] `GET /users/:uid` * [ ] `POST /users` * [ ] `PUT /users/:uid` * [ ] `DELETE /users/:uid` ### 7.4 `/products` * [ ] `GET /products` * [ ] `GET /products/:productid` * [ ] `POST /products` * [ ] `PUT /products/:productid` * [ ] `DELETE /products/:productid` ### 7.5 `/orders` * [ ] `GET /orders` * [ ] `GET /orders/:orderid` * [ ] `POST /orders` * [ ] `PUT /orders/:orderid` * [ ] `DELETE /orders/:orderid`

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.