在常规生产用例中使用server.inject – 坏主意或好主意？
这里是我的默认用例：我正在考虑通过socket.io层而不是通过http来提供一些REST资源（因为我最终需要提供大量小的API请求来呈现典型的页面，重新遍历https，这有额外的握手问题）。
一般来说，我还不确定这是个好主意（而且也一直在看http2.0）。 在短期内，我不希望从hapijs移植或重写大量的模块化代码，但是我想尝试在一些testing服务器上进行这项工作，以了解它的执行情况。
所以我写了一个超级基本的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); } };
所以，它确实是确保身份validation对象已设置（我以前在套接字上对用户进行了身份validation），然后向服务器注入GET请求。
通常情况下 ，似乎server.inject用于testing，但这似乎是一个非常cóuulent计划，除非（当然），它是超慢或一个坏主意，我没有预见的原因。 因此：我的问题。
Server.inject是封装子请求的好方法，但它可能会变得比需要更复杂。 更轻的方法是使用共享处理函数，并将其作为预处理程序运行。
预处理程序的好处在于，如果需要，可以在parellel中运行它们。
我使用server.inject （除了在testing中）的一个用例是用于健康检查路线。 我有一个路由/health-check/db和/health-check/queue 。 然后我会有一个/health-check路线封装了所有这些。 但是，这又可以通过共享路由处理程序来完成。
有一天我对gitter频道进行了长时间的讨论，我的理解是这个既不好也不坏。
我想如果你有多个团队构build插件来公开路由，并且你想在你的插件中使用这些路由，那么一个非常好的用例就是这样。 你不关心执行; 你可以调用路由。
因为使用server.inject原因是它包含路由提供的validation步骤，所以你只需要在一个地方定义你的资源。