使用服务器.注入常规的生产用例——好主意也好，坏主意也罢

Using server.inject in regular production use cases - bad idea or good idea?

本文关键字：好主意 注入 服务器 常规      更新时间：2023-09-26

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

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

所以我写了一个超基本的套接字。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似乎用于测试，但这似乎是一个完美的扩展计划，除非(当然)它非常慢，或者由于我没有预见到的原因，它是一个坏主意。因此:我的问题。

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

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

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

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

我想一个很好的用例是，如果你有多个团队在构建暴露路由的插件，而你想在你的插件中使用其中一个路由。你不关心实现;您可以直接调用路由。

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