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 web (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.
Con una API en este caso nos referimos a un servidor web, nuestro 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. 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.
Partimos de un boilerplate que ya contiene una serie de endpoints (puntos de conexión o URLs).
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.
Las herramientas para desarrollar esta aplicación de servidor son:
- Node.js
- Express como framework
- MongoDB como base datos
- Contenedores de Docker.
Este proyecto es un servidor web que debe estar en JSON sobre HTTP, y también cuenta con un despliegue en la nube..
Especificación de endpoints
Según lo establecido por la documentación entregada por nuestra clienta, la API debe exponer los siguientes endpoints:
GET /
POST /auth
GET /usersGET /users/:uidPOST /usersPUT /users/:uidDELETE /users/:uid
GET /productsGET /products/:productidPOST /productsPUT /products/:productidDELETE /products/:productid
Los tests deben cubrir un mínimo del 90% de statements, functions, lines y branches.
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.
GET /ordersGET /orders/:orderIdPOST /ordersPUT /orders/:orderIdDELETE /orders/:orderId
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.
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 8888Nuestra aplicación usa las siguientes variables de entorno:
PORT: Valor por defecto8080.DB_URL: Conexión de MongoDB. 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 condocker-compose(mas sobre esto en la siguiente sección de Deployment)JWT_SECRET: Implementamos la 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: Valor por defectoadmin@localhost.ADMIN_PASSWORD: Valor por defecto:changeme.