Node.js中Express.js与HapiJs能否混用？旧HapiJs项目可否用Express做路由？

嘿，这两个问题在项目迭代和技术栈兼容场景里挺常见的，我来给你分享些实际可行的方案：

1. 在Node.js环境中同时使用Express.js与HapiJs的可行方案 #

当然有可行方案，主要分为两种思路，根据你的项目复杂度选择：

• 方案一：独立服务+路由转发
  让两个框架各自启动独立的服务，监听不同端口，然后通过反向代理来分发请求。这种方式耦合度最低，两个框架可以各自升级、维护，互不影响。
  比如你可以让Hapi监听3000端口处理原有业务，Express监听3001端口负责新功能，然后用Node的http-proxy模块写一个简单的代理服务：

  const http = require('http');
  const httpProxy = require('http-proxy');
  const proxy = httpProxy.createProxyServer({});
  
  const mainServer = http.createServer((req, res) => {
    // 根据请求路径判断转发目标
    if (req.url.startsWith('/new-features')) {
      proxy.web(req, res, { target: 'http://localhost:3001' }); // 转发到Express
    } else {
      proxy.web(req, res, { target: 'http://localhost:3000' }); // 转发到Hapi
    }
  });
  
  mainServer.listen(8080);
  

  用户访问8080端口时，不同路径会自动路由到对应的框架服务。你也可以用Nginx来做这个转发，性能会更优。

• 方案二：将一个框架挂载到另一个的路由下
  如果不想分开端口，可以把其中一个框架的服务挂载到另一个的特定路由前缀下。比如在Hapi中使用@hapi/h2o2插件来代理到Express的路由：

  // 先启动Express服务
  const express = require('express');
  const expressApp = express();
  expressApp.get('/new-api/users', (req, res) => {
    res.json({ data: ['Alice', 'Bob'] });
  });
  expressApp.listen(3001);
  
  // Hapi主服务
  const Hapi = require('@hapi/hapi');
  const init = async () => {
    const server = Hapi.server({ port: 3000, host: 'localhost' });
    await server.register(require('@hapi/h2o2')); // 注册代理插件
  
    // 把/new-api开头的请求转发到Express
    server.route({
      method: '*',
      path: '/new-api/{path*}',
      handler: {
        proxy: {
          uri: 'http://localhost:3001/new-api/{path}',
          passThrough: true // 保留原请求头
        }
      }
    });
  
    // 原有的Hapi路由
    server.route({
      method: 'GET',
      path: '/old-api/items',
      handler: (req, h) => {
        return { data: ['Item1', 'Item2'] };
      }
    });
  
    await server.start();
    console.log('Hapi server running at:', server.info.uri);
  };
  init();
  

  这样访问http://localhost:3000/new-api/users就会自动转发到Express的对应接口。

2. 基于Hapi的旧项目，后续用Express负责路由功能的方案 #

完全可以，而且推荐用逐步迁移的方式，避免一次性重构带来的风险：

• 最优方案：独立Express服务+路由转发

  1. 新建一个Express项目，专门开发新的路由和业务功能；
  2. 保留原有的Hapi服务，继续处理旧的业务逻辑；
  3. 通过反向代理（Nginx或Node代理）将新路径的请求转发到Express，旧路径的请求仍由Hapi处理；
  4. 后续可以慢慢把旧路由也迁移到Express，直到完全替换Hapi。
     这种方式的好处是两个服务独立，你可以在Express中自由使用它的路由机制，不用考虑和Hapi的兼容性问题。

• 备选方案：用插件适配Express路由到Hapi
  有些第三方插件（比如hapi-express-bridge）可以让你在Hapi中直接使用Express的中间件或路由，但这种方式可能存在兼容性隐患——毕竟Hapi和Express的中间件机制、生命周期差异很大，尤其是Hapi的新版本，可能会出现奇怪的bug。所以除非项目限制必须单服务运行，否则更推荐上面的独立服务方案。

总的来说，这两种场景都有成熟的解决方案，核心是尽量降低框架之间的耦合，让它们各自发挥优势，同时平稳推进你的项目迭代。

内容的提问来源于stack exchange，提问作者Abdelrahman Hussien