Template para microservicios en NodeJs, se toma como ejemplo un API de Gender.
Tener instalado:
- Clonamos el repositorio en una carpeta local:
`` - Ir hacia la carpeta
- Ejecutar en la terminal
npm i: Comando para poder instalar todas las dependencias necesarias para correr la aplicación.npm run dev: Comando que va a transpilar todo el codigo typescript a JS y luego va a correr con un watch la aplicación.
Para poder correr los tests hace falta ejecutar el comando:
npm run test
Para poder desarrollar la arquitectura se siguió la guía más famosa de la comunidad en Mejores practicas para NODE.JS.
Para armar la estructura se basó en la primicia "Estructura por componentes" la misma define que es una mala practica agrupar archivos por rol técnico (Controllers,Services,etc...) y es una buena practica agrupar archivos por componentes.
Para el manejo de errores, entre otras, se tuvieron en cuenta las siguientes especificaciones:
- Distinguir errores operacionales
- Manejo de erroes asíncronos (solucionado con dependencia "express-async-errors").
Aclaración: Para no estar atado a una solución especifica para express se puede resolver con middleware. - Centralizar el manejo de errores sin estar adentro de un middleware
- Documentar errores en Swagger
- Catch unhandledRejection y uncaughtException
- Logueo de errores por niveles
Como equipo adoptamos dos herramientas para facilitarnos la estandarización de código en cuanto a formato y reglas.
Ellas son:
Las mismas nos permite que el equipo pueda desarrollar siguiendo un estandar de reglas, tanto para formateo, nomeclaturas, formas de tipificar variables, funciones, etc... Si bien puede ser molesto al principio esto nos logra dar un valor como equipo y facilitar el control de calidad/estandar del código.
Prettier es una herramienta que nos ayuda a estandarizar el formato del código en base a ciertas "opiniones"/reglas, las cuales podemos modificar.
En nuestro caso, las reglas nuestras son:
{ "singleQuote": true, "printWidth": 120 }
esto quiere decir que utilizamos comillas simples y dejamos un espacio de 120px al momento de sangría.
Prettier se puede integrar con VsCode. El cual tiene como beneficio, entre otros, poder guardar un archivo y que se formatee automaticamente.
En todo caso, ejecutando el comando npm run lint se van a verificar las reglas y, en caso de poder, arreglar automaticamente.
Eslint es una herramienta linting utilizado para Javascript (y Typescript con el plugin Eslint-Typescript) que tiene como función principal revisar nuestro código tratando de encontrar errores o futuros bugs. Para esto cuenta con un conjunto de reglas configuradas previamente. En nuestro proyecto tenemos ciertas configuraciones que valen la pena aclarar:
- Utilizamos el plugin de typescript para que sea compatible con el mismo
- Tenemos seteadas como True las variables para que soporte Ecmascript 6, Node, Jest.
- Nuestro conjunto de reglas son las recomendadas por Eslint
- Delegamos el formateo en Prettier desactivando el ofrecido por Eslint
- Agregamos el plugin de seguridad para que detecte reglas de seguridad
- Agregamos que toda funcion que no retorne un tipo es un error, por lo cual si surge el mismo no va a superar la etapa de build.
- La regla no-used-vars posee un issue el cual todavía no fue solucionado. La regla consiste en detectar como error variables que son declaradas pero no son utilizadas, si bien es una regla útil para poder estandarizar el código el issue consiste en detectar falsos positivos cuando se importan tipos que son utilizados en funciones. Por lo cual se decidió, hasta la resolución del mismo, deshabilitar dicha regla.
Las dependencias usadas para las pruebas son:
Con estas dos herramientas podemos abarcar lo que son las pruebas unitarias e integrales.
Para el logging se decidió utilizar las dependencias:
La primera para loguear todo request/response con metadata predefinada y configurada por nosotros. La segunda para loguear todo evento que surja de nuestra aplicación, con su respectiva metadata.
El healthcheck que armamos es para saber la salud de nuestra aplicación. La misma puede tener dos estados:
- Healthy: Posee todas las dependencias saludables.
- Unhealthy: Una de las dependencias no esta saludable.
Se considera que la aplicación esta saludable cuando todas sus dependencias lo estan.
Ejemplo de respuesta de aplicación saludable:
{
"status": "HEALTHY",
"dependencies":
[
{
"status": "HEALTHY",
"name": "CienciaArgentinaDb connection"
}
]
}Ejemplo de respuesta de aplicación no saludable:
{
"status": "UNHEALTHY",
"dependencies":
[
{
"status": "HEALTHY",
"name": "CienciaArgentinaDb connection"
},
{
"status": "UNHEALTHY",
"name": "Service2 connection",
"detail":"Connection Time Out"
}
]
}PM2 es un administrador de procesos para Javascript/Node.JS el cual nos facilita ciertas responsabilidades como por ejemplo:
- Utilizar todos los CPU cores
- Reinicio de proceso en caso de falla
- Modo Cluster
- Gestión de registros
Las anteriores caracteristicas mencionadas estan cubiertas gracias a la arquitectura que poseemos adentro de OCP junto a su contenedor.
Es por esto que surge pm2-runtime, el cual tiene como objetivo envolver sus aplicaciones en un entorno de producción Node.js adecuado al ejecutarlas dentro de un contenedor.
Entre los problemas que resuelve se destacan:
- Segundo proceso de respaldo para una alta confiabilidad de la aplicación
- Control de flujo de proceso
Se decidió usar un ORM llamado ObjectionJs.
La decisión de Objection fueron por las siguientes razones:
- Es un ORM con constante apoyo y soporte por la comunidad
- Soporta Typescript
- Basado en Knex
- Soporta migraciones
- Cross-database and cross-schema queries
- Logging
- Hooks
entre otras caracteristicas.
El mayor poder es el rendimiento, realizamos un benchmark contra TypeOrm y nos dio que Objection es un 50% (Mínimo) más eficiente. Link para benchmark detallado.
- axios: Cliente HTTP basado en promesas para node.js
- compression: Middleware de compresión.
- dotenv: Módulo de dependencia para cargar variables de entorno de un .env .
- express: Framework web con gran cantidad de métodos de utilidad HTTP y middleware a su disposición, para crear una API robusta de una forma más rápida y sencilla.
- express-async-errors: Permite manejar las excepciones asincronas sin tener que parchear en todos los métodos Routers.
- oracledb: Driver para poder conectarse a una base de datos Oracle.
- pm2-runtime: Administrador de procesos utilizado por la aplicación para el entorno productivo.
- reflect-metadata: Permite usar @decorators entre otras caracteristicas.
- ts-node: Cli de Typescript que me permite, entre otras caracteristicas, ejecutar en modo watch la aplicación.
- supertest: Proporciona una abstracción de alto nivel para probar HTTP.
- jest: Framework de testing utilizado para los test unitarios
- typeorm: ORM utilizado por el aplicativo
- typescript: Lenguaje para lograr un type-safe en Javascript.
- uuid: Permite generar un uuid basado en timestamp (v1) o random (v4)
- express-winston: Proporciona funcionabilidades para loguear request/response.
- winston: Logger del aplicativo.
- performance-now:
- request:
- request-promise:
- Optimizar memoria
- Optimizar seguridad
- Optimizar docker
- Subir dependencias comunes a otro repo
- Coverage 80%
- Migrar de TypeOrm a ObjectionJs
Para más información podes consultar la Wiki.
- Node.JS Best Practices - Mejores practicas de la comunidad en NODE.js
- Typescript - Mecanografíado para tipar Javascript utilizado en el proyecot
- Objection - ORM
- Jest - Framework utilizado para test
- PM2-RUNTIME - Herramienta utilizada para manejar los procesos en producción