最好的 Deno Web 框架是什么？

请注意，由于 Deno 在早期阶段发展迅速，其中一些指标可能会过时！我建议您将此作为初步指南，并确保亲自探索各个代码库——其中一些代码库自那时起可能已经越来越受欢迎！我将尽力使每个部分中的一些统计数据保持相对最新的状态，并按日期进行标注。😄

任何语言的常见用例之一就是其 HTTP 服务器功能。通常，我们倾向于看到任何特定语言的社区都集中在一个或几个 Web 框架上，这些框架在功能和性能之间实现了最佳平衡，并显示出开发成熟度和支持度的迹象。

由于 Deno 太新，很难知道哪个新兴的 Web 服务器框架才是最佳选择！仅在Deno Land 第三方模块页面上，就有 18 个搜索结果web framework，而 33 个搜索结果server。

在本文中，我尝试从几个关键因素的角度回顾大多数框架，以帮助您做出明智的决定，选择最适合您的框架！

我鼓励大家读到最后，我会谈到一些我没有完全审查的框架以及评论中提出的任何建议！

社区

一个健康的框架社区确实有助于简化框架的使用。由于目前还处于早期阶段，判断哪些框架拥有最佳社区并不容易，但我们可以从 GitHub 的使用情况中推断出一些规律。

以下是一些 GitHub 统计数据：

表格数据截至 2020 年 7 月 22 日

• 星标 - 星标通常能让人们大致了解社区中其他人正在使用什么，因此可以合理地指示哪些语言比较好。不过要注意，在一门新语言的早期，最初存在的语言往往会获得最多的星标，但这并不一定就是现在最好的！
• 分支 - 大量的分支往往表明人们正在积极使用和/或为框架做出贡献。
• 关注 - 大量人员关注存储库意味着有一个社区积极有兴趣接收有关其开发的通知。
• 未解决问题 - 大量的未解决问题可能表明项目维护不善。如果未解决问题和已解决问题的总数非常少，则可能意味着人们并没有真正使用该框架，因为他们很少提出问题、建议功能或发现错误——也许项目很完美，但事实可能并非如此！
• 已关闭的问题 - 大量已关闭的问题意味着该项目可能得到了良好的维护（尤其是在 Deno 的早期阶段，在较旧的语言中，如果问题数量较多，则项目可能会停滞一段时间！）并且社区积极参与提出疑问、建议等。

文档

当你想要使用一个新模块时，轻松上手的关键在于文档。通常最有用的是快速入门指南和一些可以查看示例代码的参考资料。当你开始在更严肃、更复杂的应用中使用该框架时，一套更完整、更易于搜索和浏览的 API 文档（例如，文档化的参数和返回类型解析等）和用例指南（可能就是代码示例本身！）会起到辅助作用。

表格数据截至 2020 年 6 月 15 日

大多数评测过的框架都有合理的文档。只有少数框架未能完整地提供 API 文档。不过，借助https://doc.deno.land/之类的文档以及 TypeScript 的使用，即使作者没有提供详尽的文档，我们仍然可以很好地理解 Deno 模块。

向Drash致以最崇高的敬意，它拥有一些最令人惊叹的文档- 它包含从入门到完整的 API 文档、内部图表以及其专用网站上的综合教程的所有内容。

 表现

对于生产服务器而言，负载下的性能对于向客户提供良好的服务至关重要，因此在选择 Web 服务器框架时应始终将其作为考虑因素。当然，性能和丰富的功能之间需要权衡——通常，提供最丰富开箱即用功能的框架会比那些对核心/标准库进行精简包装的框架略重，因此速度会更慢。务必谨慎选择能够为您当前和未来的潜在用例提供最佳性能的服务器。

为了衡量性能，我正准备编写一套基准测试程序，这时我偶然发现了Fastro，它支持完整的基准测试功能！所以，基准测试代码的贡献者必须归功于@ynwd（目前是唯一贡献者）。

注意：此基准并不完全符合实际，您应始终注意针对特定用例进行基准测试和衡量性能。

对于每个框架，我都编写了最少的代码来启动一个服务器，该服务器将响应GET指向根/路径的请求，请求主体为"Hello Deno!"。使用 NPM 包测量性能，autocannon命令如下：

npx autocannon -c100 -j localhost:3000

这是使用以下方法进行的：

