javascript - 在常规生产用例中使用 server.inject - 坏主意还是好主意？

Question

这是我的默认用例:我正在考虑通过 socket.io 层而不是通过 http 提供一些 REST 资源(因为我最终需要提供大量小型 api 请求来呈现典型页面，而且它们都通过 https，这有额外的握手问题)。

我仍然不确定这总体上是一个好主意(并且也一直在研究http2.0)。在短期内，我不想迁移 hapijs 或重写大量模块化代码，但我确实想尝试在一些测试中使其工作服务器以查看其性能如何。

因此，我编写了一个 super 基本的 socket.io 事件处理程序，它仅从 websocket 事件发射器获取请求，并通过 server.inject 调用将它们重新打包到 hapi 中:

module.exports = {
  addSocket: function(sock) {
    sock.on('rest:get:request', function(sock) {
      return function(url) {
        console.log(url);
        hapi.inject({url: url, credentials: {user: sock.user}}, function(res) {
          sock.emit('rest:get:response', url, res.payload);
        });
      };
    })(sock);
  }
};

因此，它真正要做的就是确保设置身份验证对象(我之前已经在套接字上对用户进行了身份验证)，然后向服务器注入(inject) GET 请求。

通常，似乎 server.inject 用于测试，但这似乎是一个完美的计划，除非(当然)它超慢或由于我没有预见到的原因，这是一个坏主意。因此:我的问题。

Answer 1

Server.inject 是封装子请求的好方法，但它可能会变得比必要的更加复杂。一种更简单的方法是使用共享处理程序函数并将它们运行为 pre-handlers .

预处理程序的好处是，如果需要，您可以并行运行它们。

我使用server.inject(测试除外)的一个用例是健康检查路由。我有一条路线 /health-check/db 和 /health-check/queue。然后我有一个 /health-check 路由来封装所有这些。但同样，这可以通过共享路由处理程序来完成。

前几天我在 gitter channel 上对此进行了长时间的讨论，我的理解是这既不好也不坏。

我想一个非常好的用例是，如果您有多个团队构建公开路由的插件，并且您想在插件中使用其中一个路由。你不关心实现；您可以调用路线。

使用 server.inject 的另一个原因是它包含路由提供的验证步骤，因此您只需在一个位置定义资源。