Question

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

我仍然不确定这是一个好主意（并且一直在查看http2.0）。在短期内，我不想迁移hapijs 或重写大量的模块化代码，但我做想尝试在一些测试中完成这项工作服务器，看看它的表现如何。

所以我编写了一个超级基本的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);
  }
};

所以，它真正做的就是确保设置了身份验证对象（我之前已经在套接字上对用户进行了身份验证），然后向服务器注入了一个GET请求。

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

Answer 1

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

预处理程序的优点是，如果需要，您可以在parellel中运行它们。

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

前几天我对gitter频道进行了长时间的讨论，我的理解是它既不好也不坏。

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

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

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

1 个答案: