node.js - Express 和 hapi 如何相互比较？

Question

从 Web 应用程序设计和开发的角度来看，Express 和 Hapi 相比如何？对于基本示例，它们看起来很相似，但是我有兴趣了解更多有关整体应用程序结构的主要差异的信息。

例如，据我所知，Hapi 使用 different不考虑注册顺序的路由机制，可以进行更快的查找，但与 Express 相比有局限性。还有其他重要的区别吗？

还有一个article关于选择 Hapi(而不是 Express)来开发新的 npmjs.com 网站，这篇文章指出“Hapi 的插件系统意味着我们可以隔离应用程序的不同方面和服务，以便将来可以使用微服务。Express，在另一方面，需要更多配置才能获得相同的功能”，这到底是什么意思？

Answer 1

这是一个很大的问题，需要很长的答案才能完成，所以我将只解决最重要差异的一个子集。很抱歉，这仍然是一个冗长的答案。

他们有什么相似之处？

当你说:

For basic examples they seem similar

这两个框架都在解决相同的基本问题:为在 node.js 中构建 HTTP 服务器提供方便的 API。也就是说，比使用低级原生 http 更方便单独的模块。 http模块可以做我们想做的一切，但编写应用程序很乏味。

为了实现这一点，他们都使用了高级 Web 框架中长期存在的概念:路由、处理程序、插件、身份验证模块。它们可能并不总是具有相同的名称，但它们大致相同。

大多数基本示例如下所示:

创建路由

在请求路由时运行函数，准备响应

响应请求

express :

app.get('/', function (req, res) {

    getSomeValue(function (obj) {

        res.json({an: 'object'});
    });
});

哈皮:

server.route({
    method: 'GET',
    path: '/',
    handler: function (request, reply) {

        getSomeValue(function (obj) {

            reply(obj);
        });
    }
});

这里的差异并不完全是开创性的，对吗？那么为什么要选择一个呢？

它们有何不同？

简单的答案是 hapi 多得多，而且开箱即用。当您仅查看上面的简单示例时，这可能不清楚。事实上，这是故意的。简单的情况保持简单。因此，让我们检查一些重大差异:

哲学

Express 旨在非常小。通过为您提供一个小型 API，在 http 的顶部添加了一层薄薄的灰尘，在添加附加功能方面，您仍然非常依赖自己。如果要读取传入请求的正文(很常见的任务)，则需要安装 separate module .如果您希望将各种内容类型发送到该路由，您还需要检查 Content-type header 来检查它是哪个并相应地解析它(例如，表单数据 vs JSON vs 多部分)，通常使用单独的模块。

hapi 具有丰富的功能集，通常通过配置选项公开，而不需要编写代码。例如，如果我们想确保在运行处理程序之前将请求正文(有效负载)完全读入内存并进行适当的解析(根据内容类型自动)，这只是一个简单的 option :

server.route({
    config: {
        payload: {
            output: 'data',
            parse: true
        }
    },
    method: 'GET',
    path: '/',
    handler: function (request, reply) {

        reply(request.payload);
    }
});

特点

您只需要比较两个项目的 API 文档即可看到 hapi 提供了更大的功能集。

hapi 包含以下一些 Express 没有的内置功能(据我所知):

Input and response validation (通过 Joi)

Server-side caching具有多个存储选项(mongo、S3、redis、riak)，可以通过几行配置启用

Cookie-parsing

session

文件上传/分段解析

CORS 支持

Logging

可扩展性和模块化

hapi 和 Express 以完全不同的方式实现可扩展性。使用 Express，您拥有 middleware功能。中间件函数有点像你堆叠的过滤器，所有请求在到达你的处理程序之前都会通过它们。

hapi 有 request lifecycle并提供 extension points ，它们类似于中间件功能，但在请求生命周期中存在几个定义的点。

沃尔玛构建 hapi 并停止使用 Express 的原因之一是，将 Express 应用程序拆分为不同的部分并让不同的团队成员安全地工作是多么困难，这让他们感到沮丧。出于这个原因，他们创建了 plugin system在哈皮。

插件就像一个子应用程序，你可以在 hapi 应用程序中做你能做的一切，添加路由，扩展点等。在插件中，你可以确保你不会破坏应用程序的另一部分，因为顺序路线的注册无关紧要，您不能创建冲突的路线。然后，您可以将此插件组合到服务器中并进行部署。

生态系统

因为 Express 为您提供的开箱即用很少，所以当您需要向项目添加任何内容时，您需要向外看。很多时候使用 hapi 时，您需要的功能要么是内置的，要么是核心团队创建的模块。

最小听起来很棒。但是，如果您正在构建一个严肃的生产应用程序，那么您最终很有可能需要所有这些东西。

安全

hapi 是由沃尔玛团队设计的，用于运行黑色星期五的交通，因此安全性和稳定性一直是头等大事。出于这个原因，该框架做了很多额外的事情，例如限制传入的有效负载大小以防止耗尽您的进程内存。它还具有诸如最大事件循环延迟、最大 RSS 内存使用和 v8 堆的最大大小之类的选项，超过这些选项，您的服务器将响应 503 超时，而不仅仅是崩溃。

总结

自己评估一下。考虑您的需求，两者中的哪一个解决了您最大的问题。在两个社区(IRC、Gitter、Github)中体验一下，看看你更喜欢哪个。不要只相信我的话。和快乐的黑客!

免责声明:作为 book on hapi 的作者，我有偏见以上主要是我个人的意见。