Get best of the week

Comment améliorer votre service API sur node.js. Partie 1

Une quantité décente de matériel est désormais disponible lors de l'écriture de l'API sur node.js. La plupart d'entre eux sont sous forme de tutoriels et de démos dans la documentation. Cela suffit pour comprendre et écrire rapidement quelque chose qui leur est propre. Mais ils trouvent rarement des détails sur la raison pour laquelle cela est fait de cette façon. Et certains points sont omis pour des raisons de simplicité et de concision.

Cet article est destiné à combler certaines lacunes qui pourraient survenir et, à terme, à améliorer votre service sur node.js.

PS En aucun cas je ne me considère comme un expert: il y a de la place pour grandir. Mais en même temps, il y a quelque chose à partager.

Structure du fichier de projet


La structure des fichiers est une chose basique mais très importante. Lors de sa création, il convient d'envisager la possibilité de faire évoluer le service, c'est pourquoi il ne vaut pas la peine de placer des fichiers dans la structure plate d'un répertoire. Besoin d'une hiérarchie, besoin de modularité.

Lorsque vous nommez des répertoires, vous devez respecter les normes établies. Cela aidera les collègues et en quelques mois à savoir rapidement où et ce qui se trouve.

Exemple de structure de fichier

src/
    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

Remarques:

  1. Tous les fichiers exécutables doivent être situés dans ./src.
    Cela vous permettra de séparer les fichiers source des typescript ou babel compilés, qui seront situés dans ./dist ou ./build.
    Cela facilitera également la configuration des linters et d'autres outils configurables, car les fichiers cibles sont situés dans un répertoire séparé.

  2. Placez toutes les entités de contrôleur et de route dans des répertoires distincts. Cela ouvrira un ./routes ou ./controller et ne verra qu'un seul fichier index.js qui importe et exporte des entités de sous-répertoire.
    Cela vous permettra de naviguer rapidement dans les fonctionnalités existantes, car il ne décrit que l'interface des contrôleurs ou des routeurs sans plonger dans leur implémentation.

À propos de la compilation Javascript


Bien sûr, vous ne pouvez pas utiliser babel ou tapuscript pour convertir votre javascript. En règle générale, les nouvelles normes ECMAScript se retrouvent rapidement dans node.js et vous, à l'exception du javascript basé sur un navigateur, pouvez contrôler leur prise en charge.
Mais je suis convaincu qu'ils valent la peine d'être utilisés. Et c'est pourquoi:

  1. La dernière version de Node.js n'est pas toujours disponible pour la production.
  2. Node.js (v. 13) a toujours des problèmes avec la prise en charge des modules ECMAScript, bien qu'ils soient apparus et aient quitté le drapeau, ils sont encore expérimentaux. A vendre tôt.

Pensez à ajouter babel au projet:

Installez les dépendances:

npm install @babel/core @babel/node @babel/preset-env --save-dev

Ajoutez le fichier de configuration .babelrc à la racine du projet
{
    "presets": [
      "@babel/preset-env"
    ]
}

Exemple d'exécution de script
"start": "nodemon --exec babel-node src/index.js",

Remarques:

  1. Lors de l'installation des dépendances, n'oubliez pas de placer le commutateur --save-dev (-D) uniquement pendant la phase de développement. Il est nécessaire au moins pour la sémantique.

À propos du besoin de linter


Commençons par le fait évident: des linters sont nécessaires. Nous écrivons du code, beaucoup de code. Une grande partie de cela, ils ne sont pas eux-mêmes en mesure de contrôler son uniformité. Cet article est incroyablement amélioré dans le développement d'équipe.

Et l'uniformité est la clé de la lisibilité du code.

La question demeure de la rigueur du linter. Le choix doit être basé sur la taille de l'équipe, son niveau professionnel, un critère important est le projet lui-même.

Ajout d'un simple linter au projet Installons

les dépendances:

npm install eslint --save-dev

Ajoutez le fichier de configuration .eslintrc à la racine du projet:

{
    "env": {
        "node": true,
        "es6": true,
    },
    "extends": "eslint:recommended"
}

En règle générale, une telle configuration ne suffit pas. Ici, développez les règles vous-même ou examinez de plus près les options les plus rigoureuses préparées.

 ,  
...
    "extends": "eslint:recommended",
    "rules": {
        "quotes": ["error", "single"]
    }
}

Utilisation d'un linter plus strict

Il existe plusieurs configurations populaires basées sur les mêmes guides de style.

  • Google

     npm install --save-dev eslint-config-google
  • Airbnb

     npm install --save-dev eslint-config-airbnb-base eslint-plugin-import
  • Idiomatique
     npm install --save-dev eslint-config-idiomatic

En conséquence, il sera nécessaire de corriger .eslintrc

{
    "env": {
        "node": true,
        "es6": true,
    },
    "extends": "google" | "airbnb-base" | "idiomatic"
}

Il est également nécessaire d'ajouter le lancement du linter à un script séparé.

"lint": "eslint ./src --cache && echo \"eslint: no lint errors\"",
"lint:fix": "eslint ./src --fix && echo \"eslint: no lint errors\""

À propos du lancement de l'application


Toute personne ayant accès au référentiel de projet doit pouvoir l'exécuter. Qu'il puisse le faire et combien de temps il lui faudra pour le faire est l'un des critères de qualité de votre projet.

Il est important de documenter à l'avance comment démarrer le service étape par étape dans le fichier README.md, ainsi que de prescrire des commandes pour les actions 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\"",

Pour utiliser les commandes ci-dessus, vous devrez peut-être installer les packages suivants:

npm install --save-dev @babel/cli nodemon babel-node

Remarque:

  1. Si vous avez même ajouté les commandes de base à package.json, décrivez toujours le processus de démarrage dans README.md.

Conclusion


Initialement, l'article voulait couvrir beaucoup plus de recommandations sur l'écriture d'une API sur node.js, mais je veux tenir dans 3-5 minutes. lire l'article. Sous réserve d'une bonne rétroaction, un suivi sera publié.

More articles:


All Articles