Skip to content

API REST para la gesti贸n de pedidos de un restaurante. La aplicaci贸n fue empaquetada en un contenedor de Docker y desplegada en un Droplet de Digital Ocean. 馃崝馃摫

Notifications You must be signed in to change notification settings

omairapalacios/burger-queen-api

Repository files navigation

Burger Queen - API con Node.js

脥ndice

1. Pre谩mbulo

Un peque帽o restaurante de hamburguesas, que est谩 creciendo, necesita un sistema a trav茅s del cual puedan tomar pedidos usando una tablet, y enviarlos a la cocina para que se preparen ordenada y eficientemente.

Este proyecto tiene dos 谩reas: interfaz (cliente) y API (servidor). Nuestra clienta nos ha solicitado desarrollar la API que se debe integra con la interfaz, que otro equipo de desarrolladoras est谩 trabajando simult谩neamente

2. Resumen del proyecto

Con una API en este caso nos referimos a un servidor web, que es b谩sicamente un programa que escucha en un puerto de red, a trav茅s del cual podemos enviarle consultas (request) y obtener respuestas (response).

Un servidor web debe manejar consultas entrantes y producir respuestas a esas consultas que ser谩n enviadas de vuelta al cliente. Cuando hablamos de aplicaciones de servidor, esto implica una arquitectura de cliente/servidor, donde el cliente es un programa que hace consultas a trav茅s de una red (por ejemplo el navegador, cURL, ...), y el servidor es el programa que recibe estas consultas y las responde.

Node.js nos permite crear servidores web super eficientes de manera relativamente simple y todo esto usando JavaScript!

En este proyecto partimos de un boilerplate que ya contiene una serie de endpoints (puntos de conexi贸n o URLs) y nos piden completar la aplicaci贸n. Esto implica que tendremos que partir por leer la implementaci贸n existente, y familiarizarnos con el stack elegido (Node.js y Express) y complementarlo con un motor de bases de datos, el cual tu deber谩s elegir entre MongoDB y MySQL.

La clienta nos ha dado un link a la documentaci贸n que especifica el comportamiento esperado de la API que expondremos por HTTP. Ah铆 puedes encontrar todos los detalles de qu茅 endpoints debe implementar la aplicaci贸n, qu茅 par谩metros esperan, qu茅 deben responder, etc.

3. Objetivos de aprendizaje

El objetivo principal de aprendizaje es adquirir experiencia con Node.js como herramienta para desarrollar aplicaciones de servidor, junto con una serie de herramientas comunes usadas en este tipo de contexto (Express como framework, MongoDB o MySQL como base datos, contenedores de docker, servidores virtuales, etc).

En este proyecto tendr谩s que construir un servidor web que debe servir JSON sobre HTTP, y desplegarlo en un servidor en la nube.

Para completar el proyecto tendr谩s que familiarizarte con conceptos como rutas (routes), URLs, HTTP y REST (verbs, request, response, headers, body, status codes...), JSON, JWT (JSON Web Tokens), conexi贸n con una base datos (MongoDB o MySQL), variables de entorno, deployment, contenedores de docker...

Node

  • Instalar y usar modules
  • npm scripts

Express

  • Rutas
  • middlewares

HTTP

  • Request
  • Response
  • Headers
  • Body
  • Verbos HTTP
  • Codigos de status de HTTP
  • Encodings y JSON
  • CORS

Autenticaci贸n

  • JWT
  • C贸mo guardar y validar contrase帽as

Testing

  • Tests de integraci贸n
  • Tests unitarios

Frontend Development

  • Variables de entorno
  • SSH
  • SSH keys
  • Qu茅 es un VPS

MongoDB o MySQL (seg煤n corresponda)

  • Instalaci贸n
  • Conexi贸n a trav茅s de cliente
  • Connection string
  • Comandos/Queries de creacion, lectura, modificaci贸n y eliminaci贸n

Deployment

  • Contenedores
  • Qu茅 es Docker
  • Qu茅 es Docker compose
  • Uso de docker-compose

Colaboraci贸n y Organizaci贸n con Git y Github

  • Forks
  • Branches
  • Pull Requests
  • Tags
  • Projects
  • Issues
  • Labels
  • Milestones

Buenas pr谩cticas de desarrollo

  • Modularizaci贸n
  • Nomenclatura / Sem谩ntica
  • Linting

4. Consideraciones generales

Este proyecto se realizar谩 en duos y deber谩 integrarse con el proyecto Burger Queen API client que desarrolle simult谩neamente el quipo de Frontend developers de tu squad.

La l贸gica del proyecto debe estar implementada completamente en JavaScript (ES6). En este proyecto est谩 permitido usar librer铆as o frameworks, asi como extensiones al lenguaje con babel (caso en el cual deber谩s incluir un comando npm build).

Los tests deben cubrir un m铆nimo del 90% de statements, functions, lines y branches. Si bien el boilerplate no incluye la configuraci贸n para pruebas unitarias, estas son obligatorias.

