- 1. Preámbulo
- 2. Resumen del proyecto
- 3. API endpoints
- 4. Pruebas End-To-End
- 5. Variables de entorno
- 6. Demo
- 7. Objetivos de aprendizaje
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 puede integrar con la interfaz, que otro equipo de desarrolladoras está trabajando simultáneamente.
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) usando el protocolo HTTP (o HTTPS).
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, etc.), y el servidor es el programa que recibe estas consultas y las responde.
Node.js nos permite crear servidores web súper 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. Recomendamos el uso de MongoDB y tenemos una guía para empezar con MongoDB.
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.
GET /
POST /auth
GET /usersGET /users/:uidPOST /usersPATCH /users/:uidDELETE /users/:uid
GET /productsGET /products/:productidPOST /productsPATCH /products/:productidDELETE /products/:productid
GET /ordersGET /orders/:orderIdPOST /ordersPATCH /orders/:orderIdDELETE /orders/:orderId
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.
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:e2eNuestra aplicación usa las siguientes variables de entorno:
PORT: Si no se ha especificado un puerto como argumento de línea de comando, podemos usar la variable de entornoPORTpara especificar el puerto. Valor por defecto8080.DB_URL: El string de conexión de MongoDB. Cuando ejecutemos la aplicación en nuestra computadora (en entorno de desarrollo), podemos usar el una base de datos local.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 defectoadmin@localhost.com.ADMIN_PASSWORD: Si hemos especificado unADMIN_EMAIL, debemos pasar también una contraseña para el usuario admin. Valor por defecto:changeme.
Video de las pruebas de la API REST en Postman:
-
Instalar y usar módulos con npm
-
Configuración de package.json
-
Configuración de npm-scripts
-
Pruebas unitarias (unit tests)
-
Pruebas asíncronas
-
Uso de mocks y espías
-
Pruebas de integración (end-to-end)
-
Módulos de ECMAScript (ES Modules)
-
Módulos de CommonJS
-
Uso de linter (ESLINT)
-
Uso de identificadores descriptivos (Nomenclatura y Semántica)
-
Git: Instalación y configuración
-
Git: Control de versiones con git (init, clone, add, commit, status, push, pull, remote)
-
Git: Integración de cambios entre ramas (branch, checkout, fetch, merge, reset, rebase, tag)
-
GitHub: Creación de cuenta y repos, configuración de llaves SSH
-
GitHub: Despliegue con GitHub Pages
-
GitHub: Colaboración en Github (branches | forks | pull requests | code review | tags)
-
GitHub: Organización en Github (projects | issues | labels | milestones | releases)
-
Manejo de rutas
-
Uso y creación de middleware
-
Consulta o petición (request) y respuesta (response).
-
Cabeceras (headers)
-
Cuerpo (body)
-
Verbos HTTP
-
Códigos de status de HTTP
-
Encodings y JSON
-
CORS (Cross-Origin Resource Sharing)
-
JWT (JSON Web Token)
-
Almacenamiento y acceso de contraseñas
-
Variables de entorno
-
Contenedores (Docker)
-
Docker compose
-
Cloud Functions
-
MongoDB
-
Operaciones CRUD (Create-Read-Update-Delete)
-
Modelos y esquemas de datos
-
Respaldo y restauración (backup/restore)
-
Modelado de datos
-
Conexión
-
Changelog: archivo que contiene una lista ordenada cronológicamente de los cambios notables para cada versión de un proyecto
-
Swagger
Links
- [Link a la documentación - BurgerQueenAPI](https://app.swaggerhub.com/apis-docs/ssinuco/BurgerQueenAPI/2.0.0) - [Link a la documentación - Swagger](https://swagger.io/docs/)
-
Despliegue
Links
- Vercel es una opción enfocada a aplicaciones web estáticas (como las que se construyen con React). Sin embargo, Vercel también nos permite desplegar aplicaciones node usando Serverless Functions.
- MongoDB Atlas es una muy buena opción para alojar nuestra base datos de producción, la cuál podemos usar en conjunción con cualquiera de las opciones mencionadas arriba.
-
Docker-compose
Detalles
Lee la guía para docker incluida en el proyecto para más información. Para probar tu configuración de docker, te recomendamos usar `docker-compose` localmente (en tu computadora) para ejecutar la aplicación junto con la base de datos.
-
Despliegue
Detalles
Con respecto al despliegue, puedes elegir el proveedor (o proveedores) que prefieras junto con el mecanismo de despliegue y estrategia de alojamiento. Te recomendamos explorar las siguientes opciones:
- Si quieres explorar opciones más personalizadas y ver docker del lado del servidor puedes considerar proveedores como AWS (Amazon Web Services) o GCP (Google Cloud Platform), ambos tienen algún tipo de free tier así como tanto instancias de servidores virtuales (VPS) donde configurar nuestro propio Docker o servicios para desplegar aplicaciones en contenedores (por ejemplo Compute Engine de GCP o Elastic Container Service de AWS).
-
Extra links

