Explication détaillée de l'architecture du projet Nodejs Express.js

Recommandation du didacticiel vidéo : Tutoriel nodejs

Introduction

Dans le domaine node.js, Express.js est un framework de développement d'API REST bien connu. Bien que ce soit très bien, personne ne vous dit comment organiser le code du projet.

Habituellement, cela va, mais pour les développeurs, c'est un autre problème auquel nous devons faire face.

Une bonne structure de projet peut non seulement éliminer le code en double, améliorer la stabilité du système, améliorer la conception du système, mais également faciliter son expansion à l'avenir.

Depuis des années, je suis confronté à la refactorisation et à la migration de projets node.js mal structurés et mal conçus. Cet article est un résumé de mon expérience accumulée précédente.

Structure des répertoires

Ce qui suit est la manière que je recommande d'organiser le code du projet.

Cela vient de la pratique des projets auxquels j'ai participé. Les fonctions et fonctions de chaque module d'annuaire sont les suivantes :

  src
  │   app.js          # App 统一入口
  └───api             # Express route controllers for all the endpoints of the app
  └───config          # 环境变量和配置信息
  └───jobs            # 队列任务（agenda.js）
  └───loaders         # 将启动过程模块化
  └───models          # 数据库模型
  └───services        # 存放所有商业逻辑
  └───subscribers     # 异步事件处理器
  └───types           # Typescript 的类型声明文件 (d.ts)

Et, ce n'est pas seulement la façon dont le code est organisé. ..

Structure à 3 couches

Cette idée vient du Principe de séparation des préoccupations, qui sépare la logique métier du routage API node.js.

Parce qu'un jour dans le futur, vous pourrez gérer votre entreprise dans un outil CLI ou ailleurs. Bien sûr que ce n'est peut-être pas le cas, mais utiliser des appels API pour gérer votre propre entreprise dans un projet n'est pas une bonne idée après tout...

Ne gérez pas la logique métier directement dans le contrôleur !!

Dans votre application, vous devrez peut-être gérer les affaires directement dans le contrôleur pour plus de commodité. Malheureusement, si vous faites cela, vous serez bientôt confronté à un code de contrôleur complexe, et des « conséquences négatives » s'ensuivront, comme devoir utiliser une requête ou une réponse. simulation.

En même temps, cela deviendra compliqué de décider quand renvoyer une réponse au client, ou si vous souhaitez effectuer un traitement après l'envoi de la réponse.

Veuillez ne pas faire cela comme dans l'exemple suivant.

  route.post('/', async (req, res, next) => {

    // 这里推荐使用中间件或Joi 验证器
    const userDTO = req.body;
    const isUserValid = validators.user(userDTO)
    if(!isUserValid) {
      return res.status(400).end();
    }

    // 一堆义务逻辑代码
    const userRecord = await UserModel.create(userDTO);
    delete userRecord.password;
    delete userRecord.salt;
    const companyRecord = await CompanyModel.create(userRecord);
    const companyDashboard = await CompanyDashboard.create(userRecord, companyRecord);

    ...whatever...

    // 这里是“优化”，但却搞乱了所有的事情
    // 向客户端发送响应...
    res.json({ user: userRecord, company: companyRecord });

    // 但这里的代码仍会执行 :(
    const salaryRecord = await SalaryModel.create(userRecord, companyRecord);
    eventTracker.track('user_signup',userRecord,companyRecord,salaryRecord);
    intercom.createUser(userRecord);
    gaAnalytics.event('user_signup',userRecord);
    await EmailService.startSignupSequence(userRecord)
  });

Utilisez une couche de service pour gérer les affaires

Il est recommandé de gérer la logique métier dans une couche de service distincte.

Cette couche est un ensemble de "classes" qui suivent les principes

SOLID applicables à node.js

Dans cette couche, il ne devrait y avoir aucune forme d'opérations de requête de données. L'approche correcte consiste à utiliser une couche d'accès aux données.

• Nettoyer le code commercial des routes express.js.

• La couche de service ne doit pas contenir de requête et de réponse.

• La couche de service ne doit renvoyer aucune donnée associée à la couche de transport, telle que les codes d'état et les en-têtes de réponse.

Exemple

  route.post('/', 
    validators.userSignup, // 中间件处理验证
    async (req, res, next) => {
      // 路由的实际责任
      const userDTO = req.body;

      // 调用服务层
      // 这里演示如何访问服务层
      const { user, company } = await UserService.Signup(userDTO);

      // 返回响应
      return res.json({ user, company });
    });

