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

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

总的来说，我仍然不确定这是一个好主意（并且一直在研究http2.0）。在短期内，我不想迁移出hapijs或重写大量模块化代码，但我确实想在一些测试服务器上尝试一下，看看它的性能如何

因此，我编写了一个super basic socket.io事件处理程序，它只从websocket事件发射器接收请求，并通过

服务器将它们重新打包到hapi中。inject

调用：

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

，但这似乎是一个完美的cromultent计划，除非（当然），由于我没有预见到的原因，它非常慢或是一个坏主意。因此：我的问题。

Server.inject

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

pre处理程序的优点在于，如果需要，可以并行运行它们

我使用的

server.inject

（测试中除外）的一个用例是用于健康检查路由。我需要一条路线

/health check/db

和

/health check/queue

。然后我会有一个

/health check

路径，它封装了所有这些内容。但同样，这可以通过共享路由处理程序来完成

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

我想一个非常好的用例应该是，如果你有多个团队构建插件来公开路由，并且你想在你的插件中使用其中一个路由。你不关心实施；你可以直接打电话给路线

---

另一个使用

server.inject

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

fwiw，我对这些我没有发言权的“建议编辑”并不狂热-这严格来说是一个hapi.js性能/使用问题。我也没有标记这个？正如socket.io.So澄清的那样：这是一个关于hapi.js上生产中的

server.inject

性能的问题-通常是在测试期间使用的东西。在日常工作的测试之外使用它是一个坏主意吗？我的轶事不值得一个完整的答案，但我们在生产中使用server.inject没有问题。我们的应用程序有两个服务器，其中一个响应SOAP响应，但实际上只是通过

server.select（“REST”）.inject…