• 机器：MacBook Pro, 2.3 GHz Intel Core i5, 8 GB 2133 MHz LPDDR3
• 节点：12.18.0
• 德诺：1.1.0

以下是结果，按每秒平均请求数排序（PHP 和 Python Flask 结果来自Fastro）：

表格数据截至 2020 年 6 月 15 日

有趣的是，尽管Deno 基准测试发现 Node 的 HTTP 服务器性能通常更快，但Deno的标准 HTTP 实际上比 LTS Node 12.18.0 更快（在我的设置中，在这个基准测试中——结果可能会有所不同！）。这可能是因为，即使我们添加了哪怕是最轻微的复杂性，我们也观察到了 Deno 远超其尾部延迟的影响，这意味着在多个请求的过程中，它始终保持快速，而 Node 的性能则更加不稳定。

出色的 Deno 模块是Denotrain和Fastro，它们都支持路由器和中间件，并且速度相当接近原始 Deno HTTP 库的速度。如果您需要快速路由器但不需要中间件结构，那么http_wrapper也是不错的选择。

熟悉度

虽然你应该拥抱变化并乐于采用特定语言的最佳实践，但有时最简单的起步方法是找到与你当前使用的库最匹配的库。这样，你就可以迁移现有项目，以最小的开销利用 Deno 增强的安全性、插件支持等功能，并且你和你的团队都能轻松地开发和扩展程序，因为 API 很熟悉。

在本节中，我尝试找出这些库背后的灵感，并根据它们与现有 Node 库的相似性对它们进行排序：

 表达

1. Opine - Opine 不仅受到 Express 的启发，而且直接从 Express 移植而来，这意味着其 API 和内部结构都与 Express 非常相似（即使不完全相同）。[免责声明：我是作者！]
2. Attain - Attain 支持类似 Express 的中间件和路由器 API，但略有不同。每个处理程序都会传递一个Oak Request对象和一个Response提供多种 Express 响应 API 的对象。
3. Servest - 另一个受 Express 启发的 HTTP 服务器框架，Servest 拥有许多与 Express 类似的 API，尽管其中一些 API 的命名略有不同。与 Express 不同的是，Servest 内置的请求对象包含用于解析请求的方法，并且在其处理程序 API 中支持请求过滤。它还内置了一个记录器，必须进行配置才能防止记录每个请求INFO。
4. Snowlight - Snowlight 的灵感来自 Express，其大部分 API 直接取自 Express。两者之间有一些细微的差别，例如增加了一个app.group()方法，允许你将共享中间件挂载到特定路径的路由器上，并且缺少一些不太常见的响应 API 等等。
5. http_wrapper - Deno HTTP 标准库的最小包装器，带有受 Express 启发的路由器。
6. Aqua - 路由器和中间件松散地反映了 Express API。

 相思树

1. Oak - Oak 受到 Koa 的启发，并支持与 Koa 相似的相当丰富的上下文驱动中间件 API。
2. Denotrain - 虽然它声称该库的灵感来自 Express，但我还是选择将其列在 Koa 部分，因为它使用了类似上下文的对象，而不是 Connect 风格的(req, res, next)中间件 API。然而，它与 Koa 的不同之处在于，响应是从路由处理程序返回的，并且没有next()for 中间件。
3. Ako - Ako 旨在将 Koa 移植到 Deno，因此最终可能会成为希望将其应用程序移植到 Deno 的用户的最佳选择。然而，目前它的文档非常有限，因此很难确定它在多大程度上反映了 Koa 的 API——我建议您在开发类似 Koa 的 Deno 应用程序时一定要考虑它，因为它可能计划直接使用 Koa 文档作为其文档！

 Fastify

1. Fastro - 受到 Express、Nest 和 Firebase 的启发，但主要采用来自 Fastify 的 API。

哈皮

1. Pogo - Pogo 受到 Hapi 的启发，具有匹配的路由对象 API 和丰富的支持 API。

Laravel

1. Drash - Drash 提供与 Laravel 类似的中间件，但也从 Flask 和 Tonic 中汲取灵感，并引入了自己的概念。

未分类

以下框架似乎不太适合上述其他类别：

• Abc - 尽管 Abc API 支持类似对象的上下文，但它与 Koa 上下文有些不同，并且与其他现有的 Node Web 框架不同。
• Fen - Fen 还支持其路由和中间件的类似对象 API 的上下文，但使用的路由器和控制器设置与列出的 Node 模块略有不同。