Ce qui suit est l'exemple de code de la couche de service.

  import UserModel from '../models/user';
  import CompanyModel from '../models/company';

  export default class UserService {

    async Signup(user) {
      const userRecord = await UserModel.create(user);
      const companyRecord = await CompanyModel.create(userRecord); // 依赖用户的数据记录 
      const salaryRecord = await SalaryModel.create(userRecord, companyRecord); // 依赖用户与公司数据

      ...whatever

      await EmailService.startSignupSequence(userRecord)

      ...do more stuff

      return { user: userRecord, company: companyRecord };
    }
  }

Afficher un exemple de code sur Github

https://github.com/santiq/bulletproof-nodejs

Utiliser le modèle de publication/abonnement

À proprement parler, le modèle de publication/abonnement n'appartient pas à la structure à 3 niveaux, mais il est très pratique.

Voici une simple API node.js pour créer des utilisateurs. En même temps, vous devrez peut-être également appeler des services externes, analyser des données ou envoyer une série d'e-mails. Très vite, cette fonction simple, utilisée à l'origine pour créer des utilisateurs, s'est remplie de diverses fonctions et le code dépassait les 1 000 lignes.

Il est maintenant temps de diviser ces fonctionnalités en fonctions indépendantes afin que votre code puisse continuer à rester maintenable.

  import UserModel from '../models/user';
  import CompanyModel from '../models/company';
  import SalaryModel from '../models/salary';

  export default class UserService() {

    async Signup(user) {
      const userRecord = await UserModel.create(user);
      const companyRecord = await CompanyModel.create(user);
      const salaryRecord = await SalaryModel.create(user, salary);

      eventTracker.track(
        'user_signup',
        userRecord,
        companyRecord,
        salaryRecord
      );

      intercom.createUser(
        userRecord
      );

      gaAnalytics.event(
        'user_signup',
        userRecord
      );

      await EmailService.startSignupSequence(userRecord)

      ...more stuff

      return { user: userRecord, company: companyRecord };
    }

  }

L'appel synchrone des services dépendants n'est toujours pas la meilleure solution.

Une meilleure approche consiste à déclencher des événements, tels que : un nouvel utilisateur s'inscrit par e-mail.

De cette façon, l'API qui crée l'utilisateur a rempli sa fonction, et le reste est laissé au processeur qui s'abonne à l'événement.

  import UserModel from '../models/user';
  import CompanyModel from '../models/company';
  import SalaryModel from '../models/salary';

  export default class UserService() {

    async Signup(user) {
      const userRecord = await this.userModel.create(user);
      const companyRecord = await this.companyModel.create(user);
      this.eventEmitter.emit('user_signup', { user: userRecord, company: companyRecord })
      return userRecord
    }

  }

Et vous pouvez diviser le gestionnaire d'événements en plusieurs fichiers indépendants.

  eventEmitter.on('user_signup', ({ user, company }) => {

    eventTracker.track(
      'user_signup',
      user,
      company,
    );

    intercom.createUser(
      user
    );

    gaAnalytics.event(
      'user_signup',
      user
    );
  })

  eventEmitter.on('user_signup', async ({ user, company }) => {
    const salaryRecord = await SalaryModel.create(user, company);
  })

  eventEmitter.on('user_signup', async ({ user, company }) => {
    await EmailService.startSignupSequence(user)
  })

Vous pouvez utiliser try-catch pour envelopper l'instruction wait, ou

enregistrer le gestionnaire d'événements 'unhandledPromise' sous la forme de process.on('unhandledRejection',cb)

Injection de dépendances

L'injection de dépendances ou inversion de contrôle (IoC) est un modèle courant dans lequel les dépendances impliquées dans une classe ou une fonction sont « injectées » ou transmises via le constructeur. Aidez-vous organisez votre code.

De cette façon, injecter des

dépendances devient très flexible, par exemple, lorsque vous écrivez des tests unitaires pour un service, ou lorsque vous utilisez le service dans un autre contexte.

Code sans injection de dépendances

  import UserModel from '../models/user';
  import CompanyModel from '../models/company';
  import SalaryModel from '../models/salary';  
  class UserService {
    constructor(){}
    Sigup(){
       //调用 UserMode, CompanyModel，等
      ...
    }
  }

Code avec injection de dépendances manuelle

  export default class UserService {
    constructor(userModel, companyModel, salaryModel){
      this.userModel = userModel;
      this.companyModel = companyModel;
      this.salaryModel = salaryModel;
    }
    getMyUser(userId){
      // 通过this获取模型
      const user = this.userModel.findById(userId);
      return user;
    }
  }

Vous pouvez désormais injecter une dépendance personnalisée.

  import UserService from '../services/user';
  import UserModel from '../models/user';
  import CompanyModel from '../models/company';
  const salaryModelMock = {
    calculateNetSalary(){
      return 42;
    }
  }
  const userServiceInstance = new UserService(userModel, companyModel, salaryModelMock);
  const user = await userServiceInstance.getMyUser('12346');

