---
# System prepended metadata

title: 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).

<!-- tirei o Docker da lista pois não vamos usar (motivo Windows)
 -->
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

<!-- Este projeto será realizado em duplas e deve ser integrado ao projeto
[Cliente da API do Burger Queen](link) que a equipe desenvolve simultaneamente
de desenvolvedores Frontend do seu time. -->

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?

<!-- ### 5.3 Deployment

Nosso cliente nos disse que sua equipe de _devops_ está sempre com muitas
tarefas, por isso nos pede como um requisito que a aplicação seja configurada
com `docker-compose` para que possa ser implementado sem dificuldade em qualquer
meio ambiente

O _boilerplate_ já tem uma configuração inicial do `docker-compose` para
nossa aplicação node, sua tarefa será entender essa configuração para incluir a
configuração do banco de dados, bem como o servidor.
Tenha em mente que, como você terá dois servidores rodando na mesma
configuração, você deve expor os serviços em portas diferentes.

Depois de ter sua configuração `docker-compose`, você deve criar um servidor
na nuvem (VPS) (na área de recursos propomos algumas alternativas para
provedores), acessá-lo através de `ssh`, clonar seu repositório e executar
`docker-compose up` para dar deploy na aplicação e documentação, para que
permaneçam online e acessíveis. -->

<!-- ## 6. Evaluación

NOTA: Esta sección incluye una lista de habilidades que se podrán tener en
cuenta a la hora de evaluar el proyecto. Los niveles esperados son _sugerencias_
así como _guías_ en el diseño curricular, pero no reglas absolutas.

Te aconsejamos revisar [nuestra rúbrica](https://docs.google.com/spreadsheets/u/1/d/e/2PACX-1vRktPN4ilZtkRN5tUb3DVhgeihwlzk63_-JI3moA-bXpKDbHDioAK2H3qbrwWNb0Ql4wX22Tgv7-PDv/pubhtml)
para ver la descripción detallada de cada _habilidad_ y cada _nivel_. Te
recomendamos también que trates de aplicarte la rúbrica a tí misma y/o a los
proyectos de tus compañeras a lo largo del Bootcamp para ir viendo tu evolución.

### General

| Característica | Nivel esperado |
|----------------|----------------|
| Completitud    | 4              |

### Habilidades Blandas

| Habilidad                    | Nivel esperado |
|------------------------------|----------------|
| Planificación y organización | 4              |
| Autoaprendizaje              | 4              |
| Presentaciones               | 4              |
| Adaptabilidad                | 4              |
| Solución de problemas        | 4              |
| Responsabilidad              | 4              |
| Dar y recibir feedback       | 4              |
| Comunicación eficaz          | 4              |

### Tech

| Habilidad              | Nivel esperado |
| ---------------------- | -------------- |
| **Computer Science**                    |
| Lógica                 | 2              |
| Arquitectura           | 3              |
| **Source Control Management**           |
| Git                    | 3              |
| GitHub                 | 3              |
| **JavaScript**                          |
| Estilo                 | 3              |
| Nomenclatura/semántica | 3              |
| Funciones/modularidad  | 4              |
| Estructuras de datos   | 3              |
| Tests                  | 3              | -->

## 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`