Otro requerimiento del equipo de QA de nuestra clienta es realizar pruebas end-to-end, que usaremos para verificar el comportamiento desde el punto de vista de HTTP, desde afuera del servidor. Estos tests, a diferencia de las pruebas unitarias, no prueban cada pieza por separado sino que prueban la aplicaci贸n completa, de principio a fin. Estas pruebas, al no hacer uso directo del c贸digo fuente de la aplicaci贸n, pueden ejecutarse directamente sobre una URL remota, ya que la interfaz sometida a pruebas es HTTP.

El boilerplate ya contiene el setup y configuraci贸n necesaria para ejecutar todos los tests end-to-end con el comando npm run test:e2e.

# Corre pruebas e2e sobre instancia local. Esto levanta la aplicaci贸n con npm
# start y corre los tests contra la URL de esta instancia (por defecto
# http://127.0.0.1:8080).
npm run test:e2e

# Corre pruebas e2e sobre URL remota
REMOTE_URL=<TODO: poner URL> npm run test:e2e

Las pruebas end-to-end ya est谩n completas en el boilerplate, as铆 que puedes usarlas como gu铆a de implementaci贸n y checklist de completitud.

5. Criterios de aceptaci贸n m铆nimos del proyecto

5.1 API

Seg煤n lo establecido por la documentaci贸n entregada por nuestra clienta, la API debe exponer los siguientes 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

La clienta nos ha solicitado que la aplicaci贸n cuente un comando npm start que se debe encargar de ejecutar nuestra aplicaci贸n node y que adem谩s pueda recibir informaci贸n de configuraci贸n, como el puerto en el que escuchar, a qu茅 base datos conectarse, etc. Estos datos de configuraci贸n ser谩n distintos entre diferentes entornos (desarrollo, producci贸n, ...). El boilerplate ya implementa el c贸digo necesario para leer esta informaci贸n de los argumentos de invocaci贸n y el entorno.

5.2.1 Argumentos de l铆nea de comando

Podemos especificar el puerto en el que debe arrancar la aplicaci贸n pasando un argumento a la hora de invocar nuestro programa:

# Arranca la aplicaci贸n el puerto 8888 usando npm
npm start 8888

5.2.2 Variables de entorno

Nuestra aplicaci贸n usa las siguientes variables de entorno:

  • PORT: Si no se ha especificado un puerto como argumento de l铆na de comando, podemos usar la variable de entorno PORT para especificar el puerto. Valor por defecto 8080.
  • DB_URL: El string de conexi贸n de MongoDB o MySQL. Cuando ejecutemos la aplicaci贸n en nuestra computadora (en entorno de desarrollo), podemos usar el una base de datos local, pero en producci贸n deberemos utilizar las instancias configuradas con docker-compose (mas sobre esto en la siguiente secci贸n de Deployment)
  • JWT_SECRET: Nuestra aplicaci贸n implementa autenticaci贸n usando JWT (JSON Web Tokens). Para poder firmar (cifrar) y verificar (descifrar) los tokens, nuestra aplicaci贸n necesita un secreto. En local puedes usar el valor por defecto (xxxxxxxx), pero es muy importante que uses un secreto de verdad en producci贸n.
  • ADMIN_EMAIL: Opcionalmente podemos especificar un email y password para el usuario admin (root). Si estos detalles est谩n presentes la aplicaci贸n se asegurar谩 que exista el usuario y que tenga permisos de administrador. Valor por defecto admin@localhost.
  • ADMIN_PASSWORD: Si hemos especificado un ADMIN_EMAIL, debemos pasar tambi茅n una contrase帽a para el usuario admin. Valor por defecto: changeme.

5.3 Deployment

Nuestra clienta nos ha manifestado que su equipo de devops est谩 siempre con muchas tareas, por por lo que nos pide como requerimiento que la aplicaci贸n est茅 configurada con docker-compose para que pueda ser desplegada sin dificultades en cualquier entorno.

El boilerplate ya cuenta con una configuraci贸n incial de docker-compose para la aplicaci贸n de node, tu tarea ser谩 extender esa configuraci贸n para incluir la configuraci贸n de base de datos que hayas elegido. Ten en cuenta que como vas a tener dos servidores corriendo sobre una misma configuraci贸n, deber谩s exponer los servicios en diferentes puertos.

Una vez que tengas tu configuraci贸n de docker-compose, deber谩s crear un servidor en la nube (VPS) (en el 谩rea de recursos te proponemos algunas alternativas de proveedores), acceder a 茅l a trav茅s de ssh, clonar tu repositorio y ejecutar docker-compose up para levantar la aplicaci贸n y la documentaci贸n, para que queden online y accesibles.

6. Pistas, tips y lecturas complementarias


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

About

API REST para la gesti贸n de pedidos de un restaurante. La aplicaci贸n fue empaquetada en un contenedor de Docker y desplegada en un Droplet de Digital Ocean. 馃崝馃摫

Topics

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages

  • JavaScript 100.0%