一个服务可以拥有的依赖项数量是无限的，当您添加一个新的服务时重构它的每个实例是一个无聊且容易出错的任务。

这就是创建依赖注入框架的原因。

其思想是在类中声明依赖项，当需要该类的实例时，只需调用「服务定位器」。

我们可以参考一个在 nodejs 引入 D.I npm库typedi的例子。

你可以在官方文档上查看更多关于使用 typedi的方法

https://www.github.com/typestack/typedi

警告 typescript 例子

  import { Service } from 'typedi';
  @Service()
  export default class UserService {
    constructor(
      private userModel,
      private companyModel, 
      private salaryModel
    ){}

    getMyUser(userId){
      const user = this.userModel.findById(userId);
      return user;
    }
  }

services/user.ts

现在，typedi 将负责解析 UserService 所需的任何依赖项。

  import { Container } from 'typedi';
  import UserService from '../services/user';
  const userServiceInstance = Container.get(UserService);
  const user = await userServiceInstance.getMyUser('12346');

滥用服务定位器是一种反面模式

在 Express.js 中使用依赖注入

在express.js中使用 D.I. 是 node.js 项目架构的最后一个难题。

路由层

  route.post('/', 
    async (req, res, next) => {
      const userDTO = req.body;

      const userServiceInstance = Container.get(UserService) // Service locator

      const { user, company } = userServiceInstance.Signup(userDTO);

      return res.json({ user, company });
    });

太棒了，项目看起来很棒！
它是如此有组织，以至于我现在就想写代码了。

在github上查看源码

https://github.com/santiq/bulletproof-nodejs

一个单元测试的例子

通过使用依赖注入和这些组织模式，单元测试变得非常简单。

您不必模拟 req/res 对象或要求（…）调用。

例子：注册用户方法的单元测试

tests/unit/services/user.js

  import UserService from '../../../src/services/user';

  describe('User service unit tests', () => {
    describe('Signup', () => {
      test('Should create user record and emit user_signup event', async () => {
        const eventEmitterService = {
          emit: jest.fn(),
        };

        const userModel = {
          create: (user) => {
            return {
              ...user,
              _id: 'mock-user-id'
            }
          },
        };

        const companyModel = {
          create: (user) => {
            return {
              owner: user._id,
              companyTaxId: '12345',
            }
          },
        };

        const userInput= {
          fullname: 'User Unit Test',
          email: 'test@example.com',
        };

        const userService = new UserService(userModel, companyModel, eventEmitterService);
        const userRecord = await userService.SignUp(teamId.toHexString(), userInput);

        expect(userRecord).toBeDefined();
        expect(userRecord._id).toBeDefined();
        expect(eventEmitterService.emit).toBeCalled();
      });
    })
  })

定时任务

因此，既然业务逻辑封装到了服务层中，那么在定时任务中使用它就更容易了。

您永远不应该依赖 node.js的 setTimeout 或其他延迟执行代码的原生方法，而应该依赖一个框架把你的定时任务和执行持久化到数据库。

这样你就可以控制失败的任务和成功的反馈信息。

我已经写了一个关于这个的好的练习，

 查看我关于使用 node.js 最好的任务管理器 agenda.js 的指南.

https://softwareontheroad.com/nodejs-scalability-issues

配置项和私密信息

根据 应用程序的12个因素 的最佳概念，我们存储 API 密钥和数据库连接配置的最佳方式是使用 .env文件。

创建一个 .env 文件，一定不要提交 （在你的仓库里要有一个包含默认值的.env 文件），dotenv 这个npm 包会加载 .env 文件，并把变量添加到 node.js 的 process.env 对象中。

这些本来已经足够了，但是我喜欢添加一个额外的步骤。
拥有一个 config/index.ts 文件，在这个文件中，dotenv 这个npm 包会加载 .env 文件，然后我使用一个对象存储这些变量，至此我们有了一个结构和代码自动加载。

config/index.js

  const dotenv = require('dotenv');
  //config(）方法会读取你的 .env 文件，解析内容，添加到 process.env。
  dotenv.config();

  export default {
    port: process.env.PORT,
    databaseURL: process.env.DATABASE_URI,
    paypal: {
      publicKey: process.env.PAYPAL_PUBLIC_KEY,
      secretKey: process.env.PAYPAL_SECRET_KEY,
    },
    paypal: {
      publicKey: process.env.PAYPAL_PUBLIC_KEY,
      secretKey: process.env.PAYPAL_SECRET_KEY,
    },
    mailchimp: {
      apiKey: process.env.MAILCHIMP_API_KEY,
      sender: process.env.MAILCHIMP_SENDER,
    }
  }

