Ahora hay disponible una cantidad decente de material para escribir la API en node.js. La mayoría de ellos están en forma de tutoriales y demostraciones en la documentación. Esto es suficiente para descubrir rápidamente y escribir algo propio. Pero rara vez encuentran detalles de por qué esto se hace de esa manera. Y algunos puntos se omiten por completo por simplicidad y brevedad.Este artículo está destinado a llenar algunos vacíos que puedan surgir y, en última instancia, mejorar su servicio en node.js.PD En ningún caso me considero un experto: hay espacio para crecer. Pero al mismo tiempo hay algo para compartir.Estructura del archivo del proyecto
La estructura de archivos es una cosa básica, pero muy importante. Al crearlo, vale la pena considerar la posibilidad de escalar el servicio, por esta razón no vale la pena colocar archivos en la estructura plana de un directorio. Necesita una jerarquía, necesita modularidad.Al nombrar directorios, debe cumplir con los estándares establecidos. Esto ayudará a colegas y en unos meses a descubrir rápidamente dónde y qué se encuentra.Ejemplo de estructura de archivosrc/
controllers/
users/
index.js
index.js
db/
mongo/
index.js
index.js
helpers/
middlewares/
auth.js
models/
users.js
routes/
users/
index.js
index.js
index.js
.eslintrc
.gitignore
README.md
...
package.json
Notas:- Todos los archivos ejecutables deben ubicarse en ./src.
Esto le permitirá separar los archivos fuente del mecanografiado compilado o babel, que se ubicarán en ./dist o ./build.
También facilitará la configuración de linters y otras herramientas configurables, ya que los archivos de destino se encuentran en un directorio separado.
Coloque todas las entidades de controlador y ruta en directorios separados. Esto abrirá un ./routes o ./controller y verá solo un archivo index.js que importa y exporta entidades de subdirectorio.
Esto le permitirá navegar rápidamente por la funcionalidad existente, ya que describe solo la interfaz de los controladores o enrutadores sin profundizar en su implementación.
Acerca de la compilación de Javascript
Por supuesto, no puede usar babel o mecanografiado para convertir su javascript. Como regla general, los nuevos estándares ECMAScript terminan rápidamente en node.js, y usted, con la excepción de javascript basado en navegador, puede controlar su soporte.Pero estoy convencido de que vale la pena usarlos. Y es por eso:- La última versión de Node.js no siempre está disponible para producción.
- Node.js (v. 13) todavía tiene problemas para admitir módulos ECMAScript, aunque aparecieron y dejaron la bandera, todavía son experimentales. Para vender temprano.
Considere agregar babel al proyecto:Instale las dependencias:npm install @babel/core @babel/node @babel/preset-env --save-dev
Agregue el archivo de configuración .babelrc a la raíz del proyecto{
"presets": [
"@babel/preset-env"
]
}
Ejemplo de ejecución de script"start": "nodemon --exec babel-node src/index.js",
Notas:- Al instalar dependencias, no olvide colocar el modificador --save-dev (-D) solo durante la fase de desarrollo. Es necesario al menos para la semántica.
Sobre la necesidad de linter
Comencemos con el hecho obvio: se necesitan linters. Escribimos código, mucho código. Gran parte de eso, ellos mismos no son capaces de controlar su uniformidad. Este artículo está increíblemente mejorado en el desarrollo del equipo.Y la uniformidad es la clave para la legibilidad del código.Queda la pregunta sobre el rigor de la pelusa. La elección de cuál debe basarse en el tamaño del equipo, su nivel profesional, un criterio importante es el proyecto en sí.Agregando un linter simple al proyectoInstalemos las dependencias:npm install eslint --save-dev
Agregue el archivo de configuración .eslintrc a la raíz del proyecto:{
"env": {
"node": true,
"es6": true,
},
"extends": "eslint:recommended"
}
Como regla, tal configuración no es suficiente. Aquí expanda las reglas usted mismo o eche un vistazo más de cerca a las opciones más rigurosas preparadas. ,
...
"extends": "eslint:recommended",
"rules": {
"quotes": ["error", "single"]
}
}
Uso de un linter más estrictoExisten varias configuraciones populares basadas en las mismas guías de estilo.- Google
npm install --save-dev eslint-config-google
- Airbnb
npm install --save-dev eslint-config-airbnb-base eslint-plugin-import
- Idiomático
npm install --save-dev eslint-config-idiomatic
En consecuencia, será necesario corregir .eslintrc{
"env": {
"node": true,
"es6": true,
},
"extends": "google" | "airbnb-base" | "idiomatic"
}
También es necesario agregar el lanzamiento de linter a un script separado."lint": "eslint ./src --cache && echo \"eslint: no lint errors\"",
"lint:fix": "eslint ./src --fix && echo \"eslint: no lint errors\""
Sobre el lanzamiento de la aplicación
Cualquier persona que tenga acceso al repositorio del proyecto debería poder ejecutarlo. Si puede hacerlo y cuánto tiempo le tomará hacerlo es uno de los criterios de calidad de su proyecto.Es importante documentar por adelantado cómo iniciar el servicio paso a paso en el archivo README.md, así como prescribir comandos para las acciones principales."start": "npm run dev",
"dev": "nodemon --exec babel-node ./src/index.js",
"build": "babel ./src --out-dir ./build",
"prod": "NODE_ENV=production node ./build/index.js",
"lint": "eslint ./src --cache && echo \"eslint: no lint errors\"",
Para usar los comandos anteriores, es posible que deba instalar los siguientes paquetes:npm install --save-dev @babel/cli nodemon babel-node
Nota:- Si incluso agregó los comandos básicos a package.json, siga describiendo el proceso de inicio en README.md.
Conclusión
Inicialmente, el artículo quería cubrir muchas más recomendaciones sobre cómo escribir una API en node.js, pero quiero encajar en 3-5 minutos. leyendo el artículo Sujeto a buenos comentarios, se lanzará un seguimiento.