那些逃脱的人

你可能已经注意到，我并没有对所有可用的框架进行 100% 的审查。本文重点关注的框架是基于以下考虑而选择的，目的是保持范围合理，并限制测试、审查和撰写所有内容的开销(!)：

• README 文件是否明确指出该项目仍在进行中？如果是，则无需审核。
• 这个框架和抽象是否基于另一个框架？如果是，那就不要评审。
• 我能否轻松理解文档并开始使用？如果不能，就不要评论。（这只是我的意见！）

我鼓励您根据这些（相对任意的！）因素以及这次我未涉及的一些其他因素来查看以下内容：

• Alosaur - 一款非常酷炫的基于装饰器的 Web 框架，维护良好，而且很受欢迎。我计划以后尝试一下并进行评论。
• Levo - 一个开箱即用、支持服务器端渲染 (SSR) 和 Elm 架构 (TEA) 的前端框架。该框架专为网页和单页应用 (SPA) 设计，不适用于 API。它提供许多开箱即用的强大功能，例如 Brotli 压缩、基于目录的路由和虚拟 DOM 差异化——绝对值得关注！
• Dactyl - Dactyl 构建于 Oak 框架之上，旨在通过向用户提供声明式控制器来实现与 Nest 为 Express 相同的目标。与 Alosaur 类似，它充分利用了 Deno 对 TypeScript 的支持所提供的装饰器。
• MandarineTS - MandarineTS 是一个使用模型视图控制器 (MV) 模式创建网站的 TypeScript 框架。它具有内置依赖注入、会话、ORM 和模板引擎等功能，并且充分利用了装饰器。
• Dinja - Dinja 与 Dactyl 类似，是另一个更高级别的框架，它在 Pogo 框架之上提供 API，并引入模板引擎和各种 SQL 模块。
• Mith - 受 Express 启发的中间件框架。Mith 与 Express 的不同之处在于，它专注于提供强大的中间件系统，因此不支持路由。此外，它还尽量避免对 DenoServerRequest和对象进行改动。Response
• Jurassic - 路径“零配置”，基于路径的路由框架。
• Arkoren - Arkoren 声称其“旨在成为下一代可用的 Web 框架之一”，并具备“类型安全”等特性，以及受 Laravel 启发的 API。然而，它目前处于早期开发阶段，尚未准备好投入使用。
• SF - 我对这个 Web 框架真是百思不得其解。一方面，它总是强调自己“有多蠢”，却从未真正解释过它的用途！它之所以让我感兴趣，是因为从有限的文档来看，它似乎支持一系列功能和 API，用于处理 Redis、CRON、发起 HTTP 请求以及处理和响应 HTTP(S) 请求。
• Deno Express - Deno 原始演示服务器之一的克隆版。尽管名称相似，但其内部结构与 Express 并无相似之处，不过它确实提供了一个优雅的、极简的类似 Express 的 API。目前尚不清楚它是否正在积极开发中。
• MiniServer - MiniServer 是围绕标准 Deno 库的一个非常小的服务器包装器。
• Centroid - 一个正在进行的项目，用于将MOST Web 框架实现到 Deno。
• Denosaur - 一个简单的 Web 框架，目前正在开发中。
• Espresso - 一个正在开发中的极简 Web 框架，似乎从 Koa 中汲取了灵感，但拥有雄心勃勃的路线图，包括数据库集成、graphql 和 MVC 支持。
• Denovel - “一个为 Web 工匠打造的 Deno 框架”，Denovel 是另一个从 Laravel 中汲取灵感的 Web 框架。与大多数框架不同，作者鼓励您克隆代码库作为起点，它似乎不是一个可以导入的模块——不过，核心包可以从 vendor 目录中获取。
• DeliGenius - 一个轻量级的中间件框架，具有受 Koa 启发的 API 和令人印象深刻的性能- 值得关注。

我希望这篇评论对您有帮助！

如果您一直在使用上述某个 Deno Web 框架，或者使用一些我尚未涉及的框架（！），我很乐意听听您的想法 - 请在下面的部分中留下您的评论和意见。

如果您是某个项目的维护者，而我错过了您的项目，或者您觉得我对它进行了错误的描述，那么请发表评论，我们可以考虑添加/更新文章！

下次再见，感谢阅读！🦕

PS：想测试 HTTP 服务器吗？不妨试试SuperDeno 🎉