这样可以避免代码中充斥着 process.env.MY_RANDOM_VAR 指令，并且通过自动完成，您不必知道 .env 文件中是如何命名的。

在github 上查看源码

https://github.com/santiq/bulletproof-nodejs

加载器

加载器源于 W3Tech microframework 但不依赖于他们扩展。

这个想法是指，你可以拆分启动加载过程到可测试的独立模块中。

先来看一个传统的 express.js 应用的初始化示例：

  const mongoose = require('mongoose');
  const express = require('express');
  const bodyParser = require('body-parser');
  const session = require('express-session');
  const cors = require('cors');
  const errorhandler = require('errorhandler');
  const app = express();

  app.get('/status', (req, res) => { res.status(200).end(); });
  app.head('/status', (req, res) => { res.status(200).end(); });
  app.use(cors());
  app.use(require('morgan')('dev'));
  app.use(bodyParser.urlencoded({ extended: false }));
  app.use(bodyParser.json(setupForStripeWebhooks));
  app.use(require('method-override')());
  app.use(express.static(__dirname + '/public'));
  app.use(session({ secret: process.env.SECRET, cookie: { maxAge: 60000 }, resave: false, saveUninitialized: false }));
  mongoose.connect(process.env.DATABASE_URL, { useNewUrlParser: true });

  require('./config/passport');
  require('./models/user');
  require('./models/company');
  app.use(require('./routes'));
  app.use((req, res, next) => {
    var err = new Error('Not Found');
    err.status = 404;
    next(err);
  });
  app.use((err, req, res) => {
    res.status(err.status || 500);
    res.json({'errors': {
      message: err.message,
      error: {}
    }});
  });

  ... more stuff 

  ... maybe start up Redis

  ... maybe add more middlewares

  async function startServer() {    
    app.listen(process.env.PORT, err => {
      if (err) {
        console.log(err);
        return;
      }
      console.log(`Your server is ready !`);
    });
  }

  // 启动服务器
  startServer();

天呐，上面的面条代码，不应该出现在你的项目中对吧。

再来看看，下面是一种有效处理初始化过程的示例：

  const loaders = require('./loaders');
  const express = require('express');

  async function startServer() {

    const app = express();

    await loaders.init({ expressApp: app });

    app.listen(process.env.PORT, err => {
      if (err) {
        console.log(err);
        return;
      }
      console.log(`Your server is ready !`);
    });
  }

  startServer();

现在，各加载过程都是功能专一的小文件了。

loaders/index.js

  import expressLoader from './express';
  import mongooseLoader from './mongoose';

  export default async ({ expressApp }) => {
    const mongoConnection = await mongooseLoader();
    console.log('MongoDB Intialized');
    await expressLoader({ app: expressApp });
    console.log('Express Intialized');

    // ... 更多加载器

    // ... 初始化 agenda
    // ... or Redis, or whatever you want
  }

express 加载器。

loaders/express.js

  import * as express from 'express';
  import * as bodyParser from 'body-parser';
  import * as cors from 'cors';

  export default async ({ app }: { app: express.Application }) => {

    app.get('/status', (req, res) => { res.status(200).end(); });
    app.head('/status', (req, res) => { res.status(200).end(); });
    app.enable('trust proxy');

    app.use(cors());
    app.use(require('morgan')('dev'));
    app.use(bodyParser.urlencoded({ extended: false }));

    // ...More middlewares

    // Return the express app
    return app;
  })

mongo 加载器

loaders/mongoose.js

  import * as mongoose from 'mongoose'
  export default async (): Promise<any> => {
    const connection = await mongoose.connect(process.env.DATABASE_URL, { useNewUrlParser: true });
    return connection.connection.db;
  }

在 Github 查看更多加载器的代码示例

https://github.com/santiq/bulletproof-nodejs

结语

我们深入的分析了 node.js 项目的结构，下面是一些可以分享给你的总结:

• 使用3层结构。

• 控制器中不要有任何业务逻辑代码。

• 采用发布/订阅模型来处理后台异步任务。

• 使用依赖注入。

• 使用配置管理，避免泄漏密码、密钥等机密信息。

• 将 node.js 服务器的配置拆分为可独立加载的小文件。

前往 Github 查看完整示例

https://github.com/santiq/bulletproof-nodejs

Adresse originale : https://dev.to/santypk4/bulletproof-node-js-project-architecture-4epf

Adresse de traduction : https://learnku.com/ nodejs/t/38129

Pour plus de connaissances liées à la programmation, veuillez visiter : Introduction à la programmation ! !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!