一般来说，只要 HTTP 协议存在，Web 服务就已经存在。但是，自从云计算出现以来，它们已成为实现客户端与服务和数据交互的无处不在的方法。

作为一名开发人员，我很幸运能够使用一些仍然围绕@work 的 SOAP 服务。但是，我主要使用 REST，这是一种用于开发 API 和 Web 服务的基于资源的架构风格。

在我职业生涯的大部分时间里，我都参与了构建、设计和使用 API 的项目。

我见过的大多数 API 都“声称”是“RESTful” —— 意思是符合 REST 架构的原则和约束。

然而，我与少数几个合作过的人给 REST 一个非常非常糟糕的代表。

HTTP 状态代码的不准确使用、纯文本响应、不一致的模式、插入端点的动词……我觉得我已经看到了这一切（或者至少，很多）。

因此，我决定写一篇文章来描述我个人认为设计 REST API 时的一些最佳实践。

只是为了让我们清楚……

我并不声称自己是权威，也不打算推断以下实践与任何“神圣的 REST 原则”100% 同步（如果存在这样的事情）。 我从我自己在整个职业生涯中构建和使用不同 API 的经验中拼凑出这些想法。

另外，我也不会假装精通 REST API 设计！ 我相信这是一门艺术/运动——你练习得越多，你得到的就越好。

我将列出一些代码片段作为“糟糕设计的例子”。 如果它们看起来像你会写的东西，那很好！ 🙂 唯一重要的是我们一起学习。

这里有一些技巧、建议和指导，可以帮助您设计出色的 REST API，让您的消费者（和开发人员）满意。

1. 学习HTTP的基础知识

如果您渴望构建一个设计良好的 REST API，您必须了解 HTTP 协议的基础知识。我坚信这将帮助您做出好的设计选择。

我发现 Mozilla 开发人员网络文档上的 HTTP 概述是有关此主题的非常全面的参考。

虽然，就 REST API 设计而言，这是一个适用于 RESTful 设计的 HTTP TLDR：

HTTP 有动词（动作或方法）：GET、POST、PUT、PATCH 和 DELETE 是最常见的。

REST 是面向资源的，资源由 URI 表示：/library/

端点是动词和 URI 的组合，例如：GET: /books/

端点可以解释为对资源执行的操作。示例： POST: /books/ 可能意味着“创建一本新书”。

概括地说，动词映射到 CRUD 操作：GET 表示读取，POST 表示创建，PUT 和 PATCH 表示更新，DELETE 表示删除

响应的状态由其状态代码指定：1xx 表示信息，2xx 表示成功，3xx 表示重定向，4xx 表示客户端错误和 5xx 表示服务器错误

当然，您可以使用 HTTP 协议为 REST API 设计提供的其他内容，但我相信您必须牢记这些基本内容。

2.不返回纯文本

尽管这不是任何 REST 架构风格强加或强制的，但大多数 REST API 按照惯例使用 JSON 作为数据格式。

但是，仅返回包含 JSON 格式字符串的响应正文还不够好。 您仍应指定 Content-Type 标头。 它必须设置为值 application/json。

这在处理应用程序/编程客户端时尤为重要（例如，另一个服务/API 通过 Python 中的请求库与您的 API 交互） — 其中一些依赖此标头来准确解码响应。

💡专业提示：您可以使用 Firefox 轻松验证响应的内容类型。 它具有内置的漂亮显示内容类型：application/json 的响应。 🔥

在 Firefox 中，“Content-Type: text/plain”看起来……很简单。

“Content-Type: application/json” 不错，这是多么漂亮和实用。🕺

3. 不要在 URI 中使用动词

到目前为止，如果您已经了解了基础知识，您就会开始意识到将动词放在 URI 中不是 RESTful。

这是因为 HTTP 动词应该足以准确描述对资源执行的操作。

示例：假设您正在提供一个端点来生成和检索一本书的封面。 我会注意到 :param 是 URI 参数的占位符（如 ID 或 slug）。 您的第一个想法可能是创建一个与此类似的端点：

GET: /books/:slug/generateBookCover/

但是，GET 方法在语法上足以说明我们正在检索（“GETting”）一本书的封面。 所以，让我们使用：

GET: /books/:slug/bookCover/

同样，对于创建新书的端点：

# Don’t do this
POST: /books/createNewBook/
# Do this
POST: /books/

4.资源使用复数名词

这可能很难确定，是否应该对资源名词使用复数形式或单数形式。

我们应该使用 /book/:id/ （单数）还是 /books/:id/ （复数）？

我个人的建议是使用复数形式。

为什么？ 因为它非常适合所有类型的端点。

我可以看到 GET /book/2/ 很好。 但是 GET /book/ 呢？ 我们是要拿到图书馆里唯一的一本书，还是两本书，还是全部？

为了防止这种歧义，让我们保持一致（💡软件职业建议！）并在任何地方使用复数：

GET: /books/2/
POST: /books/
...

5.在响应正文中返回错误详细信息

当 API 服务器处理错误时，在 JSON 正文中返回错误详细信息很方便（*并且推荐*）以帮助消费者进行调试。 如果您包含受错误影响的字段，那就更好了！

{
    "error": "Invalid payload.",
    "detail": {
        "name": "This field is required."
    }
}

6. 特别注意 HTTP 状态码

我觉得这个很重要。如果您需要从本文中记住一件事，那可能就是它。

您的 API 可能做的最糟糕的事情是返回带有 200 OK 状态代码的错误响应。

这只是糟糕的语义。相反，返回一个准确描述错误类型的有意义的 HTTP 状态代码。

不过，您可能想知道，“但我按照您的建议在响应正文中发送了错误详细信息，那有什么问题呢？”

让我给你讲一个故事。 🙂

我曾经不得不集成一个 API，它为每个响应返回 200 OK 并通过状态字段指示请求是否成功：

{
    "status": "success",
    "data": {}
}

尽管 HTTP 状态代码返回 200 OK，但我不能绝对确定它没有无法处理我的请求。

事实上，API 可以像这样返回响应：

HTTP/1.1 200 OK

Content-Type: text/html

{

    "status": "failure",

    "data": {

        "error": "Expected at least three items in the list."

    }

}



（是的——它也返回了 HTML 内容。因为，为什么不呢？）

因此，在读取数据之前，我必须检查状态代码和临时状态字段以确保一切正常。

太烦人了！ 🤦‍♂️

这种设计是真正的禁忌，因为它破坏了 API 与其消费者之间的信任。您开始担心 API 可能会骗您。

所有这些都非常非 RESTful。 你应该怎么做？

使用 HTTP 状态代码，仅使用响应正文提供错误详细信息。

HTTP/1.1 400 错误请求

HTTP/1.1 400 Bad Request
Content-Type: application/json
{
    "error": "Expected at least three items in the list."
}

7. 你应该一致地使用 HTTP 状态码

一旦您掌握了 HTTP 状态代码，您应该致力于始终如一地使用它们。

例如，如果您选择 POST 端点在某处返回 201 Created，则对每个 POST 端点使用相同的 HTTP 状态代码。

为什么？ 因为消费者不必担心在哪种情况下哪个端点上的哪个方法将返回哪个状态代码。

所以，要可预测（一致）。 如果您必须偏离惯例，请将其记录在带有大标志的地方。

通常，我坚持以下模式：

GET: 200 OK
PUT: 200 OK
POST: 201 Created
PATCH: 200 OK
DELETE: 204 No Content

8.不要嵌套资源

您现在可能已经注意到 REST API 处理资源。检索列表或资源的单个实例很简单。但是，当您处理相关资源时会发生什么？

例如，假设我们要检索特定作者的书籍列表 - name=Cagan 的作者。基本上有两种选择。

第一个选项是将书籍资源嵌套在作者资源下，例如：

GET: /authors/Cagan/books/

一些架构师推荐这种约定，因为它确实代表了作者与其书籍之间的一对多关系。

但是，现在还不清楚您请求的是什么类型的资源。是作者吗？是书吗？ …

同样扁平比嵌套更好，所以必须有更好的方法......而且有！ :)

我个人的建议是直接使用查询字符串参数过滤书籍资源：

GET: /books?author=Cagan

这显然意味着：“获取作者姓名 Cagan 的所有书籍”，对吗？ 🙂

9. 优雅地处理尾部斜杠

URIs 是否应该有一个斜杠/ 并不是一个真正的争论。您应该简单地选择一种方式或另一种方式（即带有或不带有尾部斜杠），坚持使用它并在客户端使用错误的约定时优雅地重定向客户端。

（我承认，我自己不止一次犯过这个罪。🙈）

讲故事的时间！ 📙 有一天，当我将 REST API 集成到我的一个项目中时，我在每次调用时不断收到 HTTP 500 内部错误。我使用的端点看起来像这样：

POST: /buckets

我很生气，我终其一生都无法弄清楚我到底做错了什么。 🤪

最后，结果是服务器出现故障，因为我缺少尾部斜杠！所以，我开始使用：

POST: /buckets/

Aaaand 之后一切顺利。 🤦‍♂️

API 尚未修复，但希望您可以为您的消费者避免此类问题。

💡专业提示：大多数基于 Web 的框架（Angular、React 等）都有一个选项可以优雅地重定向到 URL 的尾随或非尾随版本。找到该选项并尽早激活它。

10.利用查询字符串进行过滤和分页

大多数时候，一个简单的端点不足以满足各种复杂的业务案例。

您的消费者可能希望检索满足特定条件的项目，或一次少量检索它们以提高性能。

这正是过滤和分页的目的。

通过过滤，消费者可以指定返回的项目应该具有的参数（或属性）。

分页允许消费者检索数据集的一部分。最简单的一种分页是页码分页，它由一个page和一个page_size决定。

现在，问题是：您如何在 REST API 中合并这些功能？

我的回答是：使用查询字符串。

我会说为什么你应该使用查询字符串进行分页是很明显的。它看起来像这样：

GET: /books?page=1&page_size=10

但是，过滤可能不太明显。起初，您可能会想到做这样的事情来检索仅已出版书籍的列表：

GET: /books/published/

设计问题：已发布不是资源！相反，它是您正在检索的数据的特征。那种事情应该放在查询字符串中。

所以最后，用户可以像这样检索“包含 20 个项目的已出版书籍的第二页”：

GET: /books?published=true&page=2&page_size=10

非常明确，不是吗？

11、了解401 Unauthorized和403 Forbidden的区别

如果我每次看到开发人员甚至一些有经验的架构师都把它搞砸的话，我有一个季度的时间……

在处理 REST API 中的安全错误时，很容易混淆错误是与身份验证还是授权（也称为权限）有关 — 过去一直发生在我身上。

这是我的备忘单，用于了解我正在处理的内容，具体取决于情况：

• 消费者是否未提供身份验证凭据？他们的 SSO 令牌是否无效/超时？ 👉 401 未经授权。
• 消费者是否通过了正确的身份验证，但他们没有访问资源所需的权限/适当的许可？ 👉 403 禁止。

12.善用HTTP 202 Accepted

我发现 202 Accepted 是 201 Created 的一个非常方便的替代品。它基本上意味着：

我，服务器，已理解您的请求。我还没有创建资源（还），但这很好。

我发现 202 Accepted 特别适用于两种主要情况：

• 如果资源将作为未来处理的结果创建 - 例如：在作业/进程完成后。
• 如果资源已经以某种方式存在，但这不应被解释为错误。

13. 使用专门用于 REST API 的 Web 框架

作为最后一个最佳实践，让我们讨论这个问题：您实际上如何在您的 API 中实施最佳实践？

大多数情况下，您希望创建一个快速的 API，以便一些服务可以相互交互。

Python 开发者会使用 Flask，JavaScript 开发者会使用 Node（Express），他们会实现一些简单的路由来处理 HTTP 请求。

这种方法的问题在于，该框架通常不针对构建 REST API 服务器。

例如，Flask 和 Express 都是两个非常通用的框架，但它们并不是专门用来帮助您构建 REST API 的。

因此，您必须采取额外的步骤在 API 中实施最佳实践。大多数时候，懒惰或缺乏时间意味着你不会付出努力——并且会给你的消费者留下一个古怪的 API。

解决方案很简单：为工作使用正确的工具。

新框架已经出现在各种语言中，专门用于构建 REST API。它们可帮助您轻松遵循最佳实践，而不会牺牲生产力。

在 Python 中，我发现的最好的 API 框架之一是 Falcon。它就像 Flask 一样简单易用，非常快速且非常适合在几分钟内构建 REST API。

Falcon：减轻我们 0.0564 多个世纪以来 API 的负担。

如果你更喜欢 Django 类型的人，那么首选是 Django REST 框架。 它不是那么直观，但非常强大。

在 Node 中，Restify 似乎也是一个不错的选择，尽管我还没有开始尝试。

我强烈建议您试一试这些框架。 它们将帮助您构建美观、优雅且设计良好的 REST API。

结束语

我们都应该努力使 API 使用起来很愉快。 两者都是为了消费者和我们自己的开发人员。

我希望本文能帮助您学习一些技巧，并启发您构建更好的 REST API 的技术。 对我来说，它归结为良好的语义、简单性和常识。

REST API 设计是一门艺术，比什么都重要。

如果您对我上面分享的任何提示有不同的方法，请分享。 我很想听听。

与此同时，让他们的 API 不断涌现！

原文：https://abdulrwahab.medium.com/api-architecture-best-practices-for-desi…

本文：http://jiagoushi.pro/node/1633

在我之前的部分中，我分享了一些关于如何设计有效的 REST API 的最佳实践。

一个深思熟虑的设计还必须考虑 API 的性能方面。 如果 API 不能满足不断增长的请求以及不断变化的业务和/或客户需求，那么好的设计就毫无意义。

那么……什么是 API 性能？

就像任何性能一样，API 性能很大程度上取决于 API 如何响应和运行，以响应它收到的不同类型的请求。

示例：假设我们有一个面向客户的应用程序，用于显示客户的当前订单。 我们的应用程序从 API 获取订单详细信息。 但是现在，客户表示他们希望在一个地方查看所有订单（过去和当前）。 因此，我们构建了一个我的订单页面来显示客户的所有订单。 这意味着，我们的 API 现在将返回比以前更多的数据和更大的有效载荷。

我们如何确保我们的 API 能够将所有数据返回给我们的客户，而不会出现诸如延迟、服务器端错误和过多请求之类的问题？

性能提升技巧

1- 减少和限制有效载荷大小

响应数据的超大负载会减慢请求完成、其他服务调用的速度，并影响性能下降。 如您所知，现在我们正在为客户退回所有订单，而不仅仅是他们当前的订单，我们将不得不处理一些性能下降问题。

我们可以使用 GZip 压缩来减少我们的有效载荷大小。

这减少了我们在 Web 应用程序（客户端）上响应的下载大小，并提高了上传速度或某些实体（订单）的创建。

我们可以在 Web API 上使用 Deflate 压缩。

或者，我们可以将 Accept-Encodingrequest 标头更新为 gzip 。

2- 启用缓存

缓存是提高 API 性能的最简单方法之一。 如果我们有频繁返回相同响应的请求，那么该响应的缓存版本有助于避免额外的服务调用/数据库查询。

您需要确保在使用缓存定期使缓存中的数据无效时，尤其是在发生新数据更新时。

示例：假设我们的客户想要订购汽车零件，我们的应用调用一些汽车零件 API 来获取零件价格。 由于响应（部分价格）每周仅更改一次（@ 12:00am），因此我们可以在此之前的剩余时间内缓存响应。 这使我们不必每次都重新调用以返回相同的零件价格。

3-提供足够的网速

即使是设计最稳健的 API，缓慢的网络也会降低其性能。 不可靠的网络可能会导致停机，从而导致您的组织违反 SLA、服务条款和您可能对客户做出的承诺。 投资合适的网络基础设施很重要，这样我们才能保持所需的性能水平。

这可以通过利用和购买足够的云资源和基础设施来实现（例如：在 AWS 中，分配适当数量的 EC2 实例，使用网络负载均衡器）。

此外，如果您有大量后台进程，请在单独的线程上运行这些进程以避免阻塞请求。 您还可以使用镜像和内容交付网络 (CDN)（例如 CloudFront）来更快地处理全球不同地区的请求。

4- 防止意外调用、减速和滥用

您可能会遇到这样的情况，即您的 API 遭受 DDoS 攻击，这种攻击可能是恶意的、有意的，也可能是工程师调用 API 以从某个本地应用程序循环执行时无意的。

您可以通过测量交易并监控每个 IP 地址或每个 SSO/JWT 令牌（如果客户/调用应用程序在调用 API 之前获得授权）发生的交易数量来避免这种情况。

这种速率限制方法有助于减少会减慢 API 速度的过多请求，有助于处理意外调用/执行，并主动监控和识别可能的恶意活动。

5- 尝试在 PUT 上使用 PATCH

PUT 和 PATCH 操作会产生相同的结果，这是工程师之间的一个普遍误解。

它们在更新资源方面相似，但它们各自执行更新的方式不同。

PUT 操作通过向整个资源发送更新来更新资源。

PATCH 操作仅对需要更新的资源应用部分更新。 产生的 PATCH 调用产生更小的有效载荷，并大规模提高性能。

💡专业提示：尽管PATCH调用可以限制请求大小，但您应该注意它不是幂等的。 这意味着，PATCH 可能会通过一系列多次调用产生不同的结果。 因此，您应该仔细考虑使用 PATCH 请求的应用程序，并确保在需要时以幂等方式实现它们。 如果没有，请使用 PUT 请求。

6- 启用日志记录、监控和警报

这可能是您将在此处阅读的最重要的提示之一。 如果你应该从这篇文章中学到一件事，那就应该是这个！ 没有就这一点进行谈判。

拥有日志、监控和警报可帮助工程师在问题成为问题之前对其进行诊断和修复。 许多 API（基于 Express/Node 的、Java、Go）都有用于评估以下内容的预定义端点：

• /health
• /metrics

如果您没有启用日志记录，并且存在潜在问题，您将无法跟踪源，或特定请求中出现问题的位置。

如果您没有启用监控，您将无法从分析的角度了解某些问题或错误发生的频率。 这将阻止您考虑可能的解决方案。

而且……如果您没有启用警报，您将不知道是否存在问题，直到客户（或更糟的是，客户）报告它。 害怕！

7- 启用分页

分页有助于从多个响应中创建内容桶。 这种优化有助于改进响应，同时保留传输/显示给客户的数据。

您可以标准化、细分和限制响应，这有助于降低结果的复杂性，并通过仅提供客户要求的响应/结果来改善整体客户体验。

结束语

我们知道 API 非常棒，如果针对性能进行适当的优化和增强，它可以非常强大地为企业和客户提供出色的体验。

业务需求和客户期望总是随着时间的推移而发展。 作为负责任的工程师，我们可以决定如何以高性能的方式构建 API，这可以帮助我们实现并超越我们的目标。

这些技巧只是冰山一角，适用于一般设置中的所有 API。 根据您的特定 API 和用例、它与哪些服务交互、调用它的频率、调用它的位置等，您可能需要以不同的方式实现这些技巧。

原文：https://abdulrwahab.medium.com/api-architecture-performance-best-practi…

本文：http://jiagoushi.pro/node/1634

当今复杂的数字生态系统由许多相互关联的部分组成。 API 作为看门人和连接器在其中发挥着关键作用——提供了许多最终用户甚至没有注意到的自动化机会和效率。

企业密切关注 API。它们对于应用程序、数据和各种客户交互的功能至关重要。

这使得 API 管理成为几乎每个部门的组织的重要主题。根据 Zion Market Research 的数据，2017 年至 2022 年间，全球 API 管理市场预计将以 33.4% 的复合年增长率增长，到 2022 年将达到 34.3616 亿。

阅读本文以了解 API 管理是什么、它为组织带来的好处以及如何为您的业务获取正确的 API 管理解决方案。

什么是 API 管理？

API 管理是一组流程，用于分发、控制和分析组织用来跨云连接应用程序和数据并与外部世界连接的 API。

API 管理的主要目标是使创建自己的 API 或使用外部 API 的组织能够监控其活动并满足使用 API 的开发和应用程序的需求。这就是他们如何确保所有 API 的使用均符合公司政策并以适当的安全级别进行管理。

通过在您的组织和外部世界的边缘部署 API 管理，您可以获得从安全性和可追溯性到通信效率的重要功能。

API 管理由许多移动块组成，这些块通常合并到一个整体解决方案中。在 BlueSoft，我们采取了不同的方法。我们的解决方案 Agama API 在开发时考虑到了微服务模式，以使组织能够充分利用其 API 生态系统。许多企业现在转向微服务架构，因为它有助于加速软件开发。我们已经预料到了这一点，并准备了一个解决方案来帮助他们完成他们的旅程。

API 管理对 IT 世界的影响

API的功能究竟是什么？它们公开组织的数据并通过应用程序提供其资产。 API 还用于向客户、员工和合作伙伴交互添加数字层。

这就是 API 管理如此重要的原因。它为开发人员和企业提供了用于保护、扩展、管理、分析和货币化 API 程序的工具。

一项详细研究 API 采用在数字化转型计划中的作用的研究表明，API 是关键推动因素。结果显示，71% 的受访组织预计到 2022 年 API 调用量将增加。

 

API 管理的好处

改善客户体验

API 推动新应用程序的快速发展，并在各种渠道中创造无缝体验，满足客户的需求。由于连接性的提高，不同行业的组织可以在全新的水平上提供响应性和便利性。例如，API 带来了您必须自己构建的个性化和增值服务。

可扩展性

企业正在处理比以往更多的应用程序和数据。他们需要不断扩大规模，同时培养创新文化——通常是通过创建和发布新的 API。通过在整个 API 生命周期中简化访问并减少技术负担，API 管理支持可扩展性。

更严格的安全性

当多方（从内部开发人员到合作组织和客户）都可以访问 API 时，安全性成为关键焦点。当您的应用程序是分布式和断开连接时，管理数据访问可能会很棘手。

您需要采取一切可能的措施来保护敏感数据，并确保正确分配和管理权限。如果没有 API 管理解决方案，很难实现这一目标，因为您无法利用其可见性和一致性。

避免关键系统的变化

API 管理解决方案可以利用现有系统，并允许您避免对公司每天使用的关键系统进行任何更改。

变得更加敏捷和响应迅速

能够实时快速创建和发布任何端点有助于企业保持敏捷并变得更具适应性。

数据驱动的决策

API 管理解决方案收集和分析数据，让您深入了解使用模式、设备和地理位置——所有这些都旨在推动更明智的决策。

最大化开发人员性能

您的开发人员可以使用集中式生命周期管理解决方案来了解和分析整套 API 和 Web 服务。他们在一个集中的面板中获得出色的服务可见性和可追溯性，从而提高团队的工作效率。

由于专用的开发人员门户，开发人员还可以享受更轻松和自动化的文档管理。借助 Sandbox 等模块，API 管理工具还支持与外部开发团队进行测试。

API管理是如何实现的？

API 管理解决方案旨在使 API 创建、部署、发布和维护更容易和更精简。

不可否认，每个单独的 API 管理工具都带有一组独特的功能。大多数都提供安全、文档、沙盒环境和高可用性等核心功能。

如今，组织内部构建 API 管理解决方案或从第三方提供商处购买作为服务。在 Facebook、Google 和 Twitter 等科技巨头的推动下，开放 API 运动促进了 API 对轻量级 JSON 和 REST 服务的依赖，而不是传统的面向服务架构 (SOA)。现代工具经常使用这些格式。

API 管理软件必须包含哪些内容

以下是您在为您的业务选择正确的 API 管理工具时应该寻找的必备功能：

1. 提供 API 文档以及开发人员入职流程（例如注册和帐户管理）的开发人员门户。
2. 自动化和控制您的 API 和使用它们的应用程序之间的连接。
3. 一个 API 网关，作为所有客户端的单一入口点，并确定它们如何通过策略与 API 交互。
4. API 生命周期管理涵盖从设计、实施到退役的整个周期。
5. 通过使用合同实现 API 货币化。您可以通过基于 API 调用次数等指标定义的合约，通过访问 API 背后的微服务获利。
6. 能够监控来自单个应用程序的 API 流量，因此您可以了解您的 API 发生了什么——例如，哪个消费者或应用程序调用了哪个 API，以及失败的频率或多少 API（以及原因）。
7. 多个 API 实现和版本之间的一致性。
8. 提高应用程序性能的内存管理和缓存机制。
9. 保护 API 不被滥用并确保将正确权限授予正确人员的安全程序和策略。
10. 一个清晰的状态流来帮助 API 管理员——负责管理生产中可见的内容并负责哪个 API 在哪里工作的人。

如何知道您找到了正确的工具？

通过考虑可靠性、灵活性、API 行为质量、速度和成本等因素来衡量 API 管理的成功与否。

使用 Agama API 管理您的 API

我们的解决方案 Agama API 包括核心功能，例如 API 设计、发布分析、监控、安全和货币化。此外，它非常灵活，可以轻松与您的监控系统连接。

它的架构适用于两种替代方案：

• API管理解决方案负责数据转换的地方，
• 并且它是一个代理层，通过添加机制来保护通信，以启用缓存，这要归功于缓存。

我们可以在本地基础设施（数据中心）、公共云或混合环境中部署 Agama API。

在 BlueSoft，我们不遵循“黑盒方法”，可以根据您的独特需求轻松定制我们的 API 管理平台。我们知道，真正的价值与您的想法的独特性以及我们带来的不可或缺的标准化有关。

我们的专家可以帮助您部署、更改、支持和创建部署环境。我们经常建议我们的客户如何以务实的方式引入正确的机制。

最好的部分？您不必处理许可限制，例如用户限制、交易或处理能力。 Agama API 中没有这样的限制。

API 已经在塑造我们的数字生态系统方面发挥着关键作用。通过使用可靠的 API 管理解决方案（如 Agama API）来充分利用它们。

原文：https://bluesoft.com/what-is-api-management-and-why-is-it-important/

本文：https://jiagoushi.pro/node/1837

本文比较了标准 API 和服务，以通过 Internet 查询数据以进行分析、集成和数据管理。

Progress 的高级软件工程师 Jeff Leinbach 和 Progress 的开发布道者 Saikrishna Teja Bobba 进行了这项研究，以帮助您决定在您的应用程序或分析/数据管理工具中考虑采用哪种标准 API。我们对比了 OData、GraphQL 和 ORDS 之间的区别，它们是用于通过 Internet 查询和更新数据的标准 API 和服务。重点是实现跨 API 的互操作性，以进行分析、集成和数据管理。

我们一直在根据 AWS re:Invent、Oracle OpenWorld、Dreamforce、API World 等行业活动中的大量讨论跟踪这些主题。 Progress 在数据访问标准（包括 ODBC、JDBC、ADO.NET 和现在的 OData (REST)）的开发和贡献方面也拥有丰富的传统，并且是第一个加入 OData 技术委员会的成员。

什么是 REST？

REST（表示状态传输）或 RESTful Web 服务是在 Internet 上的计算机系统之间提供互操作性的一种方式。符合 REST 的 Web 服务允许请求系统使用一组统一且预定义的无状态操作来访问和操作 Web 资源的文本表示。 RESTful 实现使用 HTTP、URI、JSON 和 XML 等标准。

重要的是要注意 REST 是一种架构风格，而不是标准。

通过 Internet 查询数据的标准 API

OData

OData 最初由 Microsoft 于 2007 年开发，是一种 OASIS 标准 REST API，建立在 Microsoft、SAP、CA、IBM 和 Salesforce 等公司之间。它允许以简单和标准的方式创建和使用可查询和可互操作的 RESTful API。 OData 为您提供了一组丰富的查询功能，并因其开源方法以及出色的可扩展性而迅速获得支持。

GraphQL

GraphQL 于 2012 年在 Facebook 内部开发，在 2015 年公开发布之前，是一种部署在 Facebook、Shopify 和 Intuit 等公司的数据查询语言。 GraphQL 为您的 API 中的数据提供了完整且易于理解的描述，使客户能够准确地询问他们需要什么，使 API 更容易随着时间的推移而发展，并支持强大的开发人员工具。

ORDS

ORDS（Oracle REST 数据服务）是 Oracle REST 服务，它为以 Oracle 为中心的应用程序提供类似的标准化。它使具有 SQL 和其他数据库技能的开发人员能够构建对 Oracle 数据库的企业级数据访问 API，当今的现代、最先进的应用程序开发人员希望使用这些 API，并且确实越来越需要使用这些 API 来构建应用程序。 Oracle 的 60 个小组使用 ORDS，包括 Oracle Database、Times Ten 和 NoSQL。

对比标准 API

 

图 1

对比图 1 中的标准 API 的标准是基于实现与多个数据源的互操作性。 关于这种比较需要注意的一点是规范的成熟度。 尽管 GraphQL 越来越受欢迎，但在广泛采用、最佳实践和工具方面的成熟度仍然存在问题。

在 API 版本控制/维护下，您会认为“否”是不好的，但实际上是好的。 这是 GraphQL 的优势之一，我稍后会介绍。

图 2

在图 2 中，我们完成了对要考虑的其他标准的初步分析，并将在以后的文章中扩展这些领域。

标准查询能力

图 3

图 3 突出显示了通过开放标准接口访问数据的通用标准。 OData 全面支持所有这些查询功能。您可以使用 GraphQL 和 ORDS 执行其中一些操作，但它们没有标准化或以实现互操作性的方式记录。

GraphQL 与 REST 非常相似，因为它定义了与 Web 服务交互的方式，但它并没有告诉你服务的作用。因此，您可以通过创建可以调用的函数来进行过滤、排序和连接等操作，但应用程序开发人员必须了解它们在语义上的工作方式才能知道它们的行为是什么。

使用 ORDS，您可以进行聚合和连接，但这是通过创建您可以调用的自定义函数来完成的。但是应用程序必须知道这些函数做了什么才能理解如何解释结果。没有元数据或标准行为定义可以告诉应用程序会发生什么。

呈现元数据

图 4

图 4 比较了表面元数据，这是分析和数据管理应用程序的核心，需要以可互操作的方式以编程方式对模式进行逆向工程。

这些 API 中的每一个都在努力解决这个问题，但是 GraphQL 和 ORDS 不会告诉您数据的规模和精度，而 OData 会。 GraphQL 也不会告诉您主键，ORDS 也不会告诉您可空性。此信息对于应用程序能够知道它可以对每个特定字段做什么和不能做什么很重要。

API 版本控制和维护

一个令人头疼的问题是在 API 更改时处理应用程序的更新，同时还要维护旧版本。导致 REST API 令人头疼的最大问题是，当您查询端点时会返回所有字段。 API 开发人员无法了解客户是否依赖特定领域的信息。客户端开发人员必须处理所有返回的字段，即使他们不需要这些信息。

GraphQL 通过强制客户端准确指定他们需要哪些字段来解决 API 版本控制和维护问题。 API 开发人员可以主动联系已知的字段使用者，以迁移已弃用的字段。响应包括有关哪些字段已弃用的信息。

OData 通过提供一个选择列表来将返回的字段数限制为应用程序所需的字段数，从而提供类似的功能。这减少了应用程序中的响应大小和处理。但是，它没有提供一种机制来指示字段已被弃用。

OData 更加灵活，因为可以轻松编写查询以返回所有字段。 OData 正在将模式版本控制添加到规范中以解决此问题。

例子

为了直观地说明使用这些 API 的差异，以下两个代码示例展示了如何在 GraphQL 和 OData 中执行“排序依据”。

在 All Opportunities 函数调用的 GraphQL 示例中，从名称上可以看出它的作用。 但是，GraphQL 中没有任何内容可以告诉您可以为这些参数传递什么以及指定为参数的值如何导致函数运行。 并且这种行为在不同实现的基础上可能会有所不同。

相比之下，当您使用 orderBy 查询参数时，OData 会准确地告诉您它的行为方式，因为它的行为被定义为规范的一部分。

建议

 

GraphQL 几乎就像一种编程语言，这使得它非常灵活。它功能强大，但使用它意味着您的应用程序与特定 GraphQL 服务的实现方式紧密耦合。没有办法笼统地描述它是如何工作的。

对于习惯于处理 Web 服务的人来说，GraphQL 也可能有点尴尬，因为为了查询数据，您不需要执行 GET 操作，这就是您从普通 REST Web 服务获取结果的方式。您执行 POST，准确定义要包含在响应中的字段和函数。

因此，尽管 GraphQL 使您能够从元数据中确定哪些字段和函数可用，但您仍然不知道它们在语义上的含义。

消除进入障碍

本文主要关注 API 使用者，但 GraphQL 开发 API 的门槛要低得多。如果你正在做一个快速的项目，GraphQL 可能是要走的路。但是你仍然有你的应用程序与你的实现紧密耦合的问题。

OData 确实很强大，但是伴随着很多繁重的工作，因为您必须遵守标准的所有行为。您必须符合 OData 的最低行为级别。这为服务开发人员设置了更大的进入壁垒。

但是，您可以利用我们的混合技术来生成标准

REST API (OData)。 我们利用我们的混合技术完成所有繁重的工作，以生成标准的 REST API (OData)。 我们使用 OData 完成所有繁重的工作，因此您不必担心遵守标准。 我们为您降低了进入门槛。

此外，还有许多 OData 客户端可以帮助您快速轻松地启动和运行 OData 服务。 如果您正在开发一个新的应用程序，有很多已经支持 OData 的应用程序，以及可以为您提供帮助的 OData 客户端库。

如果您想了解如何嵌入我们的混合技术以使用 OData 通过 REST 公开数据，请立即与我们的一位数据连接专家交谈。

原文：https://www.progress.com/blogs/rest-api-industry-debate-odata-vs-graphq…

本文：https://jiagoushi.pro/node/2100

这篇最佳实践文章面向对创建 RESTful Web 服务感兴趣的开发人员，这些服务提供跨多个服务套件的高可靠性和一致性； 遵循这些准则； 服务定位于内部和外部客户快速、广泛、公开采用。

这是一个完整的图表，可以轻松理解 REST API 的原理、方法和最佳实践。

现在，让我们从每个盒子的原理开始详细说明它。

六项原则/约束

1. 客户端-服务器：关注点分离是客户端-服务器约束背后的原则。通过将用户界面问题与数据存储问题分开，我们提高了用户界面跨多个平台的可移植性，并通过简化服务器组件提高了可扩展性。
2. 无状态：通信必须是无状态的，如客户端-无状态-服务器 (CSS) 风格。从客户端到服务器的每个请求都必须包含理解请求所需的所有信息。因此，会话状态完全保留在客户端上。
3. 可缓存：为了提高网络效率，我们添加了缓存约束以形成客户端-缓存-无状态-服务器风格。缓存约束要求数据响应带有隐式或显式标签为可缓存或不可缓存的请求。如果响应是可缓存的，则客户端缓存有权为以后的等效请求重用该响应数据。
4. 分层系统：客户端通常无法判断它是直接连接到终端服务器还是沿途的中介。中间服务器可以通过启用负载平衡和提供共享缓存来提高系统可扩展性。层也可以强制执行安全策略。
5. 按需代码：REST 允许通过下载和执行小程序或脚本形式的代码来扩展客户端功能。通过减少需要预先实现的功能数量来简化客户端。它允许在部署后下载功能，提高了系统的可扩展性。
6. 统一接口：通过将通用性的软件工程原理应用于组件接口，简化了整个系统架构，提高了交互的可见性。实现与它们提供的服务分离，这鼓励了独立的可进化性。 REST 定义了四个接口约束：资源的识别、通过表示的资源操作、自描述消息和作为应用程序状态引擎的超媒体。
   1. 自描述消息：每条消息都包含足够的信息来描述如何处理消息。
   2. 基于资源：在请求中使用 URI 作为资源标识符来标识单个资源。资源本身在概念上与返回给客户端的表示分开。
   3. 通过表示操作资源：当客户端表示资源（包括附加的任何元数据）时，它有足够的信息来修改或删除服务器上的资源，前提是它有这样做的权限。
   4. 超媒体作为应用程序状态引擎 (HATEOAS)：客户端通过正文内容、查询字符串参数、请求标头和请求的 URI（资源名称）传递状态。服务通过正文内容、响应代码和响应头向客户端提供状态。

最佳实践

现在，让我们换个角度来了解 REST 的基本最佳实践，这是每个工程师都应该知道的。

• 保持简单和细粒度：创建模拟系统底层应用程序域或系统数据库架构的 API。最终，您将需要聚合服务——利用多种底层资源来减少闲聊的服务。
• 过滤和排序：对于大型数据集，从带宽的角度来看，限制返回的数据量至关重要。此外，我们可能希望指定要包含在响应中的资源的字段或属性，从而限制返回的数据量。我们最终想要查询特定值并对返回的数据进行排序。
• 版本控制：有很多方法可以破坏合同并对 API 开发中的客户产生负面影响。如果您不确定更改的后果，最好谨慎行事并考虑版本控制。在决定新版本是否合适或对现有表示的修改是否充分和可接受时，需要考虑几个因素。由于维护多个版本变得繁琐、复杂、容易出错且成本高昂，因此对于任何给定资源，您应该支持不超过两个版本。
• 缓存：缓存通过启用系统中的层来消除检索请求数据的远程调用来增强可扩展性。服务通过在响应（如 Cache-Control、Expires、Pragma、Last-Modified 等）上设置标头来提高缓存能力
• 分页：REST 的原则之一是连通性——通过超媒体链接。同时，没有它们，服务仍然有用。当链接在响应中返回时，API 变得更具自我描述性。对于支持分页的响应中返回的集合，“first”、“last”、“next”和“prev”链接至少是有益的。
• 资源命名：当资源命名正确时，API 是直观且易于使用的。做得不好，同样的 API 会让人感觉很笨拙，并且难以使用和理解。 RESTful API 适用于消费者。 URI 的名称和结构应该向这些消费者传达含义。通常很难知道数据边界应该是什么，但是通过了解您的数据，您很可能有能力进行尝试，并将什么作为代表返回给您的客户是有意义的。为您的客户设计，而不是为您的数据设计。
• - 复数：普遍接受的做法是始终在节点名称中使用复数形式，以保持您的 API URI 在所有 HTTP 方法中保持一致。原因是“客户”是服务套件中的一个集合，而 ID（例如 33245）指的是集合中的这些客户之一。
• 监控：确保添加各种监控以提高 API 的质量或性能。数据点可以是响应时间（P50、p90、P99）、状态代码（5XX、4XX 等）、网络带宽等等。
• 安全：
  • - 授权/认证：对服务的授权与对任何应用程序的授权没有什么不同。问这个问题，“这个主体对给定资源是否有请求的权限？”
  • - CORS：在服务器上实现 CORS 就像在响应中发送额外的 HTTP 标头一样简单，例如 Access-Control-Allow-Origin、Access-Control-Allow-Credentials 等
  • - TLS：所有身份验证都应使用 SSL。 OAuth2 需要授权服务器和访问令牌凭据才能使用 TLS。
  • - 幂等性：如果执行一次或多次，将产生相同结果的操作。根据其适用的上下文，它可能具有不同的含义。例如，在具有副作用的方法或子程序调用的情况下，这意味着修改后的状态在第一次调用后保持不变。
  • - 输入验证：验证服务器上的所有输入。接受“已知”好的输入并拒绝错误的输入，防止 SQL 和 NoSQL 注入，将消息大小限制为字段的确切长度，服务应仅显示一般错误消息等等。
  • - 限速：是一种限制网络流量的策略。它限制了某人在特定时间范围内重复操作的频率 - 例如，尝试登录帐户。
  • - 记录：确保您不会意外记录任何个人身份信息 (PII)。

至此，我结束了这次学习，我希望你今天学到了一些新东西。请分享给更多的同事或朋友。最后，考虑成为Medium会员，谢谢！

参考：

• REST API Tutorial
• REST Arch
• HATEOS

原文：https://blog.devgenius.io/best-practice-and-cheat-sheet-for-rest-api-de…

本文：https://jiagoushi.pro/node/1641

REST 是 REpresentational State Transfer 的首字母缩写词，是分布式超媒体系统的一种架构风格。罗伊菲尔丁于 2000 年在他的著名论文中首次提出了它。

与其他架构风格一样，REST 有其指导原则和约束。如果需要将服务接口称为 RESTful，则必须满足这些原则。

符合 REST 架构风格的 Web API（或 Web 服务）是 REST API。

1. REST 的指导原则

RESTful 架构的六个指导原则或约束是：

1.1 统一接口

通过将通用性原则应用于组件接口，我们可以简化整个系统架构并提高交互的可见性。

多个架构约束有助于获得统一的接口并指导组件的行为。

以下四个约束可以实现统一的 REST 接口：

• 资源标识——接口必须唯一标识客户端和服务器之间交互中涉及的每个资源。
• 通过表示(REpresentation)操作资源——资源在服务器响应中应该有统一的表示。 API 使用者应该使用这些表示来修改服务器中的资源状态。
• 自描述消息——每个资源表示应该携带足够的信息来描述如何处理消息。它还应该提供客户端可以对资源执行的附加操作的信息。
• 超媒体作为应用程序状态的引擎——客户端应该只有应用程序的初始 URI。客户端应用程序应该使用超链接动态驱动所有其他资源和交互。

1.2.客户端-服务器

客户端-服务器设计模式强制关注点分离，这有助于客户端和服务器组件独立发展。

通过将用户界面关注点（客户端）与数据存储关注点（服务器）分离，我们提高了用户界面跨多个平台的可移植性，并通过简化服务器组件来提高可扩展性。

在客户端和服务器发展的同时，我们必须确保客户端和服务器之间的接口/契约不会中断。

1.3.无状态

无状态要求从客户端到服务器的每个请求都必须包含理解和完成请求所需的所有信息。

服务器无法利用服务器上任何先前存储的上下文信息。

因此，客户端应用程序必须完全保持会话状态。

1.4.可缓存

可缓存约束要求响应应隐式或显式地将自身标记为可缓存或不可缓存。

如果响应是可缓存的，则客户端应用程序有权在稍后为等效请求和指定时间段重用响应数据。

1.5 分层系统

分层系统样式允许通过约束组件行为来由分层层组成架构。

例如，在分层系统中，每个组件都无法看到它们正在与之交互的直接层之外。

1.6 按需编码（可选）

REST 还允许通过以小程序或脚本的形式下载和执行代码来扩展客户端功能。

下载的代码通过减少需要预先实现的功能数量来简化客户端。服务器可以将部分功能以代码的形式交付给客户端，客户端只需要执行代码即可。

2. 什么是资源？

REST 中信息的关键抽象是资源。我们可以命名的任何信息都可以是资源。例如，REST 资源可以是文档或图像、临时服务、其他资源的集合或非虚拟对象（例如，人）。

资源在任何特定时间的状态称为资源表示。

资源表示包括：

• 数据
• 描述数据的元数据
• 以及可以帮助客户过渡到下一个所需状态的超媒体链接。

一个 REST API 由一组相互关联的资源组成。这组资源称为 REST API 的资源模型。

2.1资源标识符

REST 使用资源标识符来识别客户端和服务器组件之间交互中涉及的每个资源。

2.2.超媒体

表示的数据格式称为媒体类型。媒体类型标识了一个规范，该规范定义了如何处理表示。

RESTful API 看起来像超文本。每个可寻址的信息单元都带有一个地址，可以是显式的（例如，链接和 id 属性），也可以是隐式的（例如，源自媒体类型定义和表示结构）。

超文本（或超媒体）意味着信息和控制的同时呈现，使得信息成为用户（或 automaton）获得选择和选择动作的可供性。

请记住，超文本在浏览器上不需要是 HTML（或 XML 或 JSON）。当机器了解数据格式和关系类型时，它们可以跟踪链接。

— Roy Fielding

2.3.自我描述

此外，资源表示应该是自描述的：客户端不需要知道资源是员工还是设备。它应该根据与资源相关联的媒体类型进行操作。

所以在实践中，我们将创建许多自定义媒体类型——通常是一种媒体类型与一种资源相关联。

每种媒体类型都定义了一个默认处理模型。例如，HTML 定义了超文本的呈现过程以及每个元素周围的浏览器行为。

媒体类型与资源方法没有关系，得到/ put / post / delete / ......除了某些媒体类型元素将定义像href属性的锚元素的进程模型的事实之外，veroct方法，在对应于 CDATA 编码的 href 属性的 URI 上调用检索请求 (GET)。”

3. 资源方法

与 REST 相关的另一件重要事情是资源方法。这些资源方法用于在任何资源的两种状态之间执行所需的转换。

很多人错误地将资源方法与 HTTP 方法（即 GET/PUT/POST/DELETE）相关联。 Roy Fielding 从未提及任何关于在何种条件下使用哪种方法的建议。他所强调的只是它应该是一个统一的界面。

例如，如果我们决定应用程序 API 将使用 HTTP POST 来更新资源——而不是大多数人推荐的 HTTP PUT——那没关系。尽管如此，应用程序界面仍将是 RESTful。

理想情况下，转换资源状态所需的一切都应该是资源表示的一部分——包括所有支持的方法以及它们将以何种形式离开表示。

我们应该输入一个 REST API，除了初始 URI（书签）和一组适合目标受众的标准化媒体类型（即任何可能使用该 API 的客户端都可以理解）之外，没有任何先验知识。

从那时起，所有应用程序状态转换都必须由客户端选择服务器提供的选项来驱动，这些选项存在于接收到的表示中，或者由用户对这些表示的操作暗示。

转换可能由客户对媒体类型和资源通信机制的了解确定（或限制），这两者都可以即时改进（例如，按需编码）。 [这里的失败意味着带外信息正在推动交互而不是超文本。]

4. REST和HTTP不一样

许多人更喜欢将 HTTP 与 REST 进行比较。 REST 和 HTTP 不一样。

REST != HTTP

尽管 REST 还打算使 Web（互联网）更加精简和标准，但 Roy fielding 提倡更严格地使用 REST 原则。这就是人们尝试将 REST 与 Web 进行比较的地方。

Roy fielding 在他的论文中没有提到任何实现方向——包括任何协议偏好甚至 HTTP。到目前为止，我们都在遵守 REST 的六项指导原则，我们可以将其称为我们的接口——RESTful。

五、总结

简而言之，在 REST 架构风格中，数据和功能被视为资源，并使用统一资源标识符 (URI) 进行访问。

通过使用一组简单的、定义明确的操作对资源进行操作。此外，资源必须与其表示分离，以便客户端可以访问各种格式的内容，例如 HTML、XML、纯文本、PDF、JPEG、JSON 等。

客户端和服务器通过使用标准化的接口和协议来交换资源的表示。通常 HTTP 是最常用的协议，但 REST 并不强制要求它。

有关资源的元数据可用并用于控制缓存、检测传输错误、协商适当的表示格式以及执行身份验证或访问控制。

最重要的是，与服务器的每次交互都必须是无状态的。

所有这些原则都有助于 RESTful 应用程序变得简单、轻量和快速。

参考：

• REST APIs must be hypertext-driven
• REST Arch Style

原文：https://restfulapi.net/

本文：https://jiagoushi.pro/node/1929

在 API 工艺的世界里，没有比设计更受热议的领域了。 从 REST、gRPC 到 GraphQL，有许多方法可以设计和标准化 Web API 交互。 今天，我们将注意力转向另一种方法，JSON API，JSONAPI.org 上详细介绍的用于构建 API 的规范。

JSONAPI.org 中描述的 JSON API 非常适合使您的 JSON 响应格式更加一致。 以提高生产力和效率为目标，JSON API 因其可以消除多余的服务器请求的高效缓存功能而受到吹捧。

在这篇文章中，我们将定义 JSON API 是什么，并了解如何使用它来构建高效的 API。 我们将介绍 JSON API 的一些主要优点，并通过 FitBit 的案例研究了解该规范在实践中的应用情况。 希望本概述将介绍 JSON API 的新手，并帮助您判断它是否适合您的 API 场景。

什么是 JSON API (JSONAPI.org)？

JSON API 是一种适用于 HTTP 的格式。它描述了客户端应如何从服务器请求或编辑数据，以及服务器应如何响应所述请求。该规范的一个主要目标（现在是稳定的 v1.0）是优化 HTTP 请求；在请求数量和客户端和服务器之间交换的数据包大小方面。

“JSON API 是一种有线(Wire)协议，用于通过 HTTP 增量获取和更新图形”

——耶胡达·卡茨

在 JSON API 中，客户端和服务器都在请求文档中发送 JSON API 数据，带有以下标头，而不指定媒体类型参数：

Content-Type: application/vnd.api+json

JSON API 表示如何调用资源以及如何共享相关链接。 JSON 对象位于请求的根部，它必须包含资源数据、错误或元信息。数据以及与数据的关系可以通过 GET 调用来获取，如下所示：

GET /articles HTTP/1.1
Accept: application/vnd.api+json

以下是资源类型 `articles` 在 JSON API 响应中的显示方式：

// ...
{
  "type": "articles",
  "id": "1",
  "attributes": {
    "title": "Rails is Omakase"
  },
  "relationships": {
    "author": {
      "links": {
        "self": "/articles/1/relationships/author",
        "related": "/articles/1/author"
      },
      "data": { "type": "people", "id": "9" }
    }
  }
}
// ...

到目前为止，相当标准的东西。 JSON API 支持创建、更新和删除资源的典型 CRUD 流程。 JSON API 将始终向后兼容，它是一个社区驱动的计划，在 Github 上接受拉取请求。

使用 JSON API 的好处

既然我们对 JSON API 是什么有了基本的了解，那么有哪些独特的优势使它脱颖而出？

复合文档

复合文档是 JSON API 中的一项独特功能，允许服务器将相关资源与请求的主要资源一起发送——如果实施得当，这可以减少必要的 HTTP 请求的数量。复合文档使用 include 参数工作，如下所示：

GET https://api.example.com/posts?include=author

这使您能够在初始请求中包含其他资源。

稀疏字段集

如果您使用复合文档来包含相关资源，您可能会遇到回复量大的问题。再一次，JSON API 有一个解决方案。

JSON API 的另一个独特方面是稀疏字段集，它使客户端只能从特定字段请求数据。它通过将要检索的字段添加到具有资源名称和所需字段的 URI 参数来工作。这提供了额外的定制，可以减少臃肿。它看起来像：

 

GET /articles?include=author&;fields[articles]=title,body&;fields[people]=name HTTP/1.1
Accept: application/vnd.api+json

 

稀疏字段集是一种标准化方法，它允许客户端仅指定他们希望从对象中包含在响应中的属性。 使用稀疏字段集，您只能获得所需的字段，提供独特的定制潜力，这对精益数据共享环境很有吸引力。

可选性

JSONAPI.org 中的许多功能都是可选的；您可以关闭或打开它们。这些功能使客户能够决定接受哪些资源，从而很好地适应精益的移动环境。让客户就如何检索和处理数据达成一致是有帮助的，因为它消除了冗余和优化以减少膨胀。

优化功能

JSON API 配备了许多功能来优化 API 返回包。 JSON API 中的特殊服务器端操作包括排序和分页；将返回资源的数量限制为子集的能力，包括 first、last、next 和 prev 链接。

缓存

在他的演讲中，Lee 强调了定义良好的资源如何提高缓存能力，从而提高最终用户的“感知速度”。

“因为数据变化影响的资源更少，所以数据变化时失效的资源更少”

在 JSON API 用例中，缓存本质上是内置在 HTTP 中的。由于使用 JSON API 的客户端以相同的方式访问数据，因此他们不需要将数据存储在不同的位置。这种设计可能需要转变思想，但如果使用得当，可以带来显着的优化优势。

JSON API 如何在实践中使用：FitBit 案例研究

让我们看看 JSON API 如何在实践中实现以设计高效的 API，使用 FitBit 作为现实生活中的案例研究。

Jeremiah Lee 在 FitBit 领导 API 开发 4 年，在此期间他参与了他们的 JSON API 采用。健身可穿戴公司 FitBit 拥有蓬勃发展的 API 程序；在每年 40 亿次请求中，有 1/4 是通过第三方应用程序完成的，收入可观。

符合 API 风格有助于标准化客户端

一个常见的问题是当不同的客户端类型偏好不同的方法来从服务器检索数据时。围绕功能区域形成的工程团队通常一次一个平台地逐步实施新功能，并在每个客户端中找到相反的约束。

Lee 描述了 FitBit 团队如何拥有四个主要客户：Android、iOS、Windows 和 Web。一个主要问题是 Android 和 iOS 对 API 应该如何运行有非常不同的想法。 iOS 更喜欢较少的网络请求和较大的 API 响应，而 Android 更喜欢更多的网络请求和较小的 API 响应。

为了将这些约束规范化为一致的数据模型，团队必须首先解决请求数量和请求大小之间的争论。 FitBit 团队在具有敌对数据网络的移动环境中工作，无法依赖理想的客户端连接。

相信 HTTP/2、TLS 1.3 和改进的 LTE 网络的日益普及，FitBit 团队决定他们可以减少请求的开销、发出并发请求并减少安全延迟问题，同时相信更多弹性连接。这将导致他们采用更小的资源和许多轻量级的 HTTP 请求。

JSON API 帮助创建一致的数据模型

“如果没有明确的指导，数据模型可能会变得混乱。”

——耶利米·李

Lee 描述了在 FitBit，他们的 API 如何开始类似于“视图模型”；现有端点变得超载，数据相关性松散，而不是范围广泛。团队正在根据用户体验视图重载端点。

随着客户体验随着时间的推移而发展，团队正在以任意方式拆分数据。由于没有权威或风格可以遵循，这造成了很多不一致。客户端和服务器数据模型之间的错位造成了问题。团队需要就如何检索数据和处理数据达成一致，并且需要能够以很少的开销检查数据更改。

他们倾向于使用 JSON API 来规范化他们的数据。使用 JSON API 定义数据之间关系的能力，他们能够建立客户端-服务器通信期望。

JSON API 有助于保持同步

FitBit 案例中的另一个问题是与服务器保持同步。他们的设备需要经常与服务器同步，并且这些数据也可以被第三方应用程序修改。

这些更改必须非常快速地反映在所有 API 客户端中。 JSON API 利用的 HTTP 缓存使他们能够防止召回过时的数据，从而减少冗余并提高最终用户的感知速度。根据 Lee 的说法，这真的开始在一个应用程序中叠加多种体验。

比较 JSON API 和 GraphQL

既然我们本质上是在讨论使用图形，为什么不使用 GraphQL 呢？虽然您可以使用 GraphQL 实现许多相同的功能，但 Lee 看到了采用 JSON API 的两个主要好处：分页和可缓存性。

分页是 GraphQL 没有专门解决的一个领域。或者，当客户端请求它们时，JSON API 会向客户端提供诸如 next 和 prev 之类的链接。由于 GraphQL 中的分页完全由客户端处理，Lee 认为这很不幸，因为客户端可能会在不知不觉中进行昂贵、耗时的数据库查询。

GraphQL 也没有利用 HTTP 缓存功能，因为它与协议无关。由于没有建议的通用方法，这意味着每个 GraphQL API 处理缓存的方式都会略有不同。

“我个人认为缓存对于客户端性能考虑来说太重要了，不能事后考虑”

——耶利米·李

Lee 还指出，使用 JSON API 意味着开发人员不必采用像 GraphQL 这样的另一个工具链，而是可以继续使用他们很可能已经熟悉的技术。

GraphQL 的许多好处，例如查询效率和减少往返调用，都可以在 JSON API 中使用稀疏字段集和复合文档进行匹配。 JSON API 因此可以提供与 GraphQL 相同的功能。

考虑将 JSON API 用于“实用”的 API 设计

JSON API LogoJeremiah Lee 称其为“务实”，我们必须同意。如上所述，让客户端和服务器共享一个通用数据模型（如 JSON API）有很多优点。

“JSONAPI.org 规范应该是您的智能默认设置”

——耶利米·李

虽然 JSON API 并不适合所有情况，但许多人声称它是客户端和服务器通过 HTTP 共享通用数据接口的一种很好的默认方式。凭借上面列出的优势，以及它的健康采用，JSON API 似乎是 API 风格的有力竞争者。

我们鼓励您自己阅读规范。您如何看待 JSONAPI.org？您使用什么规范来定义您的 API 和数据模型？

资源

• Jeremiah Lee Slides with commentary
• Introduction to the JSON:API spec: Presentation by Marco Otte-Witte
• JSON API Homepage
• JSON API Specification
• JSON API Twitter
• JSON API Github
• JSON Patch: Can be used for incremental udpates

原文：https://nordicapis.com/the-benefits-of-using-json-api/

本文：

 

今天，eBay宣布他们正在利用OpenAPI规范(OAS)来实现它所有的RESTful公共api。使用OpenAPI，开发人员可以下载一个eBay OpenAPI契约，生成代码并在几分钟内成功调用一个eBay API。api在eBay的开发者生态系统中扮演着重要的角色，帮助公司建立并向买家和卖家提供最好的体验。

“考虑到我们对OpenAPI周围的开发者生态系统的需求和了解，使用OpenAPI规范是一个一致的选择，”eBay Portland的总经理盖尔·弗雷德里克(Gail Frederick)和eBay副总裁开发生态系统说。“OpenAPI规范实际上是描述api的标准，在eBay基于微服务的新体系结构中扮演着关键角色。”

作为OpenAPI计划的成员和主席，我看到越来越多的公司转向基于分布式和微服务的体系结构，因为为用户构建高质量的体验并更快地将产品或服务推向市场是任何企业成功的关键。为支持这种转换而创建的技术和工具主要是由开放协作构建的，跨越了像Node这样的应用程序开发技术。像Kubernetes这样的容器编排。由于api是分布式组件之间的“粘合剂”，因此OAS标准在这一转换中扮演了中心角色。

易趣就是这样。随着eBay从单一的、集中的体系结构过渡到分布式的微服务体系结构，公司需要改进服务契约的开发、测试、发布以及与API规范集成的方式。

该公司对这种转变有一系列需求:

API契约需要满足跨不同技术堆栈的无缝探索和集成的需求，成为行业标准，并具有丰富的特性，以补充我们的技术标准和治理模型，因此需要探索新的规范。

主要的标准是人类和机器可读的规范、语言无关性的规范、厂商中立的规范和开源的规范。

Shekhar Banerjee, MTS高级架构师，eBay

由于其工具支持、完全可定制的堆栈、代码优先和契约优先的API开发方法，以及最重要的是，OpenAPI作为由OpenAPI首创的开放协作所领导的标准继续发展，OAS成为了一致的选择。迁移到OAS进一步推进了eBay对其开发者生态系统的使命，即通过不再使用sdk和花费更多时间编写API客户端代码来提高开发者的效率和生产力。

自2017年8月以来，eBay一直是OpenAPI计划的成员之一，也是业内最早发布基于OpenAPI 3.0规范的合同的公司之一。我们很高兴看到eBay继续支持我们的联盟以及其他开放合作项目，包括云本地计算基金会(CNCF)。

问题：

我在职业生涯中使用过很多 OData，现在我来自不同团队的同事中很少有人建议我们迁移到 JsonAPI 和 GraphQL，因为它与 Microsoft 无关。 我对这两种查询语言都没有太多经验。 据我所知，OData 是 Salesforce、IBM、Microsoft 使用的标准，并且非常成熟。 为什么要切换到 JsonAPI 和/或 GraphQL？ 有真正的好处吗？ JsonAPI 和 GraphQL 是新标准吗？ 根据受欢迎程度更改公共 api 实现似乎没有用，尤其是在没有太大好处的情况下。

有人可以启发我吗？

答案：

OData 是与 JSON API 类似的规范。它们都描述了用于创建和使用 RESTful API 的标准协议。 GraphQL 是一种完全不同的 API 设计方法，并指定了一种查询 API 资源的不同方式。

OData：

自 2007 年以来在 Microsoft 设计和开发，由 OASIS 联盟标准化。最新版本 V4 已提交给 ISO/IEC JTC 1 以作为国际标准获得批准。技术委员会 (TC) 中的公司包括 CA Technologies、Citrix、IBM、Microsoft、Progress、Red Hat、SAP 和 SDL。

有许多用于流行编程语言的库 - .NET、Java、JavaScript、PHP 和 Ruby。该规范允许动态资源，并且有一个服务文档列出了所有 API 端点供客户端发现。此外，还有一个描述架构的元数据文档。

JSON API：

JSON API 最初由 Yehuda Katz 于 2013 年 5 月起草。这个初稿是从 Ember Data 的 REST 适配器隐式定义的 JSON 传输中提取的。该规范的当前稳定版本是 1.0。 JSON API 规范适用于大多数编程语言，包括客户端和服务器端。

JSON API 通过 JSON 文档中的链接属性支持 HATEOAS。其他功能包括分页、排序、过滤和关系。 JSON API 服务器生成的 JSON 文档非常冗长，带有许多嵌套属性。

GraphQL：

自 2015 年以来在 Facebook 开发。该规范仍是工作草案。它在 React 爱好者中很受欢迎，主要与 React 或 Vue.js 结合使用。与 GraphQL 类似的是 Falcor，它也相对较新。

虽然 GraphQL 使用 HTTP，但它不被视为 REST，而是 REST 的替代品。相反，它在单个（虚拟）JSON 文档中使用查询/响应模型。这种新模型更适合开发人员使用，但它相对于 REST 的优势是值得商榷的。鉴于其年轻，生态系统尚未成熟。

为了清楚和完整起见，我将 OpenAPI 包括在列表中，尽管它并不完全是 API 规范。这可能会让一些人感到困惑。 OpenAPI 标准是一种与语言无关的标准，用于描述和定义 API。例如，您的 API 可以遵循上述标准之一（不包括 GraphQL），也可以使用 OpenAPI 3 进行记录。

OpenAPI（又名 Swagger）：

作为 OpenAPI Initiative 和 Linux 基金会的一部分开发。得到 Google、Microsoft、IBM、SAP、Oracle、Ebay 和 PayPal 等大型科技公司的支持。该规范的当前版本是 3.1.0。大多数编程语言都有实现，以及许多其他工具，如 Web UI 生成器等。

使用 OpenAPI 等规范获得的最好的东西是围绕它们的工具——API 文档页面的生成器、客户端 SDK 代码的生成器等。

这个标准可能是当今最常用于 API 声明、文档和代码生成的标准。它还受到云提供商（如 Amazon Web Services）在其 API 网关中的支持。

总之，OData 和 JSON API 都是 JSON 数据格式，它们在数据周围添加上下文和特征（例如链接），GraphQL 是一种完全不同的查询和变异 JSON 数据的新方法，而 OpenAPI 是声明和记录任何数据的标准方法RESTful API。

我个人的看法：

如您所见，有很多 RESTful 规范，而不是单一的通用标准。我同意 xumix 的观点——他们似乎都患有“这里没有发明”综合症。选择上述任何一项的好处都很小，特别是如果您的项目是中小型项目。您的 API 实现的规范是否重要？应该不多吧。只需专注于构建一致且记录良好的 API。

原文：https://stackoverflow.com/questions/44711161/what-is-the-difference-bet…

本文：

尽管名为GraphQL，但它并不是一种简单的查询语言。这是一个全面解决现代应用与云服务之间连接问题的方案。因此，它构成了现代应用程序开发堆栈中一个新的重要层的基础:数据图。这个新层将公司的所有应用程序数据和服务集中在一个地方，具有一致的、安全的、易用的界面，这样任何人都可以在最小的摩擦下使用它。

在Apollo，我们从2015年就开始构建行业领先的数据图技术，我们估计我们的软件现在在超过90%的GraphQL实现中使用。多年来，我们与各种规模的公司中实现GraphQL的开发人员进行了数千次对话。我们希望分享我们所学到的知识，因此我们将他们的经验提炼为一组创建、维护和操作数据图的最佳实践。我们在这里将它们以10个GraphQL原则的形式呈现，分为三类，其格式受到了Twelve Factor应用程序的启发。

完整性原则

确保图定义良好、稳定且一致

1. 一个图

您的公司应该有一个统一的图表，而不是由每个团队创建的多个图表。

通过一个图形，你可以最大化GraphQL的价值:

• 可以通过一个查询访问更多的数据和服务
• 代码、查询、技能和经验可以跨团队移植
• 所有图形用户都可以查看的所有可用数据的中心目录
• 实现成本最小化，因为图形实现工作不重复
• 图的中央管理——例如，统一的访问控制策略——成为可能

当团队在没有协调工作的情况下创建他们自己的图表时，他们的图表几乎不可避免地会开始重叠，以不兼容的方式向图表添加相同的数据。在最好的情况下，这是昂贵的返工;在最坏的情况下，它会造成混乱。在公司的数据图采用过程中，应该尽可能早地遵循这一原则。

2. 联合实施

尽管只有一个图，但该图的实现应该跨多个团队联合。

如果没有高度专门化的基础设施，单片架构很难扩展，数据图也不例外。与在单个代码库中实现组织的整个数据图层不同，定义和实现图的责任应该划分到多个团队中。每个团队都应该负责维护公开他们的数据和服务的模式部分，同时拥有独立开发和在他们自己的发布周期上操作的灵活性。

这维护了图的单一、统一视图的价值，同时保持了整个公司的开发工作的分离。

3.跟踪注册表中的模式

应该有一个单一的事实来源来记录和跟踪图表。

就像在版本控制系统中跟踪源代码很重要一样，在模式注册表中跟踪图形的定义也很重要。您的公司应该有一个模式注册表，它是图形的权威定义，而不是依赖于当前正在运行的进程或在开发人员的笔记本上检入的任何代码。像一个源代码控制系统,注册表的模式存储修改图,谁让他们的历史,它应该理解图像的多个版本的概念(例如,登台和生产,或不同的开发分支)的方式相似的软件开发过程。

模式注册中心应该成为系统的中心，为开发人员工具、工作流或任何业务流程提供支持，这些业务流程将受益于对数据图的感知，以及对数据图的任何实际或建议的更改。

 

敏捷原则

快速展开图形并不断调整它以适应不断变化的需求

4. 抽象的,需求模式法

模式应该作为一个抽象层，为使用者提供灵活性，同时隐藏服务实现细节。

GraphQL的很大一部分价值在于提供了服务和使用者之间的抽象，因此该模式不应该与特定的服务实现或特定的使用者紧密耦合，因为它们现在已经存在了。通过将实现细节排除在模式之外，应该可以重构实现图的服务——例如，从一个整体转换到微服务，或者改变服务实现的语言——而不影响该领域的应用程序。同样，模式不应该与特定应用程序获取数据的方式紧密耦合。如果新应用程序的功能与现有的应用程序类似，那么应该可以编写新应用程序，而对图形的修改应该最小。

要实现这一点，可以使用面向需求的模式的标准:该模式侧重于为应用程序开发人员提供良好的开发体验，并根据现有图构建新功能。以这个标准为目标将有助于防止图与将来可能更改的服务实现耦合，并有助于增加添加到图中的每个字段的重用价值。

5. 使用敏捷方法进行模式开发

模式应该根据实际需求逐步构建，并随着时间的推移平稳地演进。

提前定义组织所有数据的“完美模式”可能很有诱惑力。相反，真正使模式有价值的是它遵循实际用户需求的程度，而这些需求从来都不是预先完全知道的，并且是不断变化的。实现“完美模式”的真正途径是使图易于根据实际需要进行演化。

不应该推测性地将字段添加到模式中。理想情况下，每个字段应该只在响应消费者对附加功能的具体需求时添加，而设计的目的是最大限度地让其他有类似需求的消费者重用。

更新图形应该是一个连续的过程。与其每隔6个月或12个月发布一个新的图形“版本”，不如在必要时每天多次更改图形。可以随时添加新字段。要删除字段，首先要弃用它，然后在没有使用者使用它时删除它。模式注册表支持图形的这种敏捷演化，以及使每个人都知道可能影响他们的更改的流程和工具。这确保了只有完全审查过的变更才能投入生产。

6. 迭代地提高性能

性能管理应该是一个连续的、数据驱动的过程，能够平稳地适应不断变化的查询负载和服务实现。

数据图层是讨论服务团队和使用其服务的应用程序开发人员之间的性能和容量的最佳位置。这个对话应该是一个持续的过程，它使服务开发人员能够持续地、主动地了解消费者打算用他们的服务做什么。

与其优化图形的每一种可能的用法，不如将重点放在支持生产中所需的实际查询形状上。工具应该提取提议的新查询形状，并在它们投入生产之前将它们呈现给所有受影响的服务团队，这些团队具有延迟需求和预计的查询量。一旦查询进入生产环境，就应该持续监视它的性能。如果遵循这一原则，那么很容易将问题追溯到行为不符合预期的服务。

7. 使用图形元数据来增强开发人员的能力

开发人员应该在整个开发过程中对图形有丰富的认识。

GraphQL的主要价值在于它为开发人员提供了巨大的生产力提升。为了最大限度地提高性能，开发人员的工具应该让他们对数据图有普遍的认识，并贯穿于他们在整个开发生命周期中使用的所有工具。

每当开发人员进行与管理数据或连接到服务相关的工作时，他们的工具应该将关于图的实时信息放在手边。这些信息应该是最新的，工具应该是高度智能的，以有用和强大的方式将图形感知应用到当前的情况。如果处理得当，不仅会提高开发人员的工作效率和幸福感，而且GraphQL还会成为连接前端和后端团队的纽带，在整个开发生命周期中实现无缝对话。

一些数据图形感知工具的功能的实际例子包括:

• 开发人员可以在他们的编辑器中享受所有可用图形数据和服务的实时文档，而且总是最新的。
• 有关废弃字段的信息可以传播到使用这些字段的开发人员的编辑器中，并提供建议的替代方案
• 根据实时生产数据，在开发人员输入查询时，可以向他们显示查询的估计成本(以延迟或服务器资源计算)。
• 运维团队可以跟踪后端服务的负载，将其追溯到特定的应用程序、版本、功能，甚至代码行，从而全面了解开发人员如何使用其服务。
• 当服务开发人员对其模式进行更改时，可以作为持续集成过程的一部分自动确定更改的影响。如果更改会破坏现有的客户机(根据重播最近的生产使用情况确定)，那么服务开发人员可以确定将受到影响的精确客户机、版本和开发人员。
• 当应用程序开发人员构建特性时，可以从他们的代码中提取支持这些特性的新查询，并与操作团队共享。有了这种认识，操作团队就可以提前提供所需的能力，并在开发过程的早期介入，如果查询不能在预期的范围内得到批准的话。
• 当应用程序是用类型化语言(如TypeScript、Java或Swift)开发的时候，类型信息可以从服务类型声明一直传播到应用程序的每一行代码，从而确保全堆栈类型的正确性和对错误的即时反馈。

操作原则

安全地将图部署到大规模生产环境中

8. 存取和需求控制

在每个客户端基础上授予对图形的访问权，并管理客户端可以访问什么以及如何访问它。

数据图中的授权具有两个同样重要的方面:访问控制和需求控制，前者表示允许用户访问哪些对象和字段，后者表示允许用户如何(以及多少)访问这些资源。虽然经常讨论访问控制，但也需要注意需求控制，因为它在GraphQL的任何生产部署中都是至关重要的。允许用户不考虑成本执行任何可能的查询是错误的，因为用户没有能力管理它对生产系统的影响。访问和需求控制都必须在充分了解数据图的语义和性能的情况下执行。在不分析实际发送的查询的情况下，仅将用户限制在每分钟特定的查询数量是不够的，因为查询可以访问大量的服务，而且查询的成本可以在多个数量级上变化。

验证在数据图也有两个方面:请求操作的应用程序,并使用这个应用程序的人。虽然访问控制中心的人使用应用程序,适当的需求控制至少取决于每个应用控制人均控制,应用程序的开发人员,而不是应用程序的用户负责应用程序所使用的特定查询的形状做它的工作。

控制需求的最佳方法包括:

• 当不受信任的用户访问生产系统时，他们应该只发送由经过验证的应用程序开发人员预先注册的查询，而不是允许他们使用应用程序的凭据发送任意查询。对于只分发给可信用户的内部应用程序来说，这有时并不严格。
• 对于预计将发送大量查询的应用程序，团队应该设计一个与更广泛的软件开发周期相一致的查询审批工作流，以便在查询进入生产之前对其进行审查。这可以确保它们不会获取不必要的数据，并且服务器的容量可以支持它们。
• 作为第二道防线，在执行查询之前估计它的成本，并为每个用户和每个应用程序制定查询成本预算，可以防止过度使用预先注册的操作，或者在无法进行预先注册的操作的情况下。
• 开发人员应该能够禁用特定应用程序在生产环境中发送特定查询的能力，无论是作为紧急情况下的安全网，还是发现第三方应用程序以不可接受的方式使用数据图。

 

9. 结构化的日志

捕获所有图形操作的结构化日志，并利用它们作为了解图形用法的主要工具。

可以捕获关于在图上执行的每个操作(读或写)的大量信息:哪些用户和应用程序执行了该操作、访问了哪些字段、实际执行操作的方式、如何执行操作，等等。这些资料非常宝贵，应当有系统地加以收集，供以后使用。它应该以结构化的、机器可读的格式捕获，而不是文本日志，这样就可以为尽可能多的目的利用它。

图形操作的记录称为跟踪。跟踪应该召集所有相关信息关于一个操作在一个地方,包括业务信息(谁做了手术,访问或改变,哪些功能的应用程序由哪些开发人员,是否成功,如何执行)和纯技术信息(后端服务联系,每个服务如何导致延迟,是否使用缓存)。

因为跟踪真正地捕获了一个图是如何被使用的，它们可以被用于广泛的用途:

• 了解是否可以删除废弃字段，或者是否可以删除仍在访问它的特定客户端，以及它们的重要性
• 根据实时的生产数据，实时地预测一个查询需要多长时间执行，因为开发人员正在他们的IDE中输入查询
• 自动检测生产中的问题(如增加的延迟或错误率)并诊断其根本原因
• 提供权威的审计跟踪，显示哪些用户访问了特定的记录
• 为商业智能查询提供支持(当天气炎热时，人们会在自己所在的地方更频繁地搜索冰激凌吗?)
• 根据API使用情况为合作伙伴生成发票，可以根据访问的特定字段或消耗的资源创建详细的成本模型

所有图形操作的跟踪应该集中在一个中心位置，这样就有了一个权威的跟踪流。然后，这个流可以通过管道进入其他可观察性系统(可能在对不支持graphql的现有系统进行简单转换之后)，或者存储在一个或多个数据仓库中供以后使用(根据预算、用例和规模的需要进行汇总和取样)。

10. 将GraphQL层与服务层分离

采用分层架构，将数据图功能分解为单独的层，而不是整合到每个服务中。

在大多数API技术中，客户机不直接与服务器通信，除非在开发中。取而代之的是一种分层的方法，其中将一些问题(如负载平衡、缓存、服务位置或API密钥管理)分解为单独的一层。然后，可以将此层与后端服务分开设计、操作和伸缩。

GraphQL也不例外。与其将一个完整的数据图系统所需的所有功能都放到每个服务中，不如将大多数数据图功能分解成位于客户端和服务之间的独立层，让每个服务专注于服务于实际的客户端请求。这一层可以由多个进程组成，执行访问和需求控制、联合、跟踪收集和潜在的缓存等功能。这一层的某些部分是特定于graphql的，需要深入了解数据图，而负载平衡和客户端身份验证等其他功能可能由现有系统来执行。

即使在只有一个应用程序和一个服务的简单场景中，这个单独的层也是有价值的;否则，属于中间层的功能必须在服务器中实现。在复杂的应用程序中,这一层可能开始看起来像一个地理上分布的系统:通过多个入口点接收传入的查询,处理其中一些在网络的边缘边缘缓存的好处,路由子组件查询多个数据中心的公共云,民营,或由合作伙伴,最后这些组件组装成一个查询结果,同时记录跟踪,这是纪念整个操作。

在某些情况下，此数据图层将使用GraphQL与后端服务通信。但是，最常见的情况是，后端服务保持不变，并继续被它们现有的api(如REST、SOAP、gRPC、Thrift甚至SQL)访问，这些api与数据图对象之间的映射由构成数据图层一部分的服务器完成。

 

原文：https://principledgraphql.com

讨论：请加入知识星球【首席架构师圈】

ℹ️ Updated on 2020-07-18 ℹ️

Benchmarking with wrk

• Threads : 8
• Timeout : 8
• Duration : 15s (seconds)

ℹ️ Sorted by max req/s on concurrency 64 ℹ️

	Language	Framework	Speed (64)	Speed (256)	Speed (512)
1	php (7.4)	mark (1.1)	167 900	172 088	173 349
2	nim (1.2)	httpbeast (0.2)	165 808	197 548	200 123
3	javascript (13.14)	nanoexpress-pro (2.2)	159 374	203 682	209 592
4	go (1.14)	fasthttp (1.15)	158 244	170 931	174 931
5	nim (1.2)	whip (0.2)	157 852	185 577	186 965
6	go (1.14)	atreugo (11.4)	153 402	165 386	169 576
7	go (1.14)	router (1.2)	152 854	164 684	169 379
8	go (1.14)	fasthttprouter (0.1)	152 460	164 763	168 679
9	javascript (13.14)	sifrr (0.0)	151 082	193 326	196 249
10	go (1.14)	gorouter-fasthttp (4.4)	150 957	162 632	166 975
11	go (1.14)	gearbox (1.0)	149 964	161 740	165 613
12	java (11)	rapidoid (5.5)	148 731	176 813	177 967
13	java (11)	jooby (2.8)	144 563	187 072	191 087
14	kotlin (1.3)	kooby (2.8)	143 410	184 223	188 305
15	c (11)	agoo-c (0.7)	143 179	189 183	191 403
16	java (11)	light-4j (2.0)	141 210	176 879	181 302
17	crystal (0.35)	router.cr (0.2)	139 828	167 278	166 448
18	crystal (0.35)	toro (0.4)	139 397	169 974	169 052
19	crystal (0.35)	spider-gazelle (3.3)	138 223	165 592	164 228
20	php (7.4)	workerman (4.0)	137 200	167 944	170 403
21	crystal (0.35)	kemal (0.26)	132 422	156 420	154 940
22	crystal (0.35)	grip (0.28)	130 657	156 505	154 662
23	nim (1.2)	jester (0.4)	130 311	152 825	154 276
24	rust (1.45)	actix (2.0)	125 383	136 847	133 849
25	crystal (0.35)	amber (0.35)	125 178	144 644	143 136
26	php (7.4)	simps (1.0)	106 139	161 415	178 670
27	go (1.14)	clevergo (0.3)	104 631	106 188	110 306
28	go (1.14)	rte (0.0)	104 620	106 149	110 679
29	java (11)	act (1.9)	104 185	134 428	135 251
30	go (1.14)	echo (4.1)	103 125	105 277	109 307
31	go (1.14)	httprouter (1.3)	103 050	104 779	108 820
32	go (1.14)	fiber (1.12)	102 607	147 858	158 998
33	go (1.14)	gin (1.6)	101 067	106 832	110 609
34	go (1.14)	chi (4.1)	98 634	99 431	103 165
35	go (1.14)	gorouter (4.4)	98 633	103 964	107 547
36	go (1.14)	aero (1.3)	97 903	99 607	103 562
37	go (1.14)	violetear (7.0)	96 608	97 463	101 120
38	go (1.14)	webgo (4.1)	95 193	96 077	99 893
39	csharp (8.0)	aspnetcore (3.1)	94 733	108 017	110 905
40	go (1.14)	goroute (0.0)	94 052	93 621	97 834
41	go (1.14)	kami (2.2)	93 292	100 148	102 552
42	fsharp (4.7)	falco (1.2)	92 339	106 072	108 406
43	go (1.14)	gorilla-mux (1.7)	92 088	90 908	95 179
44	fsharp (4.7)	frank (6.1)	91 990	104 069	106 111
45	go (1.14)	beego (1.12)	91 186	96 653	100 384
46	javascript (13.14)	polkadot (1.0)	90 657	102 551	103 376
47	crystal (0.35)	athena (0.9)	86 509	105 308	104 455
48	c (99)	kore (3.3)	85 960	119 082	141 485
49	javascript (13.14)	0http (2.5)	85 365	98 058	99 126
50	javascript (13.14)	restana (4.6)	81 941	91 578	91 555
51	cpp (14/17)	drogon (1.0)	81 662	87 368	90 524
52	javascript (13.14)	polka (0.5)	80 601	88 104	87 295
53	go (1.14)	air (0.19)	80 321	81 983	85 383
54	javascript (13.14)	rayo (1.3)	78 392	85 836	84 595
55	javascript (13.14)	fastify (3.1)	77 280	86 412	85 020
56	elixir (1.1)	cowboy_stream (2.8)	77 117	79 037	77 251
57	php (7.4)	one (2.0)	76 042	91 735	96 299
58	ruby (2.7)	agoo (2.13)	74 106	110 573	123 845
59	go (1.14)	gf (1.13)	73 254	80 074	81 884
60	scala (2.13)	akkahttp (10.1)	73 141	85 596	82 421
61	csharp (8.0)	carter (5.1)	73 130	74 246	66 783
62	swift (5.2)	perfect (3.1)	72 461	82 137	87 742
63	php (7.4)	hyperf (2.0)	71 889	90 300	94 927
64	java (11)	javalin (3.9)	71 495	79 141	78 295
65	javascript (13.14)	muneem (2.4)	70 256	77 801	76 235
66	python (3.8)	falcon (2.0)	68 617	75 668	76 314
67	kotlin (1.3)	ktor (1.2)	67 121	88 190	88 361
68	fsharp (4.7)	saturn (0.14)	66 497	62 731	55 831
69	java (11)	spring-boot (2.3)	65 455	71 623	71 444
70	javascript (13.14)	foxify (0.1)	64 148	70 024	69 199
71	php (7.4)	comet (0.8)	62 612	67 405	67 497
72	go (1.14)	mars (1.0)	59 797	60 607	64 349
73	javascript (13.14)	koa (2.13)	59 674	65 111	63 278
74	java (11)	micronaut (1.2)	57 662	66 616	65 711
75	fsharp (4.7)	websharper (4.6)	56 923	58 362	54 924
76	javascript (13.14)	iotjs-express (0.0)	56 004	58 967	59 745
77	haskell (8.8)	scotty (0.12)	55 879	62 428	66 645
78	python (3.8)	bottle (0.12)	55 116	60 823	60 007
79	clojure (1.1)	coast (1.0)	53 021	54 762	54 992
80	javascript (13.14)	feathersjs (4.5)	53 012	56 219	55 119
81	javascript (13.14)	express (4.17)	52 902	56 723	55 330
82	rust (1.45)	nickel (0.11)	52 618	48 793	51 696
83	python (3.8)	apidaora (0.27)	51 515	59 053	59 192
84	java (11)	spring-framework (5.2)	51 296	59 316	59 156
85	javascript (13.14)	nestjs-fastify (7.3)	50 931	60 892	59 478
86	swift (5.2)	kitura (2.9)	50 405	50 872	50 863
87	swift (5.2)	kitura-nio (2.9)	49 712	51 150	51 070
88	javascript (13.14)	moleculer (0.14)	49 456	52 663	51 879
89	elixir (1.1)	cowboy (2.8)	47 798	48 484	48 750
90	python (3.8)	pyramid (1.1)	47 764	50 253	50 442
91	python (3.8)	asgineer (0.7)	47 627	54 254	54 501
92	rust (1.45)	gotham (0.4)	46 373	52 337	54 878
93	php (7.4)	siler-swoole (1.7)	45 565	68 053	74 899
94	swift (5.2)	vapor (4.23)	45 341	48 039	47 892
95	python (3.8)	blacksheep (0.2)	44 967	50 418	50 507
96	cpp (11)	evhtp (1.2)	43 647	44 683	44 202
97	scala (2.13)	http4s (0.21)	42 326	48 277	47 692
98	javascript (13.14)	hapi (19.1)	42 248	45 758	44 916
99	python (3.8)	hug (2.6)	42 168	44 293	44 976
100	javascript (13.14)	nestjs-express (7.3)	41 140	43 789	42 970
101	php (7.4)	imi (1.2)	41 017	47 086	47 684
102	python (3.8)	sanic (20.6)	40 439	48 110	47 946
103	python (3.8)	starlette (0.13)	40 394	44 210	44 588
104	javascript (13.14)	restify (8.5)	39 954	43 417	42 549
105	elixir (1.1)	plug (1.10)	39 654	40 583	40 747
106	csharp (8.0)	simplify.web (4.1)	36 547	37 086	35 917
107	python (3.8)	emmett (2.0)	35 263	39 568	39 663
108	crystal (0.35)	orion (3.0)	34 914	33 918	29 528
109	scala (2.13)	play (2.8)	34 647	37 040	37 025
110	elixir (1.1)	phoenix (1.5)	33 992	35 518	35 721
111	clojure (1.1)	luminus (1.0)	31 689	32 569	32 417
112	crystal (0.35)	shivneri (0.15)	30 797	30 161	27 481
113	haskell (8.8)	servant (0.17)	30 434	29 284	28 323
114	fsharp (4.7)	giraffe (4.1)	30 235	28 822	28 120
115	dart (2.8)	aqueduct (3.3)	29 971	30 096	29 962
116	fsharp (4.7)	suave (2.5)	29 197	29 977	31 845
117	nim (1.2)	rosencrantz (0.4)	27 634	23 877	21 571
118	php (7.4)	swoft (2.0)	27 634	33 470	34 678
119	python (3.8)	fastapi (0.59)	26 912	29 394	29 387
120	nim (1.2)	akane (0.1)	26 627	22 183	19 714
121	php (7.4)	yii-swoole (2.0)	26 277	31 291	32 132
122	ruby (2.7)	syro (3.2)	25 741	29 593	28 479
123	php (7.4)	sw-fw-less (preview)	25 667	31 452	31 917
124	ruby (2.7)	hanami-api (0.1)	25 632	28 830	27 512
125	ruby (2.7)	roda (3.34)	24 920	28 354	27 291
126	python (3.8)	molten (1.0)	24 593	25 860	25 732
127	python (3.8)	responder (2.0)	24 299	26 653	26 415
128	php (7.4)	chubbyphp-swoole (3.1)	24 293	29 108	29 633
129	rust (1.45)	iron (0.6)	24 175	24 341	24 340
130	python (3.8)	aiohttp (3.6)	23 664	26 132	26 490
131	python (3.8)	clastic (19.9)	23 404	25 203	25 107
132	javascript (13.14)	turbo_polka (0.3)	23 248	22 736	21 330
133	ruby (2.7)	cuba (3.9)	23 016	25 621	25 030
134	python (3.8)	masonite (2.3)	22 134	23 324	23 179
135	python (3.8)	flask (1.1)	22 075	23 192	23 136
136	go (1.14)	macaron (1.3)	20 151	22 685	22 867
137	ruby (2.7)	rack-routing (0.0)	19 946	21 276	21 418
138	ruby (2.7)	rack_app (7.6)	19 540	20 793	20 692
139	ruby (2.7)	camping (2.1)	18 954	19 060	18 964
140	java (11)	blade (2.0)	15 292	17 610	17 259
141	dart (2.8)	start (0.4)	14 224	13 842	12 911
142	go (1.14)	tango (0.6)	14 146	14 645	14 701
143	php (7.4)	spiral (2.4)	13 078	13 360	13 230
144	crystal (0.35)	runcobo (0.2)	13 002	12 826	11 896
145	ruby (2.7)	sinatra (2.0)	12 825	12 867	12 936
146	go (1.14)	gramework (1.7)	12 526	12 784	12 771
147	java (11)	struts2 (2.5)	12 128	13 157	12 915
148	javascript (13.14)	sails (1.2)	12 108	12 938	12 548
149	ruby (2.7)	grape (1.4)	11 869	11 833	11 831
150	python (3.8)	quart (0.13)	11 074	11 607	10 829
151	php (7.4)	chubbyphp-roadrunner (3.1)	10 004	10 777	10 760
152	swift (5.2)	swifter (1.4)	9 942	10 134	10 016
153	php (7.4)	sunrise-router-roadrunner (2.4)	9 743	9 456	9 244
154	python (3.8)	django (3.0)	9 480	9 487	9 184
155	python (3.8)	tornado (6.0)	9 092	9 871	9 402
156	python (3.8)	cherrypy (18.6)	8 804	8 765	8 703
157	pony (0.35)	jennet (0.1)	8 516	16 636	15 585
158	ruby (2.7)	flame (4.18)	8 030	8 004	8 002
159	php (7.4)	fastsitephp (1.3)	7 981	7 896	7 748
160	ruby (2.7)	hanami (1.3)	7 803	7 920	7 958
161	python (3.8)	tonberry (0.2)	6 888	6 603	6 290
162	php (7.4)	ubiquity (2.3)	6 787	6 679	6 670
163	php (7.4)	one-fpm (2.0)	6 071	5 943	5 990
164	php (7.4)	phalcon (4.0)	5 792	5 717	5 735
165	php (7.4)	hamlet (3.2)	5 773	5 687	5 708
166	php (7.4)	siler (1.7)	5 685	5 636	5 658
167	php (7.4)	bearframework (1.2)	5 142	5 097	5 129
168	php (7.4)	ice (1.5)	5 006	4 976	5 016
169	php (7.4)	sunrise-router (2.4)	4 945	4 913	4 946
170	php (7.4)	chubbyphp (3.1)	4 568	4 555	4 613
171	php (7.4)	slim (4.5)	3 819	3 843	3 895
172	v (0.1)	vape (0.3)	3 692	1 734	2 287
173	ruby (2.7)	rails (6.0)	3 683	3 452	3 438
174	php (7.4)	nette (3.0)	3 654	3 696	3 744
175	php (7.4)	lumen (7.2)	3 506	3 534	3 637
176	php (7.4)	yii (2.0)	3 444	3 487	3 543
177	julia (1.5)	merly (0.2)	3 392	8 155	6 444
178	perl (5.32)	dancer2 (2.0)	3 235	2 528	1 359
179	php (7.4)	sunrise-router-annotations (2.4)	3 130	3 177	3 226
180	php (7.4)	symfony (5.1)	2 770	2 801	2 846
181	php (7.4)	mezzio (3.2)	2 488	2 525	2 546
182	python (3.8)	cyclone (1.3)	2 416	2 416	2 412
183	ruby (2.7)	pakyow (1.0)	2 286	2 275	2 293
184	python (3.8)	klein (20.6)	1 588	1 609	1 600
185	python (3.8)	nameko (2.12)	1 523	1 487	1 468
186	php (7.4)	laminas (3.1)	1 339	1 358	1 380
187	php (7.4)	codeigniter4 (4.0)	1 039	1 059	1 122
188	php (7.4)	basicphp (0.9)	586	465	548
189	php (7.4)	laravel (7.2)	320	159	3 655
190	crystal (0.35)	lucky (0.23)	306	332	323

原文：https://github.com/the-benchmarker/web-frameworks

本文：

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】

Web3已成为一种将区块链、智能合约和去中心化应用程序结合在一起的尝试，但其真正的功效难以确定。

Web3，如Web3基金会设想的那样，将是一个公共互联网，数据和内容被注册在块链上，在对等分布式网络上进行令牌化或管理和访问。

Web3有望成为一个去中心化的、不可变的web版本，不存在中间人，并具有与加密货币、不可替代代币（NFT）和以分布式账本（DAPP）为基础的新型去中心化应用程序相同的加密可验证性。

如果所有这些听起来都很复杂，那是因为它是复杂的。就目前而言，Web3是一个有点模糊的概念，它仍然被定义为一个更理想的web外观，而不是一个可供开发人员构建的有形且可访问的技术堆栈。

这种模糊性导致了整个行业在这个术语上的某种程度的分歧，有人称赞Web3是一种革命性的方式，可以让互联网回归自由主义的根基，而著名的怀疑论者，如密码乐观主义者埃隆·马斯克（Elon Musk），则认为Web3是一个“营销时髦词”

Web3的起源

Web3首先由以太坊区块链的创建者之一Gavin Wood描述。在2014年的一篇博文中，伍德设想“Web3.0”是一个加密的在线空间，以应对爱德华·斯诺登（Edward Snowden）2013年披露的全球监控事件所引发的隐私问题。

他写道，在Web3中，“我们假设是公开的信息，我们发布。我们假设是一致同意的信息，我们放在共识账上。我们假设是私人的信息，我们保守秘密，从不泄露。”。

该模型将通过加密技术“在数学上强制实施”，在加密技术中，交易将被验证并添加到区块链中，以实现普遍的透明性和不可撤销性。

在2021年11月的有线采访中，伍德进一步细化了这个定义，以“少信任，多真相”。

Web3这个词直到2021才真正开始流行，然而，当像Andreessen Horowitz合作伙伴Chris Dixon这样的风险资本家开始把Web3作为一个“由建造者和用户拥有的互联网，用令牌编排的时候”。

作为这一领域的大投资者，Andreessen Horowitz在Web3游戏中有着丰富的经验，因此有必要采取一些有益的措施，Twitter联合创始人杰克·多尔西（Jack Dorsey）等批评者非常乐意将Web3称为“一个有着不同标签的中央集权实体”

Web 1.0和Web 2.0

如果Web3是internet的下一个迭代，那么它与Web1.0和Web2.0到底有什么不同？

从1990年到2004年左右，Web1.0是现代互联网的第一次迭代。在Web1.0时代，用户通常使用静态网页，其中只读内容由雅虎和AOL等一小群看门人创建和分发。

Web2.0是一种动态的、交互式的Web，在这种Web中，静态网页由应用程序和用户生成的内容连接在一起。Web2.0由一系列占主导地位的平台统治，比如FAANG公司Facebook（现在的Meta）、亚马逊、苹果、Netflix和谷歌的市场力量，所有这些公司都在一定程度上为个人数据交换服务。

Web3与Web2.0的不同之处在于，它消除了这些强大的把关人，增强了互联网的平等性。在互联网上，用户通过各种代币的所有权获得回报，同时在共享、分布式、防篡改的账本上保持其数据的私密性和安全性。

“本质上，这意味着我个人可以像世界上任何人一样轻松地成为这项整体服务的提供者或共同提供者，”伍德告诉《连线》。

这反映在Web3基金会的任务声明中，通过“去中心化和公平的互联网，用户控制自己的数据、身份和命运”来“培育去中心化式Web软件协议的尖端应用”。

这种想法自然产生了去中心化的自治组织或DAO，它们是高度民主的互联网社区，有着共同的目标，没有领导结构。当然，一个人的平等主义网络可能是另一个人不受管制的野蛮西方。

Web3与Tim Berners Lee早在1999年就将其描述为Web3.0或语义网（semantic Web），后者专注于使互联网机器可读，但这一愿景在很大程度上尚未实现。

Web3堆栈

一些工程师已经尝试定义Web3堆栈，因为它目前存在，但这不是一个简单的练习。

Nader Dabit，前AWS高级开发人员倡导者，现为Web3公司Edge&Node的开发人员关系工程师，试图从高层次概述Web3堆栈，包括：

• 区块链
• 区块链开发环境
• 文件存储
• P2P数据库
• API（索引和查询）
• 身份
• 客户端（框架和库）
• 其他议定书

这显然与当今常用的web开发三层体系结构有很大的不同，三层体系结构包括：

• 前端web服务器
• 中间层应用服务器
• 后端数据库或数据存储

Preethi Kasireddy拥有在风险投资公司Andreessen Horowitz和加密交换Coinbase工作的独特地位。她在Web3体系结构上的博客文章展示了一个开发模型，“您可以编写智能合约，定义应用程序的逻辑，并将其部署到去中心化的状态机[即以太坊区块链]。”

智能合约的编写本身可能需要学习新的编程语言，如Solidity、Vyper，或者越来越多的Rust。然后，您需要了解如何部署到以太坊虚拟机，或您选择的区块链的类似执行机制。

开发人员还需要掌握向区块链“签署”交易的机制，MetaMask将自己确立为这一过程的早期行业标准工具。

接下来，Kasireddy讨论了在以太坊上构建应用程序的扩展问题。她写道：“任何在以太坊上构建应用程序的人都知道，在区块链上存储所有东西会变得非常昂贵，速度非常快。”。这就需要“一个去中心化的链外存储解决方案，如IPFS[星际文件系统]或Swarm。”

随着越来越多的开发人员涌入该领域，以及工具的成熟，这些问题可能会得到解决。像Polygon这样的项目已经在研究区块链缩放问题的解决方案。但就目前而言，在新生的Web3堆栈上开发应用程序看起来很有挑战性。

正如Kasireddy自己所写，“如果所有这些都让你头晕目眩，那么你并不孤单。拼凑所有这些工具是复杂的，可能会带来痛苦的开发体验。但不要担心，我们开始看到新的开发框架，它们真的改善了开发人员的体验。”

Web3应用程序

Web3怀疑论者经常提出的一个问题是，应用程序在哪里？正如上面所概述的那样，随着一个新的、复杂的应用程序栈的出现，我们还没有看到大量杀手级Web3应用程序进入市场也就不足为奇了。

虽然Web3承诺将NFT和加密货币所有权的基础技术带入web的潜在新领域，但这一承诺尚未兑现。

早期的Web3项目往往由它们的不易访问性和微妙的用户体验来定义。要访问大多数Web3应用程序，用户需要一个加密钱包，很可能需要一个新的浏览器，了解全新的术语世界，并愿意支付在以太坊区块链上执行操作所需的不稳定“气体”费用。这些都是普通互联网用户进入互联网的重大障碍。

虽然去中心化的社交网络Mastodon和GitHub clone Radicle是基于一些Web3原则构建的，就像勇敢的浏览器一样，大多数现有的Web3应用程序都是为了交易加密资产或在赌场游戏上下注加密货币。

“如果Web3将成为身份识别或社交媒体的未来，我们需要问问自己，有什么证据表明采用Web3真的比前几代互联网技术更好吗？”Tim O'Reilly问道，他创造了Web2.0这个术语。

Web3基金会在其网站上列出了几个项目，但这些项目主要集中在构建互操作Web3所需的底层协议上。

正如区块链和信任新架构的作者凯文·沃巴赫（Kevin Werbach）对TechCrunch所说：“许多所谓的Web3解决方案并不像看上去那样去中心化，而其他解决方案还没有显示出它们的可扩展性、安全性和可访问性足以满足大众市场的需要。”

Web3入门

准备好开始了吗？您可以在许多地方了解有关Web3核心原则和技术的更多信息。

Edge&Node的Dabit建议从流行的以太坊区块链和用于编写智能合同的Solidity编程语言的文档开始。然后，您可以开始探索Web3工具、库和API的全新世界。你还需要一个加密钱包，比如MetaMask，来管理你的Web3资产。

随着人们对这个术语兴趣的增长，也出现了一些Web3教程，包括Udemy、Coursera、Web3大学、Buildspace等网站上出现的教程，以及通过以太坊网站本身出现的教程。

原文：https://www.infoworld.com/article/3646597/what-is-web3-a-new-decentrali…

本文：

当我们谈论 web3 时，我怀疑大多数技术人员会立即想到 NFT、加密货币或 DeFi。 我不能责怪他们：从 Twitter 的活动来看，这主要是事实。

但作为开发人员，我真正感兴趣的并不是 NFT、加密货币或 DeFi。事实上，我估计这些项目中有 95% 充其量是高风险的，最坏的情况是骗局——而且绝对没有准备好 供消费者采用。

同时，我也觉得剩下的5%是值得提倡的。 我说作为一个应该成为 Web 2.0 助推器的人：几年前，我的专注于开发人员的初创公司被 Airbnb 收购，如果我选择去，我在传统硅谷框架内的职业选择非常好 那样。

相反，在过去的 6 个月里，我将我的创意和专业精力投入到为 web3 开发人员创建免费的开源工具上：Studio 721

• Studio 721, an open source website for creating and uploading metadata and artwork to IPFS (web3 file hosting), and deploying NFT smart contracts to the Ethereum and Polygon blockchains

我对 web3 作为开发者平台的未来持乐观态度。因为尽管整个平台存在许多缺点，但一些 web3 功能已经令人震惊，对开发人员来说非常好用。以下是其中三个特别适用于基于以太坊的项目的功能：

使用以太坊登录

在以太坊区块链上为应用程序创建注册过程就像添加钱包连接选项一样简单和即时。该系统的构建使登录成为其架构的核心。从隐私和安全的角度来看，泄露个人数据的想法并不存在，因为应用程序只能访问消费者自己已经公开的数据。

将此与创建一个将 Facebook 作为登录选项结合的应用程序进行对比。对于开发人员来说，这是一个耗时的麻烦。你首先需要设置一个开发者账号，同意 Facebook 的服务条款，然后集成官方 SDK。这个过程至少需要几天时间，实际上，您还想为 Apple、Google、Twitter 等添加登录选项。毕竟，如果 Facebook 或其他平台巨头不批准您的应用程序 - 并且围绕它的规则非常模糊——他们可以立即将其关闭。

尽管如此，我们实际上别无选择，只能使用 Facebook 和其他社交网络。实际上，他们已经是我们在现代社会中的许多活动的守门人。尽管 Facebook 不仅“拥有”你的所有数据，而且可以（而且经常拥有！）意外泄露它而几乎没有追索权。以太坊为这一切提供了一个可行的替代方案。

这让我想到了下一点：

全球测试网络

Web 2.0 的另一个挫折是缺乏简单、安全和可互操作的测试网络。假设您正在开展在线零售业务，并且您想制作一个推特应用程序来发布当天的热门商品。您可能希望在构建应用程序时对其进行测试。但是，无法创建虚拟 Twitter 帐户或虚假推文。而且，如果您的应用程序存在错误，则很容易开始使用可能敏感的业务数据向垃圾推文发送垃圾邮件。此示例中的风险很低，因为您的新业务可能没有任何 Twitter 关注者。但是，一旦您的企业收集个人数据或与支付处理器相关联，风险就会变得非常严重；那么一个错误就会威胁到人们的财务或隐私。

即使在 Facebook 和其他科技巨头，这类数据泄露已经经常发生，以至于许多人认为这只是软件开发中不可避免的一部分。一些平台确实支持测试账户，尤其是在风险很高的情况下。但是很多人没有，或者即使他们这样做了，他们也经常受到限制，阻止（例如）Facebook 测试账户和 Stripe 测试账户之间的完全互操作性。

相比之下，以太坊再次闪耀，提供了一个单一的全球网络，区块链上的所有软件都可以无缝通信。作为这种架构的自然结果，可以启动整个网络的测试版本，包括其上的每个应用程序。现在所有结果（包括由错误引起的任何外部性）都可以进行模拟和安全测试。这种力量根本不存在于 web3 之外。它使无畏的发展成为可能。

内置支付处理

最后，支付：作为开发商，收取 IAP 和其他收入一直是一个关键的摩擦点。从理论上讲，集成像 Stripe 这样的处理器应该很容易，但这也意味着设置帐户、签署平台的服务条款、学习其 API 并处理其合规性要求。作为跳过这些障碍的交换，您作为开发人员必须等待付款被处理——但前提是平台首先削减了您的收入。

相比之下，以太坊仍然存在交易费用，但作为开发人员，您通常会在一分钟内收到付款。虽然许多支付处理器并不支持每个国家，但以太坊在全球范围内自动得到支持。是的，交易费用目前可能相当高。但作为开发者，我相信这个可扩展性问题是可以解决的，而不是 web3 的根本缺陷。现实的解决方案正在开发中，就 L2s 而言，已经成为他们自己的创新平台。

—

出于所有这些原因以及更多原因，作为一名开发人员，从 Web 2.0 堆栈转变并尝试这个新环境是非常令人兴奋的。我可以从从事 web3 工作的开发人员那里感受到同样的能量；我会在推特上发布我在业余时间制作的一个有趣的小应用程序，第二天，我的 Discord 中就有 800 人兴奋地谈论它。

这并不是说 web3 是完美的——远非如此。普通消费者还没有为用户体验做好准备，对 NFT 和加密货币的投机炒作只会加剧这个问题，对消费者的采用产生不切实际的期望。

归根结底，对我来说，真正重要的是开发人员的 web3 基础设施。

可以这样想：在 Web 2.0 期间，几乎没有任何消费者将 Linux 作为自己直接个人使用的操作系统。但是对于消费者网络的后台架构和我们现在都认为理所当然的开发人员工具来说，Linux 仍然是不可或缺的。这就是为什么我在未来几年的职业生涯中投资于相信 web3 将沿着类似的路径发展的原因。

原文：https://medium.com/@devinabbott/i-sold-my-startup-to-airbnb-and-went-al…

本文：https://jiagoushi.pro/node/2008

这些都是2022年在Java、Ruby、Python、JavaScript、PHP、Scala和Golang中进行web开发的最佳后端开发框架

大家好，如果您是一名应用程序编程人员，正在寻找2022年要学习的最佳后端框架，那么您来对地方了。在前面，我已经分享了最好的全栈开发课程，在本文中，我将与您分享创建web应用程序的10个最好的后端框架。

Web开发通常分为两类：前端开发和后端开发。后端开发人员负责构建web应用程序的服务器端。

当前端部分与用户交互时，后端部分负责内部工作。如果没有后端，前端可能会工作，也可能无法工作，但要创建一个功能齐全的web应用程序，必须有一个与前端连接的适当后端。

后端开发人员的角色不同于前端开发人员。前端开发人员更关注应用程序的外观，而后端开发人员则关注服务器、数据库以及两端的连接和交互方式。

后端开发人员应该具备许多必要的技能。理解后端框架就是其中之一。有几种后端框架，本文将讨论目前使用的顶级后端框架。

该列表包括基于编程语言和技术堆栈的最佳后端框架。这意味着您不需要学习所有这些，而是选择与您选择的编程语言和技术堆栈相匹配的一种。

2022年10个最佳Web开发后端框架

在不浪费任何时间的情况下，这里列出了程序员可以为web开发学习的10个最佳后端框架。虽然在特定的技术堆栈或编程语言（如Java开发人员）中有很多选择，但也有MicroNaut, Quarkus, Vert.X,、 和其他框架，但我只根据受欢迎程度、成熟度和功能选择了最好的框架，比如Spring Boot。

1.面向Java开发人员的Spring框架+Spring Boot

Java被认为是一种常青的编程语言。它的一个常见用途是在后端开发中。Spring框架是最好的Java框架之一。

它于2002年发布，今天，它是最流行的后端框架之一，用于创建基于spring的生产级独立应用程序。

使用Spring boot很容易，因为它省略了Spring框架所具有的各种配置开销。当您使用Spring框架项目（如Spring Boot、Spring Cloud、Spring security等）时，您可以获得许多有用的功能，如缓存、事务管理、配置管理、监控、安全蚀刻。

如果你想在2022年学习Spring框架和Spring Boot，并且需要资源，那么我强烈建议你加入Udemy上的Spring和Hibernate（包括Spring Boot）课程。超过200000名Java开发人员参加了这门课程，学习Spring、Hibernate和Spring Boot，这是Java中最重要的三种后端框架。

2.面向Python开发人员的Django

Django是web开发中最流行的Python框架。Django基于Don't Repeat Yourself（DRY）原则，注重代码重用，从而提高了开发速度。它也是一个非常安全的框架。

作为一个Python框架，Django非常用户友好，易于学习。它也是最流行的全堆栈框架之一，提供了很多现成的功能，比如REST API支持。

如果你想在2022年学习Django，那么我建议你参加由Jose Portilla在Udemy上开设的Python和Django全栈Web开发者训练营课程。

Jose是一位很棒的讲师，这门32小时的Django课程是在线学习Django最全面的资源之一。

Python开发人员的最佳后端框架

3.面向JavaScript开发人员的Express.js 

JavaScript是世界上最流行的编程语言。随着节点的出现。js，JavaScript在后端开发社区的受欢迎程度迅速增加，在过去十年中，Node。js已经成为顶级品牌之一。

这就是为什么Express在2010年为节点开发者发布的原因。它是一个极小的节点。js框架用于开发高度灵活的应用程序。

考虑到JavaScript是最流行的web开发语言，而且可能是唯一一种提供从前端到后端到移动学习的全堆栈开发的语言，Expressjs可能是程序员的最佳选择。

如果你想学习表达。2022年的js需要一个资源，我推荐MERN堆栈从前到后：完整堆栈React、Redux和Node。js课程由我最喜欢的Udemy讲师Brad Traversy编写，这门课程非常适合任何想学习使用MERN stack进行全栈web开发的人，MERN stack包括React和Express。js。

4.面向.Net 开发者的ASP.NET core 

ASP。NET内核是ASP的继承者。网它是一个开源的、独立于平台的框架，用于在平台上构建web应用程序。NET平台。它被认为是性能最好的后端框架之一。

它基本上是ASP的统一版本。NET MVC和ASP。NET Web API转换为编程模块，从而使其功能更加强大。

如果你想学习ASP。NET核心，并需要一个资源，然后我建议你加入完整的ASP。网络MVC 5课程由Mosh Hamedani在Udemy上完成。这门7.5小时的课程最适合C#and。NET开发人员谁想要学习ASP。网

C#开发者的最佳后端框架

5.面向PHP程序员的Laravel

PHP是后端开发中使用最多的编程语言之一。Larvel是一个基于MVC架构的PHP框架。它是一个初学者友好的框架，具有用户友好的界面、广泛的库和出色的API支持。

使用Laravel可以简化后端开发，同时构建现代安全的web应用程序。如果您正在处理非平凡的应用程序，这一点尤其正确。

如果你想学习幼虫，并为PHP开发者寻找学习Laravel的最佳在线课程，那么你也可以通过Laravel为初学者查看PHP——成为Udemy上Laravel课程的大师。这门43小时的课程是在线学习拉拉瓦尔的最佳课程之一。

6.面向Ruby程序员的Ruby on Rails

Ruby on rails，俗称rails，是一个基于MVC架构的服务器端框架。这是一个初学者友好的框架，易于理解和学习。

然而，它的优点和缺点仍然存在争议，但它因其用户友好而受到世界各地后端开发人员的喜爱。

如果你想在2022年学习Ruby on Rails并需要资源，那么Rob Percival在Udemy上的完整Ruby on Rails开发人员课程是一个很好的课程。它有超过46小时的内容和157篇文章，8个编码练习和1个可下载资源。

Ruby开发者的最佳后端框架

7.面向Golang开发者的Fiber 框架

Fiber是Golang程序员的web开发框架。它构建在Fasthttp之上，Fasthttp是Go最快的HTTP引擎。它的设计目的是在考虑到零内存分配和性能的情况下简化快速开发

Fiber是一个精简但功能极其强大的框架。由于极度精简，很容易将第三方库与马提尼酒整合在一起。该框架提供了更多的可伸缩性和更少的开销问题。

它类似于Express。js和js对路由、服务静态文件、构建restapi、灵活的中间件支持、模板引擎和低内存占用有很好的支持。

如果你想了解更多关于使用Golang和Fiber构建web应用程序的知识，我建议你加入Rob Percival和CodeStars在Udemy上的完整React&Golang课程。这是一门基于项目的课程，你将使用React和Golang Fiber从头开始构建一个管理应用程序。

8.面向PHP开发人员的CakePHP框架

CakePHP是另一个PHP框架，它基于另一个流行的后端框架Ruby on rails的概念。

它遵循MVC体系结构，并提供了一些有用的功能，如模型视图控制器、前端控制器、活动记录、数据映射和配置约定。

如果你想从头开始学习CakePHP，并且需要一个资源，我建议你在Udemy上查看CakePHP for初学者，以完成项目课程。这门6小时的课程是Udemy上评分最高的CakePHP课程，适合初学者和经验丰富的PHP程序员。

最佳PHP后端框架

9.Python开发人员的Flask框架

Flask是另一个可用于后端开发的python框架。它被认为是一个微框架，因为它省略了特定工具和库的使用。此外，没有数据库抽象层、表单验证或外部源依赖。

它是一个简单、高度灵活、高性能的web框架。作为一个轻量级的框架或微框架，它很容易学习和理解。此外，作为一个Python框架，它非常用户友好。

如果你想从头开始学习Flask，并且需要一个资源，那么你也可以在Udemy上通过Flask和Python课程查看REST API。由Jose Salvatierra创建，这门17小时的课程非常适合学习web开发。

最佳Python后端框架

10.Scala开发人员的Play框架

PLAY是用Scala和Java编写的，是最强大的后端web框架之一。它基于MVC架构，提供各种功能，如热代码重新加载、显示程序错误，以及专注于提高开发人员的盈利能力。

此外，它是RESTfull和非阻塞的。

如果你想学习Scala并开始使用Play Framework进行web开发，并且需要一个资源来开始在线学习，那么我建议你加入Scala&Functional Programming for初学者|在Udemy上学习JVM课程。

这是一门在线学习Scala的好课程，是Play框架所必需的，已经有超过3万名学生加入了这门课程。

用于web开发的最佳Scala后端框架

这就是程序员在2022年能学到的最好的后端框架。正如我所说，如果你想成为一名完整的堆栈工程师或后端工程师，学习后端开发是值得的。如今，后端开发依赖于后端框架。

有几种后端框架，有些流行，有些不流行。在本文中，我们讨论了顶级后端框架。所有这些框架在后端社区都非常流行，在就业市场上对它们有巨大的需求。

大多数框架都是用流行的编程语言编写的，比如Java、Python和JavaScript。如果您是初学者，可以从Ruby on rails等对初学者友好的框架或Flask等轻量级框架开始。如果你热衷于学习最受欢迎的，那么你可以选择Spring Boot、Django或Express。

原文：https://medium.com/javarevisited/10-best-backend-frameworks-for-web-dev…

本文：https://jiagoushi.pro/node/2061

“弄清楚下一个大趋势是什么，告诉我们应该关注什么。”-马克·扎克伯格

多年来，Web开发已被证明是任何组织/企业成功的不可或缺的因素。它是您业务的窗口，有助于您在全球范围内发展业务。

现在，Web开发世界在不断变化，趋势也在不断变化。有时，这些趋势的变化速度远远超过了它们的使用速度。为了保持领先，有必要关注正在流行的最新趋势、更新、技术和方法。此外，了解趋势并控制周围发生的事情对于web开发来说是非常重要的。

在分析了2023年网络发展趋势列表中各行业的趋势后，我们收集了一些趋势。在接下来的一年里，您将了解值得您关注的顶级网络技术堆栈。

我们列出这个列表是为了节省时间，并帮助您在即将到来的时代发展业务。所以，让我们开始吧。

1.单页应用程序

都在一个地方。无需切换。无需等待。。！！

嗯，当一次点击就可以从服务器上下载一个网页时，这有点令人恼火。它还会消耗你的时间，也会给用户留下不好的影响。这种情况导致了SPA的趋势。

SPA是近年来的趋势之一，有助于避免与服务器的长时间通信。它提供了更好的页面性能，并提供了高级别的数据保护。

因此，单页应用程序是一种在浏览器内工作的应用程序，在使用过程中不需要重新加载页面。您每天都在使用这种类型的应用程序。例如，Gmail、谷歌地图、Facebook或GitHub。

图片来源：Pinterest

随着2023年JavaScript框架的兴起，SPA将使用这种语言进行内容加载，这种趋势不会很快消失。此外，这些应用程序不需要额外的等待时间，为用户提供即时反馈。此外，它还提供了一些惊人的优势。

优点：

• 原生浏览器环境中出色的UX/UI
• 节省的带宽
• 使用Chrome工具更轻松地设置和调试
• 对API的关注
• 缓存过程的效率

单页应用示例：

• Google web services: Drive, Spreadsheet, Maps
• Trello
• Twitter
• Github

例如，您可以查看Sneat Bootstrap 5 HTML管理模板。它是最新的对开发人员最友好的🤘🏻 & 高度可定制✨ 基于Bootstrap 5的管理面板模板。

此外，最高的行业标准被认为会为您带来最好的引导程序管理模板，不仅速度快🚀易于使用，但具有高度可扩展性。

此外，Sneat Bootstrap 5管理模板功能强大，还允许您构建任何类型的web应用程序。例如，您可以创建：

• SaaS平台
• 项目管理应用程序
• 电子商务后端
• CRM系统
• 分析应用程序
• 银行应用程序
• 教育应用程序
• 健身应用程序及更多…。

此外，您可以使用这个最好的创新Bootstrap管理员来创建引人注目、高质量和高性能的Web应用程序。此外，您的应用程序将完全响应，确保它们在台式机、平板电脑和移动设备上看起来令人惊叹，功能完美。

特点：

• 基于Bootstrap 5
• 垂直和水平布局
• 默认、带边框和半暗主题
• 支持明暗模式
• 国际化/i18n和RTL就绪
• 布局生成器
• 主题配置：轻松定制我们的模板。
• SASS供电
• 全响应布局
• 清除注释代码（&C）
• 记录良好
• 享受无忧支持

 

也可在React Dashboard版本中获得。

2. Progressive Web Apps (PWA)

Image credit: Pinterest

你拇指上的一切…！！我们知道这个概念，对吧？导航方便，工作平稳，装载量少，速度快。是的，这就是PWA，即Progressive Web App的意义。。！！快速、可靠、流畅的用户友好体验。

毫无疑问，PWA并不是什么新鲜事。尽管如此，自从它来到这里以来，它一直是这个小镇的话题，而且它也将在2023年占据主导地位。现代开发商和投资者之所以瞄准它，是因为它能够提供高质量的用户体验。由于它们对移动非常友好，毫无疑问，对PWA的需求将增加。

好吧，Progressive Web Apps（PWA）是用现代API构建和增强的，以提供增强的功能、可靠性和可安装性，同时使用单个代码库访问任何设备上的任何人、任何地方。这使得它适合跨设备兼容性。

它们不仅快速、即时加载，还允许用户离线使用服务，同时执行本地应用程序的所有功能。

优点

• PWA有助于提供流畅且用户友好的网络体验。
• 有助于降低反弹率
• 脱机工作，因为它独立于连接
• 使您的应用程序可靠、功能强大且可安装

使用PWA的一些服务示例：

• Uber
• Twitter
• Smashing Magazine
• Pinterest
• Instagram
• Forbes

 

3. 人工智能开发

根据报告“2019年人工智能市场的价值将达到399亿美元，到2025年可能达到1906.1亿美元，预测期内的复合年增长率为42.2%。”这是一个相当大的数字…！！不是吗？😮

 

现在，如果网站的内容或布局不吸引人，大约38%的人会跳过网站。超过75%的客户根据网站设计来决定企业的信誉。用户只需0.5秒就可以形成对网站的看法。从那时起，技术介入网络开发的世界是至关重要的。在这里，人工智能进入了2023年的网络发展趋势。

 

将人工智能应用于网络开发可以帮助您预测客户的选择，从而塑造网站的整体外观。AI让你知道，

• 你的客户下一步打算买什么？
• 客户决定购买产品的理想时间范围。
• 什么样的产品最吸引顾客？
• 哪些产品不受客户欢迎？
• 谁都有兴趣购买你们的产品？

我们生活在一个数字时代，众所周知，即将到来的时代将在各个领域采用更智能的方法。这意味着更少的手动操作。例如聊天机器人、增强现实/虚拟现实。说到这里，许多初创企业、中小企业和大型组织已经在寻求为其业务雇佣人工智能开发人员，以通过人工智能应用程序、软件和工具满足最终用户的未来需求。

Sketch2Code是一种基于web的解决方案，最近推出。它依靠人工智能将手写UI设计从图像转换为有效的HTML标记代码。

许多用户甚至对人工智能在某种程度上参与大多数网站并不感到惊讶。它在网络开发领域创造了一个新的维度。

4. WebAssembly

在开发web应用程序时，首先不能忽视的是性能。现在，JavaScript的限制使繁重的计算变得缓慢。这大大恶化了用户体验。

这是WebAssembly日益流行的主要原因之一。有了这项技术，任何编程语言中的代码都可以编译成在浏览器中运行的字节码。

WebAssembly是一个开放标准，它为可执行程序定义了一种可移植的二进制代码格式，以及相应的文本汇编语言，以及用于促进此类程序与其宿主环境之间交互的接口。

优点：

• 它独立于编程语言和平台
• 独立于硬件
• 快速执行代码
• 提供高级别的安全性。

这一切都归结为三角关系——占地面积小、跨平台脚本和速度。这三个组件都是现代web开发中的关键组件。这就是为什么今天大部分的web开发案例都没有WebAssembly的原因。

For more info check Webassembly concepts

5. 语音搜索和导航

Credit Giphy

嘿Siri…。今天的趋势是什么？

我们人类一天比一天懒…不是吗。。！！？😂 首先，我们制造了手机，然后开发了智能手机来减少体力劳动，现在我们正朝着“语音免提”的方向发展。面向命令的服务是当今的热门话题。

语音搜索和导航将成为2023年最主要的网络发展趋势之一。它们已经成为我们日常生活的一部分。它们非常棒，因为它们让我们搜索信息、做笔记等等的方式变得很简单。

苹果、安卓和谷歌等品牌在其用户界面/用户体验设计过程中实现了这一趋势。因此，这种迅速出现的趋势不容忽视…！！

谷歌报告称，全球27%的在线人口在手机上使用语音搜索。

Voicebot.ai报告称，超过一半的成年人使用过语音搜索，2019年初，33%的人每月使用语音搜索，高于2018年的25%。

通过在web开发中实现语音搜索和导航，您可以确保您的服务提供令人惊叹的用户体验。

• 语音用户界面根据以下算法工作：
• 语音识别软件将输入的模拟波转换为数字格式
• 音频输入被分解为单独的声音、音素
• 该软件分析每一个单词，并将它们与字典中的单词进行比较
• 语音转换为屏幕文本或计算机命令

优点：

• 易用性
• 允许徒手交互
• 任务执行速度快
• 出色的用户体验
• 直观方便

人们喜欢花更少的时间键入命令。这就是他们越来越多地使用语音搜索的原因。因此，网络开发将与此类功能的实现密切相关。

6. 本地应用程序将主导市场

如果你正在工作，突然出现网络问题怎么办。。！！一直依赖互联网有点烦人。这就是Native应用程序的用武之地。它还允许您离线工作。

原生移动应用程序是直接安装在智能手机上的应用程序，在大多数情况下，根据应用程序的性质，它可以在没有互联网连接的情况下工作。

好吧，原生应用程序开发已经很有需求了，未来，软件开发人员可以预计这一趋势将主导2023年的网络开发趋势。

由于它们是为特定平台专门设计的，与混合应用程序相比，它们通常提供更好的用户体验和更强大的性能。这就是为什么，越来越多的企业正在投资于iOS和Android的多个本地应用程序，以使他们能够为用户提供更好的体验。

优点：

• 由于使用了底层设备的功能，因此具有广泛的功能
• 更好地与操作系统的用户体验相匹配的UI
• 响应迅速
• 提醒推送
• 通过应用商店中的评级进行质量保证。

随着智能手机在市场上越来越受欢迎，iOS和Android操作系统在市场上的主导地位越来越大，对本地应用程序开发的投资似乎不会很快减少，事实上，在2023年或可预见的未来都不会减少。

7. Motion design UI

Credit: Vuexy By Anand Patel on Dribbble

运动设计是2023年网页设计和网页发展的主要趋势之一。极简主义的设计加上复杂的互动，给人一种引人入胜的互动外观，吸引了用户的注意力。

顾名思义，动作设计就是设计动作。然而，它远远超出了在构思后简单地为屏幕元素设置动画的范围。

必须在UI/UX设计阶段就已经考虑到动作设计。这背后的原因是，仅仅拥有一个包含动画的屏幕就有点达不到预期目标：添加的动作必须有意义和目的。

由于运动设计，这些元素将被实现：

• 页眉转换；
• 图表
• 弹出窗口
• 下拉菜单
• 滚动

所有这些都将帮助你展示你的独特风格，娱乐用户，改善行为因素，并帮助你的网络应用程序在搜索结果中排名更高。

在AMP的帮助下，可以在不损失下载速度的情况下实现动作设计。因此，如果你想让用户停留在你的页面上，那么不要忽略这个…！！

优点：

• 定义你的结构和互动
• 简化导航
• 减缓加载时间
• 增加会话长度，从而降低反弹率
• 为了提高参与度并为网络应用程序的用户提供更好的UI/UX，请尝试使用动作UI技术进行升级。

通过动画引导用户浏览您的应用程序，演示下一步要采取的步骤；

通过朗朗上口的动画对用户的手势做出反应；

演示应用程序不同组件之间的关系等。

8. 无服务器架构

Credit: Runcloud

运动设计是2023年网页设计和网页发展的主要趋势之一。极简主义的设计加上复杂的互动，给人一种引人入胜的互动外观，吸引了用户的注意力。

顾名思义，动作设计就是设计动作。然而，它远远超出了在构思后简单地为屏幕元素设置动画的范围。

必须在UI/UX设计阶段就已经考虑到动作设计。这背后的原因是，仅仅拥有一个包含动画的屏幕就有点达不到预期目标：添加的动作必须有意义和目的。

由于运动设计，这些元素将被实现：

• 页眉转换；
• 图表
• 弹出窗口
• 下拉菜单
• 滚动

所有这些都将帮助你展示你的独特风格，娱乐用户，改善行为因素，并帮助你的网络应用程序在搜索结果中排名更高。

在AMP的帮助下，可以在不损失下载速度的情况下实现动作设计。因此，如果你想让用户停留在你的页面上，那么不要忽略这个…！！

优点：

• 定义你的结构和互动
• 简化导航
• 减缓加载时间
• 增加会话长度，从而降低反弹率

为了提高参与度并为网络应用程序的用户提供更好的UI/UX，请尝试使用动作UI技术进行升级。

• 通过动画引导用户浏览您的应用程序，演示下一步要采取的步骤；
• 通过朗朗上口的动画对用户的手势做出反应；
• 演示应用程序不同组件之间的关系等。

9. 持续集成和部署

Credit: By Stories on Freepik

我们生活在一个数字时代，在这个时代，速度和连续性在任何行业和业务中都扮演着残酷的角色，网络开发世界也不例外。事实上，在网络开发的世界里，提供快速、流畅和更新的服务是最重要的。

定期修复、更新、改进UI/UX等错误的频率使您的web服务负责任，成为用户的最爱。此外，大多数现代应用程序都需要在不同的平台和工具中开发代码，团队需要一种机制来集成和验证其更改。它会影响您的整体业务。因此，持续集成和部署在网络世界中至关重要。🧐

好吧，持续集成是指尽早自动测试对代码库所做的每一项更改的过程。Continuous Deployment遵循Continuous Integration过程中发生的测试，并将更改推送到暂存或生产系统。而持续交付意味着应用程序进入生产环境进行彻底测试，并且持续部署会自动更新它们。

优点：

• 较小的代码更改更简单（更原子化）
• 故障隔离更简单、更快。
• 产品通过快速功能介绍快速改进
• 平均解决时间（MTTR）更短，因为代码更改更小，故障隔离更快。
• 可测试性由于较小的、特定的更改而提高。这些较小的变化允许更准确的阳性和阴性检测。
• 检测和纠正生产逃逸所花费的时间更短，发布速度更快。

有了这样的优势，难怪会有更多的软件开发公司在他们的工作中采用这种方法。因为它是网络开发世界中最关键的方面。

10. 云技术将继续存在

Created by Taras Ivanytskyi on dribbble

你知道吗，2020年，云服务行业创造了近400亿美元的收入，使其市值从2019年的2278亿美元增至2664亿美元，在短短一年内增长了17%？

有了这些数字，有一点是肯定的；在web开发服务中，云技术是王者。2023年，由于云技术，预计谷歌、微软和亚马逊等云供应商将继续赚得盆满钵满。

这一热门趋势背后的原因是，云上有几家公司，预计还会有更多的公司搬到那里。从小型创业公司或跨国公司，到多个行业的企业，从医疗保健到情报机构，甚至政府组织，各种规模的企业都将转向数据存储的云提供商。

Credit: Cloudopedia

Following are some cloud services.

• AWS Lambda
• Google Cloud Functions
• Azure Functions
• IBM OpenWhisk
• Alibaba Function Compute
• Iron Functions
• Auth0 Webtask
• Oracle Fn Project
• Kubeless

云技术在数据存储方面提供了强大的安全性、可扩展性和灵活性，考虑到可能导致安全漏洞的黑客威胁一直存在，组织将希望确保采取可衡量的措施来保护其敏感数据，避免数据泄露和其他可能损害数据隐私的活动。

11. 5G技术将无与伦比

Credit: Rpc senate

5G是第五代蜂窝网络，它带来了新的功能，将为人们、企业和社会创造机会。即使在网络开发领域，5G也占据主导地位。由于需要增强服务，因此必须加快连接速度。

2023年，软件开发商可以预计5G技术将作为一种趋势回归，但这一次的理由是正确的。随着新射频的使用和速度达到100 Gbps，5G技术的速度大约是4G网络的100倍，软件开发行业的专家预测，未来五年，它将引领全球14亿台设备的标准数据传输。

优点：

• 变速箱速度更高
• 减少延迟
• 连接的设备数量更多
• 网络切片
• 增强的容量
• 可用性和覆盖范围

Credit: By Kate mangostar on Freepik

5G技术是为增强现实、虚拟现实和4K视频流等计算密集型应用程序设计的。对创建能够提高业务性能的设计和功能感兴趣的软件开发人员会发现这项技术特别有用。

随着更好的数据传输和更快的网络的承诺，5G技术无疑是2023年最佳网络发展趋势之一的有力竞争者。

12. Mixed Reality (MR)

As per the report,

AR/VR市场（即混合现实）将从2017年的10.54亿美元增长到2024年的99.82亿美元，2018-2023年的复合年增长率将达到73.2%。

混合现实（MR）是增强现实（AR）和虚拟现实（VR）的结合。它在企业应用程序中发挥着关键作用。AR将数字内容与用户的物理环境相结合，而VR则为用户创造了身临其境的体验。

在这项技术的帮助下，Web应用程序开发、国防、旅游、建筑、建筑、游戏、医疗保健等许多领域的组织正在实现关键的商业价值。

MR如何扭转局面：

• 企业、政府组织，甚至非营利组织都可以使用AR和VR来培训员工从事复杂的工作。
• 在物理环境上实时覆盖数字信息的能力为增强现实在商业中创造了许多可能性。
• 媒体和娱乐企业正在以一种重要的方式使用AR和VR，为消费者提供引人入胜的内容。
• 企业可以使用AR和VR让潜在客户虚拟地“试用”他们的产品，这增加了他们的销售努力。

MR在网站上的体验将在未来几年不断增加。想想宜家这样的家具网站，展示你房间里的家具。。！！

13. Blockchain: 增强企业解决方案的透明度、效率和安全性

比特币问世时有点革命性…！！它在某种程度上震撼了市场，也为网络开发世界打开了一扇新的大门。Cision PR Newswire的一份报告估计，2025年区块链技术市场将达到576.41亿美元，2019年至2025年的复合年增长率将达到69.4%。

比特币和以太币等加密货币让我们注意到了区块链，这项技术对企业系统有着广泛的影响。基本上，区块链是一个对等（P2P）网络，它提供去中心化、分布式账本、透明和安全功能。

在区块链网络上运行的智能合约是不可篡改和透明的，因此，它们是安全和值得信赖的。此外，它们的执行是不可逆转的，这使得合同管理更容易。

优点：

• 权力下放
• 不可变性
• 安全
• 透明度
• 保护物联网（IoT）

Check “Benefits of blockchain for identity management” for more information

几个区块链用例示例：

• 改善供应链管理
• 身份管理：区块链可以通过其防篡改数据和分布式账本来改进“身份和访问管理”（IAM）流程。
• 更好的分析：区块链提供了不变性和审计跟踪，从而确保了正确的数据质量。这可以帮助所有行业的企业，因为他们可以根据可靠的数据运行分析工具。
• 去中心化颠覆：以太坊和NEO等区块链平台使企业家能够构建“去中心化应用程序”（DApp），因此，他们可以颠覆现有的中心化商业模式。
• 保护物联网（IoT）：物联网具有巨大的潜力，因为它可以从数十亿个传感器和设备中获得见解。尽管如此，物联网仍面临风险，因为设备之间的整个通信都是通过互联网进行的。区块链可以通过其强大的安全功能来保护这种通信。

14. IoT: 物联网

Credit: By vectorpouch on Freepik

根据研究，“到2020年，将有超过200亿台物联网设备活跃并连接到互联网”。真是令人印象深刻…！！😎

我们希望一切都更智能。无论是智能手机还是灯泡。。！！你看，对智能设备的需求与日俱增，而且不会停止。而且，多亏了互联网，智能生活正在成为现实。你所要做的就是命令…！！是的，这就是我们喜欢的东西。😁

嗯，没有互联网的生活是不可能想象的，因为现在世界的每一个方面都被连接起来，使一切变得方便、简单和智能。因此，为了让世界更加互联，物联网的出现是一件幸事。

物联网是指能够与其他设备和网络通信的广泛的互联网连接设备。它们可以执行各种功能，但最常用于收集信息和执行特定操作。你会惊讶地发现，每秒钟都有127台设备连接到互联网。

优点：

• 改进监控
• 预测和行动的新能力
• 增加客户对话
• 微调服务和产品
• 改进对操作过程的控制

如今，互联网让生活变得更加轻松，但也让世界变得越来越小。由于不断增强的功能，互联网现在已经成为我们丰富生活的系统和日常生活的一部分。

Iot肯定会在很长一段时间内统治网络开发世界…！！

15. MEAN-React-Vue-Flutter

如果没有一定的技术堆栈，上面列出的大多数趋势都无法实现。但现在有数百个框架和库。它们中的哪一个最常使用？

MEAN是一个免费的开源JavaScript软件栈，用于构建动态网站和web应用程序。由于MEAN堆栈支持程序的所有组件都是用JavaScript编写的，因此MEAN应用程序可以用一种语言编写，用于服务器端和客户端执行环境

MEAN堆栈是最受欢迎的堆栈之一。它包括：

• MongoDB——一个数据库
• React.js——一个web框架
• Vue.js——一个前端框架
• Angular——一个前端框架

• Flutter for web

React库起着重要作用。它经常被用作MEAN堆栈中Angular的替代品。它能够更快、更容易地实现更改，因此越来越多的开发人员选择它而不是Angular。

• React是一个开源的前端JavaScript库，用于构建用户界面或UI组件。它由Facebook和一个由个人开发者和公司组成的社区维护。

您可以查看Sneat MUI React NextJS管理模板和Vuexy React管理模板。这些是最好的React管理模板，用于构建强大而令人敬畏的web应用程序。

您可以查看ReactJS开发人员路线图，了解如何使用ReactJS的详细概述。除此之外，还有一篇关于最佳ReactJS UI框架和组件库的文章会很有帮助。

在小米和阿里巴巴等巨头转向Vue后，Vue已经在全球市场上站稳了脚跟。这是一个非常紧凑的前端解决方案。

您可以查看使用VueJS制作的Materio Vuetify VueJS管理模板。

• Vue.js是一个开源的模型-视图-视图模型前端JavaScript框架，用于构建用户界面和单页应用程序。

此外，还有一篇关于Trending VueJS UI组件库和框架的详细文章，您会发现这些文章很有用。

• Angular是一个基于TypeScript的开源web应用程序框架，由谷歌的Angular团队以及个人和企业社区领导。

为了获得更好的外观，请查看使用Angular制作的Apex Angular Admin Template

最后一个流行的解决方案是Flutter for Web。Flutter是一个开源的用户界面软件开发工具包，由谷歌创建。它用于从单个代码库为Android、iOS、Linux、Mac、Windows、Google Fuchsia和web开发应用程序。它有助于在任何设备上提供高质量的网络应用程序，因此在网络开发人员的评分中名列前茅。

16. API-First Development

Credit: Freepik

API-first方法意味着对于任何给定的开发项目，您的API都被视为“一流公民”。它满足用户的需求。使用这种方法，开发人员可以在用户访问网站时同时执行任务和推送代码。

它还降低了开发费用并提高了交付速度。此外，这种方法还允许新网站成为内容传递源。这种互连性允许开发人员将外部产品添加到他们的应用程序中，以帮助增强他们的功能和性能。

新的物联网设备、软件工具和网络接口都包含API，允许它们相互连接，并为用户提供无缝的数字体验。

以前，许多开发人员可能首先关注该产品，然后将其需要连接到其他设备的事实视为事后考虑。现在，API成为焦点，并成为公司寻找增加与用户互连性的方法的中心。

优点：

• 开发团队可以并行工作
• 更快的上市时间
• 降低开发应用程序的成本
• 良好的客户体验
• 降低故障风险

17. Accelerated Mobile Pages (AMP)

AMP类似于PWA，是web开发中的新兴技术之一。随着互联网越来越以用户为中心，这是一种新的网络发展趋势。因此，许多品牌选择创建本地应用程序来改善用户体验。此外，AMP插件还可以帮助企业节省用户体验费用并接触目标用户。

AMP背后的目的是为用户提供无缝的页面体验，让他们沉迷于网站。不同的功能是谷歌和推特最近开发的开源插件。

AMP是经过优化的页面，可快速加载和操作。此外，它们有一个方便但基本的设计，不同于全范围的网络产品。页面变得便于移动，并增加了内容的可读性。AMP等插件允许不同网速的用户访问页面，并使互联网更加用户友好。

它使公司能够节省用户体验的成本，同时提高其可达性。此外，以下是AMP带来的一些优势。

优点：

• 提高网站参与度
• 提高排名和流量
• 较低的反弹率
• 增加了广告浏览量
• 点击率更高

18. Dark mode:

 

Credit: Materio Vuetify VueJS Admin Template

嗯，暗模式、夜班和其他弱光用户界面选项是一种趋势，主要是因为它们为用户提供了一个低对比度的网站或应用程序，在弱光环境中更容易查看。

此外，黑色是一种特别强烈的颜色，它会打击人们的强烈情绪，如果使用过量，很容易压倒个人。当您想要突出显示特定类型的内容时，暗模式特别有用。

此外，Spotify、Netflix和Steam都是在黑暗模式下设计的。与此同时，谷歌开始提供暗模式，Instagram、Twitter、苹果和安卓是提供暗模式的一些最受欢迎的应用程序和服务。

根据安卓管理局的评估，81.9%的受访者接受在设备上使用暗模式，9.9%的受访者在亮模式和暗模式之间切换。Polar的另一项调查显示，95%的用户喜欢使用暗模式而不是亮模式。

这一趋势的主要原因如下：

• 它给人一种超现代、酷炫的外观
• 它节省了设备电池电量（在OLED/AMOLED屏幕的情况下）
• 它允许弹出和突出显示其他设计元素
• 它可以减少弱光条件下的眼睛疲劳。

尽管如此，我们不应该忽视这样一个事实：任何过量的东西都是有害的。所以，小心使用它…！！

19. Cybersecurity

这是2023年以及未来最重要的趋势之一。随着新兴技术和对技术的依赖，网络安全威胁的风险正在增加。2020年10月，黑客用恶意软件攻击了德国第二大软件供应商software AG，要求赔偿近2000万美元。

根据Cloudflare的数据，2020年分布式拒绝服务（DDoS）攻击的数量每个季度都翻了一番。在DDoS攻击中，黑客会用大量恶意互联网流量淹没目标服务器。这可能会导致数小时的停机时间，也可能导致收入损失。

客户已经认识到这一新出现的威胁，并希望公司采取强有力的安全措施，确保其个人信息的安全。这就是为什么，保护您的公司和客户信息将是2023年的优先事项，尤其是在网络攻击持续增加的时候。

以下是您可以采取的一些步骤：

• 进行脆弱性评估
• 保护您的远程访问
• 引入角色、权限和多因素身份验证

20. Push Notifications

推送通知是由移动应用程序发送到用户设备的小型弹出消息，即使在应用程序未打开时也会出现。这些通知旨在吸引注意力，并可以传达提醒、更新、促销等信息。

它们可以提供实时更新，或通过必要的细节和推送通知来吸引用户的注意力，例如提醒用户重新访问最近查看的项目或新的博客文章。

推送通知是与受众沟通的好方法。根据Localytics的一项研究，52%的智能手机用户在他们的设备上启用了推送功能，这些通知可以通过以下方式为企业带来好处：

• 引导用户访问您的社交媒体渠道
• 推广产品和服务（特别是特惠）
• 通过提供有价值的内容建立信任和品牌声誉
• 吸引当前不在您网站上的用户
• 恢复电子商务应用程序的废弃购物车

以下应用程序使用此技术来提高销售额：

• Myntra
• Amazon
• The Bump
• La Redoute
• Ticketmaster

21. No-Code/Low-Code Apps

无代码/低代码的平台使web开发更加容易。这些工具使用户能够利用预先制作的代码块和管理模板创建软件解决方案。

简言之，它们是可视化的软件开发环境，使开发人员能够拖放软件组件，连接它们，并创建移动或web应用程序。这些平台经常与它们所代表的开发方法互换使用。

因此，它减少了编码所需的时间和精力。此外，无论技术经验如何，任何人都可以开发软件和高需求应用程序。这些工具还使公民开发人员更容易构建有用的应用程序，而无需编写复杂的代码。

以下是您可以使用的一些无代码开发工具。

• Webflow
• Bubble.io
• Previewed
• Shopify
• NoCodeAPI

For more such, No code tools refer to the collection: Best No Code Development Tools

22. Personalization

根据访问者的需求和特点，不同版本的网页会显示给不同的访问者。可以对登录页进行个性化设置，以共享专为特定访问者量身定制的信息。事实上，客户渴望个性化。这就是让他们保持投入和忠诚的原因…！！

因此，个性化正在为2023年的网络开发设定基准。您可以通过多种交互方式向您的网站访问者提供个性化权限。例如，您可以允许用户手动或通过他们的反馈设置他们的首选项。除此之外，你还可以授权他们根据他们的意愿更改你的网站外观，这样他们会感觉更紧密。

机器学习的内容个性化，也称为预测性内容个性化，是一种先进的人工智能驱动方法，可以向每个用户动态显示最相关的内容。

23. CRM Integration

客户关系管理（CRM）系统帮助企业管理与当前和潜在客户的关系和互动。在其潜力中，许多企业没有将其纳入其网络解决方案，从而错过了好处。

通过连接您的网站和CRM，您将能够增强客户体验。通过这种方式，您将能够在客户消费旅程的每个阶段为其提供帮助。此外，您将通过消除手动复制和粘贴或导出和导入的需要来节省管理费用。这会提高你的工作效率，让你的日程安排更加专注于其他目标。

以下是提供CRM集成的一些服务和应用程序：

• Zoho CRM
• Sneat MUI React Admin Template
• Freshsales
• Pipedrive

24. AI & Machine Learning

几年来，人工智能一直在渗透我们的数字生活，但随着越来越多的公司投资于技术，我们可以期待在可能的方面取得重大进展。特别是自然语言处理（NLP）和机器学习（ML）已经从理论概念发展到了成熟的应用。

例如，“YouTube使用NLP从视频音频中自动创建字幕，或者谷歌分析使用ML更好地了解网站用户的行为，或者Alexa使用VR和ML，这样我们就可以与机器进行完整的对话。”

机器学习（ML）用于网络开发，为用户提供改进的体验。开发人员使用ML使软件能够分析传入数据、检测模式和个性化内容。许多领先的公司都使用这项技术来增强用户体验。例如，Airbnb和Netflix使用ML为用户定制搜索结果。

结论

好吧，正如这里谈到的2023年的网络发展趋势一样，很难追逐它们，因为它们变化如此之快。但是，我们必须控制住它们，并尝试它们。。！！

通过跟踪网络开发的最新趋势，您可以用世界级的用户体验来安抚用户，提高您的网络应用排名，并为您的服务打开新市场…！！

通过使用这些趋势，您将能够为您的网络应用程序的用户提供令人惊叹的体验。此外，你将增加成为他们首选的机会！

一般来说，每一个网络发展趋势都值得你关注。其中一些可能会持续到未来十年，例如物联网、语音机器人、MR、ETC。而其中一些将在几个月内成为常态。

所以，不要犹豫，尽快在下一个项目中开始实施它们。

一定要告诉我们你最喜欢的一个，如果我们在这里错过了，我们很乐意听到。发展快乐。🤩

GraphQL的真正威力…从客户端请求一直到数据库指定所请求的字段。

问题

GraphQL最强大的特性之一是客户端可以指定从响应返回的字段，从而减少通过网络传输的数据，从而避免过度获取数据。

然而，我们真的做了更少的工作吗?后端服务器和数据库仍然必须执行查询数据库的所有工作，获取被请求对象的所有字段，然后仅通过GraphQL/Network层返回被请求的字段。

因此，通过发送较小的响应大小，我们只是节省了网络时间，但我们的后端服务器和数据库仍然在做额外的不必要的工作，以获取所请求对象的所有字段。这基本上是浪费了很多时间，我们可以优化。

解决方案

如果有一种方法可以确定客户机请求哪些字段，并且只从数据库层返回这些字段，那该怎么办?

大多数现代数据库都提供了“投影”或“选择”特性，其中数据库驱动程序允许使用者指定应该从与数据库查询匹配的文档中返回哪些字段，以避免返回所有不必要的字段，并加快对数据库的查询。

这对数据库查询性能有相当大的影响，因为它避免了不必要的工作，如果您想知道潜在的节省是什么样子的，可以看看我之前写的这篇文章，它展示了在MongoDB中使用/不使用投影的一些性能指标。

Apollo-Server解析器函数

因此，我们可以从网络层和数据库层实现这一点，唯一缺少的是在我们的服务器/解析器中解决它。

用apollo-server编写的graphQL解析器函数通常接受四个输入参数。根，args，上下文和信息。如果我们要写一个解析器，返回所有用户从数据库举例，它会像这样:

resolvers = {
  getUsers: function (root, args, context, info) {
    const User = mongoose.model('User')
    return User.find({})
  }
}

根对象通常是Schema中请求的操作/字段的父对象。args是可以传递给该操作的任何参数，而上下文包括传递到上下文对象的任何参数(通常用于身份验证)。但是info对象呢?它似乎包括一些关于传入请求的信息。

所以我在apollographql.com上查阅了它的文档，这是我找到的

Info:这个参数只应该在高级情况下使用，但是它包含关于查询执行状态的信息，包括字段名、从根到字段的路径等等。它只在GraphQL.js源代码中有文档说明。

不是很有用，但我认为它可能包含有关传入请求和请求字段的必要信息，在查看了可能能够执行我想要的操作的在线库之后，我发现了graphql-fields。

graphql-fields

我遇到了graphql-fields，它可以根据info参数返回被请求的字段，它还可以处理高级情况，如联合类型、片段、子字段( union types, fragments, sub-fields)等。

下面是它所能做的，对于这样一个返回所有用户姓名和电子邮件的查询

{

  users {

    name

    email

  }

}

结果就是:[' name '， ' email ']

用法:

const graphqlFields = require(‘graphql-fields’);

function userResolver(root, args, context, info) {

  const topLevelFields = Object.keys(graphqlFields(info));

  console.log(topLevelFields)

  // prints [‘name’, ‘email’]

}

很好，现在我们可以使用这个结果从数据库中只选择这些字段，而不是为每个用户从数据库中请求整个用户文档。

 

使用结果

在我的例子中，我使用MongoDB和Mongoose作为数据库驱动程序，所以Mongoose投影所需的语法与我从graphql-fields得到的结果有一点不同。

我想实现的等价查询如下所示:

User.find({}).select({name: 1, email: 1}).lean()

将来自graphql-fields的结果转换为猫鼬需要的选择对象的helper函数如下:

export function getMongooseSelectionFromSelectedFields (info, fieldPath = null) {

  const selections = graphqlFields(info)

  const mongooseSelection = Object

  .keys(fieldPath ? selections[fieldPath] : selections)

  .reduce((a, b) => ({ …a, [b]: 1   }), {})

  return mongooseSelection

}

好了，现在客户端请求的字段就是数据库请求和返回的字段，这使我们的解析器更快了!

这在自动持久化查询(APQ)和缓存中完美地工作。另外两个表现容易获胜。

我添加了一个fieldPath参数来支持响应中的一层嵌套，以防从数据库请求数据的操作不是顶层操作。

这是新的解析器的样子:

resolvers = {

  getUsers: function (root, args, context, info) {

    const mongooseSelection = getMongooseSelectionFromRequest(info)

    return User.find({}).select(mongooseSelection).lean()

  }

}

结论

GraphQL是相当强大的，它不仅优化性能的客户端应用，但也可以用于优化后端性能，毕竟我们得到的特定请求字段在我们的解析器免费。

 

原文：https://itnext.io/graphql-performance-tip-database-projection-82795e434b44

本文：http://jiagoushi.pro/node/1176

讨论：请加入知识星球【首席架构师智库】或者小号【jiagoushi_pro】

 

由HyBi工作组开发的WebSocket有线协议(RFC 6455)由两个高级组件组成:用于协商连接参数的开放HTTP握手和二进制消息帧机制，以实现低开销、基于消息的文本和二进制数据传输。

WebSocket协议试图在现有HTTP基础架构的上下文中解决现有双向HTTP技术的目标;因此，它被设计为在HTTP端口80和443上工作……然而，这种设计并没有将WebSocket限制为HTTP，而且未来的实现可以在专用端口上使用更简单的握手，而无需重新发明整个协议。

                                                                          ----WebSocket协议RFC 6455

WebSocket协议是一个功能完整的独立协议，可以在浏览器之外使用。尽管如此，它的主要应用程序是作为基于浏览器的应用程序的双向传输。

二进制框架层

客户端和服务器端WebSocket应用程序通过一个面向消息的API进行通信:发送方提供一个任意的UTF-8或二进制有效负载，当整个消息可用时，接收方被通知它的传递。为了实现这一点，WebSocket使用了自定义的二进制帧格式(图17-1)，它将每个应用程序消息分解成一个或多个帧，将它们传输到目的地，重新组装它们，并在收到整个消息后通知接收者。

Figure 17-1. WebSocket frame: 2–14 bytes + payload

Frame

通信的最小单位，每个单位包含一个可变长度的帧头和一个可携带全部或部分应用程序消息的有效负载。

Message

映射到逻辑应用程序消息的完整帧序列。

决定将应用程序消息分割成多个框架是由客户机和服务器框架代码的底层实现做出的。因此，应用程序仍然很高兴地不知道各个WebSocket帧或者帧是如何执行的。话虽如此，理解每个WebSocket帧在连线上是如何表示的要点仍然是有用的:

• 每个帧(FIN)的第一个比特表示该帧是否为消息的最后一个片段。一条消息可能只包含一帧。
• 操作码(4位)表示传输帧的类型:用于传输应用程序数据的文本(1)或二进制(2)或用于连接活性检查的控制帧，如连接关闭(8)、ping(9)和pong(10)。
• 掩码位指示负载是否被掩码(仅针对从客户机发送到服务器的消息)。
• 有效载荷长度用可变长度字段表示:
  • 如果0-125，那么这就是有效载荷长度。
  • 如果是126，那么下面的两个字节表示一个16位无符号整数，表示帧长度。
  • 如果是127，那么下面的8个字节表示一个64位无符号整数，表示帧长度。
• 屏蔽键包含一个用于屏蔽有效负载的32位值。
• 有效负载包含应用程序数据和自定义扩展数据(如果客户端和服务器在建立连接时协商了扩展)。

所有客户端发起的帧的有效负载都使用帧头中指定的值来隐藏:这可以防止恶意脚本在客户端执行缓存中毒攻击，攻击那些可能不理解WebSocket协议的中介。有关这次攻击的详细信息，请参考2011年W2SP上的 "Talking to Yourself for Fun and Profit"。

因此，每个服务器发送的WebSocket帧都会产生2-10字节的帧开销。客户端还必须发送一个屏蔽密钥，这将在头文件中增加额外的4个字节，导致开销增加6-14个字节。没有其他元数据可用，例如头字段或关于有效负载的其他信息:所有WebSocket通信都是通过交换帧来执行的，这些帧将有效负载视为应用程序数据的不透明blob。

WebSocket多路复用和堆头阻塞( Head-of-Line Blocking)

WebSocket易受行头阻塞的影响:消息可以被分割成一个或多个帧，但是来自不同消息的帧不能交叉，因为在HTTP/2帧机制中没有等效的“流ID”;参见流、消息和帧)。

因此，一个大消息，即使被分割成多个WebSocket帧，也会阻止与其他消息相关联的帧的传递。如果您的应用程序交付的是对延迟敏感的数据，请注意每个消息的有效负载大小，并考虑将大消息拆分为多个应用程序消息!

核心WebSocket规范中缺乏多路复用也意味着每个WebSocket连接都需要一个专用的TCP连接，这可能成为HTTP/1的一个潜在问题。由于浏览器维护的每个源的连接数量有限而进行的部署;请参阅耗尽客户机和服务器资源。

从好的方面来看，由HyBi工作组开发的“WebSockets多路复用扩展”解决了后一个限制:

有了这个扩展，一个TCP连接可以通过封装带有通道ID标签的帧来提供多个虚拟WebSocket连接……这个多路复用扩展维护独立的逻辑通道，每个逻辑通道提供独立WebSocket连接的完全等价逻辑，包括单独的握手头。

                                                          --------------WebSocket多路复用(草案10)

有了这个扩展，多个WebSocket连接(通道)可以在同一个TCP连接上多路复用。然而，每个单独的通道仍然很容易被线头阻塞!因此，一种可能的解决方案是使用不同的通道或专用的TCP连接并行地多路传输多个消息。

最后，注意前面的扩展仅对HTTP/1是必要的。x连接。虽然目前还没有官方规范可以使用HTTP/2传输WebSocket帧，但是这样做会容易得多:HTTP/2有内置的流多路复用，通过在HTTP/2帧机制中封装WebSocket帧，可以在一个会话中传输多个WebSocket连接。

协议的扩展

WebSocket规范允许协议扩展:WebSocket协议的有线格式和语义可以通过新的操作码和数据字段进行扩展。虽然有些不寻常，但这是一个非常强大的特性，因为它允许客户端和服务器在基本的WebSocket框架层之上实现额外的功能，而不需要任何来自应用程序代码的干预或合作。

有一些WebSocket协议扩展的例子吗?负责WebSocket规范开发的HyBi工作组列出了两个正在开发中的官方扩展:

“WebSockets的多路复用扩展”

这个扩展为单独的逻辑WebSocket连接提供了一种共享底层传输连接的方法。

“WebSocket的压缩扩展”

一个用于创建WebSocket扩展的框架，为WebSocket协议添加压缩功能。

 

如前所述，每个WebSocket连接都需要一个专用的TCP连接，这是低效的。多路复用扩展通过为每个WebSocket帧增加一个额外的“通道ID”来允许多个虚拟的WebSocket通道共享一个TCP连接来解决这个问题。

类似地，基本的WebSocket规范没有为传输数据的压缩提供任何机制或规定:每一帧都携带由应用程序提供的有效负载数据。因此，虽然这对于优化的二进制数据结构来说不是问题，但这可能会导致高字节传输开销，除非应用程序实现了自己的数据压缩和解压缩逻辑。实际上，压缩扩展支持HTTP提供的等效传输编码协商。

要启用一个或多个扩展，客户机必须在初始升级握手时公布它们，服务器必须选择并确认在协商的连接的生命周期中将使用的扩展。作为一个实际的示例，现在让我们仔细看看升级顺序。

WebSocket多路复用和压缩在野外

到2013年中期，WebSocket多路复用还没有被任何流行的浏览器支持。类似地，对压缩的支持也很有限:谷歌Chrome和最新的WebKit浏览器可能会在服务器上发布一个“x-webkit-deflate-frame”扩展。然而，deflate-frame是基于一个过时的修订标准，并将在未来过时。

顾名思义，每帧都是逐帧压缩有效负载内容，这对于可能在多个帧之间分割的大消息不是最优的。因此，压缩扩展的最新版本已经切换到每消息压缩——这是一个好消息。坏消息是每条消息的压缩还处于试验阶段，目前还不能在任何流行的浏览器中使用。

因此，应用程序应该密切关注传输数据的内容类型，并在适用的情况下应用自己的压缩。也就是说，至少要等到本地WebSocket压缩支持在所有流行的浏览器上广泛可用。这对于移动应用程序尤其重要，因为在移动应用程序中，每个不必要的字节都会给用户带来很高的代价。

HTTP升级协商

WebSocket协议提供了很多强大的特性:面向消息的通信、它自己的二进制帧层、子协议协商、可选协议扩展等等。因此，在交换任何消息之前，客户机和服务器必须协商建立连接所需的适当参数。

利用HTTP执行握手提供了几个优点。首先，它使WebSocket与现有的HTTP基础设施兼容:WebSocket服务器可以在端口80和443上运行，这两个端口通常是客户端唯一开放的端口。其次，它允许我们重用和扩展HTTP升级流自定义WebSocket头执行协商:

• Sec-WebSocket-Version
  • 由客户端发送来指示它想要使用的WebSocket协议的版本(对于RFC6455“13”)。如果服务器不支持客户端版本，则必须使用支持版本列表进行响应。
• Sec-WebSocket-Key
  • 客户端发送的自动生成的密钥，它充当服务器的“质询”，以证明服务器支持所请求的协议版本。
• Sec-WebSocket-Accept
  • 包含Sec-WebSocket-Key签名值的服务器响应，证明它理解所请求的协议版本。
• Sec-WebSocket-Protocol
  • 用于协商应用程序子协议:客户端发布支持协议列表;服务器必须使用单个协议名进行应答。
• Sec-WebSocket-Extensions
  • 用于协商用于此连接的WebSocket扩展:客户端声明支持的扩展，服务器通过返回相同的头来确认一个或多个扩展。

有了这些，我们现在就有了执行HTTP升级和协商客户端和服务器之间新的WebSocket连接的所有必要的部分:

GET /socket HTTP/1.1
Host: thirdparty.com
Origin: http://example.com
Connection: Upgrade
Upgrade: websocket 
Sec-WebSocket-Version: 13 
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== 
Sec-WebSocket-Protocol: appProtocol, appProtocol-v2 
Sec-WebSocket-Extensions: x-webkit-deflate-message, x-custom-extension

• 请求执行WebSocket协议升级
• 客户端使用的WebSocket协议版本
• 自动生成密钥来验证服务器协议支持
• 应用程序指定的子协议的可选列表
• 客户端支持的可选协议扩展列表

就像浏览器中任何其他客户端发起的连接一样，WebSocket请求遵循同源策略:浏览器自动在升级握手中附加源头，远程服务器可以使用CORS来接受或拒绝跨源请求;参见跨源资源共享(CORS)。要完成握手，服务器必须返回一个成功的“交换协议”响应，并确认客户端公布的选择:

HTTP/1.1 101 Switching Protocols 
Upgrade: websocket
Connection: Upgrade
Access-Control-Allow-Origin: http://example.com 
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 
Sec-WebSocket-Protocol: appProtocol-v2 
Sec-WebSocket-Extensions: x-custom-extension

• 确认WebSocket升级的响应代码
• CORS头指示选择进入跨源连接
• 签名键值证明协议支持
• 由服务器选择的应用程序子协议
• 由服务器选择的WebSocket扩展的列表

所有RFC6455-compatible WebSocket服务器使用相同的算法来计算客户挑战的答案:Sec-WebSocket-Key的内容与独特的GUID连接字符串中定义的标准,SHA1哈希计算,生成的字符串是base - 64编码,并返回给客户端。

一次成功的WebSocket握手至少必须包含协议版本和客户端发送的自动生成的质询值，以及来自服务器的101 HTTP响应代码(交换协议)和一个哈希的质询-响应来确认所选协议版本:

• 客户端必须发送Sec-WebSocket-Version和Sec-WebSocket-Key。
• 服务器必须通过返回Sec-WebSocket-Accept来确认协议。
• 客户端可以通过Sec-WebSocket-Protocol发送应用程序子协议列表。
• 服务器必须选择一个子协议并通过Sec-WebSocket-Protocol返回。如果服务器不支持任何连接，则连接将中止。
• 客户端可以发送一个协议扩展列表在Sec-WebSocket-Extensions。
• 服务器可以确认一个或多个选定的扩展通过Sec-WebSocket-Extensions。如果没有提供扩展，则连接在不提供扩展的情况下继续运行。

最后，一旦前面的握手完成，如果握手成功，连接现在就可以用作交换WebSocket消息的双向通信通道。从这里开始，客户端和服务器之间不再有其他明确的HTTP通信，由WebSocket协议接管。

代理、中介和WebSockets

在实践中，由于安全和策略的原因，许多用户拥有一组受限的开放端口——具体来说端口80 (HTTP)和端口443 (HTTPS)。因此，WebSocket协商是通过HTTP升级流执行的，以确保与现有网络策略和基础设施的最佳兼容性。

然而,正如我们前面提到的代理中介,TLS,和新协议在网络上,许多现有HTTP中介可能不理解新WebSocket协议,从而导致各种各样的失败案例:盲目连接升级,意想不到的WebSocket帧缓冲,内容修改协议的不了解,误分类的WebSocket信息流作为妥协的HTTP连接,等等。

WebSocket密钥和接受握手解决了一些问题:它是一个安全策略，可以防止服务器和中介在没有真正理解WebSocket协议的情况下盲目地“升级”连接。然而，尽管这种预防措施解决了显式代理的一些部署问题，但它对于“透明代理”是不够的，“透明代理”可以在没有通知的情况下分析和修改网络上的数据。

解决方法?建立一个安全的端到端隧道。,用WSS !通过在执行HTTP升级握手之前协商一个TLS会话，客户机和服务器建立一个加密隧道，从而解决前面列出的所有问题。对于移动客户端来说尤其如此，它的流量经常要通过各种代理服务，而这些代理服务在WebSocket中可能不能很好地发挥作用。

 

原文：https://hpbn.co/websocket/

本文：http://jiagoushi.pro/node/1111

讨论：请加入知识星球【首席架构师智库】或者小号【jiagoushi_pro】

WebSocket支持在客户端和服务器之间双向的、面向消息的文本和二进制数据流。它是浏览器中最接近原始网络套接字的API。除了WebSocket连接也不仅仅是一个网络套接字，因为浏览器在一个简单的API背后抽象了所有的复杂性，并提供了一些额外的服务:

• 连接协商和同源策略的实施
• 与现有HTTP基础设施的互操作性
• 面向消息的通信和有效的消息框架
• 子协议协商和可扩展性

WebSocket是浏览器中最通用、最灵活的传输方式之一。简单和最小的API使我们能够以流方式在客户机和服务器之间分层和交付任意的应用程序协议——从简单的JSON有效负载到定制的二进制消息格式的任何内容——其中任何一方都可以随时发送数据。

但是，定制协议的代价是它们是定制的。应用程序必须考虑到缺少状态管理、压缩、缓存和其他由浏览器提供的服务。设计约束和性能权衡总是存在的，利用WebSocket也不例外。简而言之，WebSocket不是HTTP、XHR或SSE的替代品，为了获得最佳性能，充分利用每种传输的优势至关重要。

WebSocket是由多个标准组成的:WebSocket API由W3C定义，WebSocket协议(RFC 6455)及其扩展由HyBi工作组(IETF)定义。

WebSocket API

浏览器提供的WebSocket API非常小和简单。同样，连接管理和消息处理的所有低级细节都由浏览器处理。为了启动一个新的连接，我们需要一个WebSocket资源的URL和一些应用程序回调:

var ws = new WebSocket('wss://example.com/socket'); 

ws.onerror = function (error) { ... } 
ws.onclose = function () { ... } 

ws.onopen = function () { 
  ws.send("Connection established. Hello server!"); 
}

ws.onmessage = function(msg) { 
  if(msg.data instanceof Blob) { 
    processBlob(msg.data);
  } else {
    processText(msg.data);
  }
}

1. 打开一个新的安全WebSocket连接(wss)
2. 可选回调，在发生连接错误时调用
3. 可选回调，在连接终止时调用
4. 可选回调，在建立WebSocket连接时调用
5. 客户端发起的消息到服务器
6. 为来自服务器的每个新消息调用的回调函数
7. 为接收到的消息调用二进制或文本处理逻辑

API不言自明。实际上，它应该与我们在前一章看到的EventSource API非常相似。这是有意为之，因为WebSocket提供了类似的扩展功能。话虽如此，两者之间也有一些重要的区别。让我们一个一个来看看。

效仿WebSocket

WebSocket协议已经经历了许多修订、实现回滚和安全调查。然而，好消息是RFC6455定义的最新版本(v13)现在被所有现代浏览器支持。唯一值得注意的遗漏是Android浏览器。有关最新状态，请参阅http://caniuse.com/websockets。

类似于SSE的polyfill策略(用定制的JavaScript模拟EventSource)， WebSocket浏览器API可以通过一个可选的JavaScript库来模拟。然而，模拟WebSockets的难点不是API，而是传输!因此，polyfill库及其回退传输(XHR轮询、EventSource、iframe轮询等)的选择将对模拟WebSocket会话的性能产生重大影响。

为了简化跨浏览器的部署，流行的库(如SockJS)在浏览器中提供了类似WebSocket的对象的实现，而且更进一步地提供了一个定制服务器来实现对WebSocket的支持和各种替代传输。定制服务器和客户机的结合能够实现“无缝回退”:性能下降，但应用程序API保持不变。

其他库，比如Socket。除了多传输回退功能外，IO还实现了其他特性，如心跳、超时、支持自动重新连接等。

当考虑一个polyfill 库或“实时框架”，Socket.IO，密切关注客户端和服务器的底层实现和配置:始终利用本地WebSocket接口获得最佳性能，并确保回退传输满足您的性能目标。

WS和WSS URL方案

WebSocket资源URL使用自己的定制方案:ws用于明文通信(例如，ws://example.com/socket)， wss用于需要加密通道(TCP+TLS)。为什么使用自定义模式，而不是熟悉的http?

WebSocket协议的主要用例是在浏览器和服务器上运行的应用程序之间提供一个优化的双向通信通道。然而，WebSocket有线协议可以在浏览器之外使用，并且可以通过非http交换进行协商。因此，HyBi工作组选择采用自定义URL方案。

尽管自定义方案启用了非http协商选项，但在实践中，还没有用于建立WebSocket会话的替代握手机制的现有标准。

接收文本和二进制数据

WebSocket通信由消息和应用程序代码组成，不需要担心缓冲、解析和重构接收到的数据。例如，如果服务器发送了1 MB的有效负载，应用程序的onmessage回调将只在客户机上整个消息可用时被调用。

此外，WebSocket协议对应用程序的有效负载没有任何假设和限制:文本和二进制数据都是公平的。在内部，该协议只跟踪关于消息的两部分信息:作为可变长度字段的有效负载的长度和区分UTF-8和二进制传输的有效负载类型。

当浏览器接收到新消息时，它会自动转换为DOMString对象(用于基于文本的数据)或Blob对象(用于二进制数据)，然后直接传递给应用程序。唯一的另一个选项，作为性能提示和优化客户端，是告诉浏览器转换接收到的二进制数据到ArrayBuffer，而不是Blob:

var ws = new WebSocket('wss://example.com/socket');
ws.binaryType = "arraybuffer"; 

ws.onmessage = function(msg) {
  if(msg.data instanceof ArrayBuffer) {
    processArrayBuffer(msg.data);
  } else {
    processText(msg.data);
  }
}

• 当收到二进制消息时，强制进行ArrayBuffer转换

用户代理可以将此作为如何处理传入的二进制数据的提示:如果属性设置为“blob”，则将其缓冲到磁盘是安全的，如果属性设置为“arraybuffer”，则可能更有效地将数据保存在内存中。自然，用户代理被鼓励使用更微妙的启发式来决定是否将传入数据保存在内存中……

                                                                   WebSocket API, W3C候选推荐

Blob对象表示不变的原始数据的类文件对象。如果您不需要修改数据，也不需要将其分割成更小的块，那么它就是最佳格式——例如。，您可以将整个Blob对象传递给图像标记(请参阅使用XHR下载数据中的示例)。另一方面，如果需要对二进制数据执行额外的处理，那么ArrayBuffer可能更适合。

用JavaScript解码二进制数据

ArrayBuffer是一种通用的、固定长度的二进制数据缓冲区。但是，ArrayBuffer可以用来创建一个或多个ArrayBufferView对象，每个对象可以以特定的格式显示缓冲区的内容。例如，假设我们有以下类似c的二进制数据结构:

struct someStruct {
  char username[16];
  unsigned short id;
  float scores[32];
};

给定这种类型的ArrayBuffer对象，我们可以在同一个缓冲区中创建多个视图，每个视图都有自己的偏移量和数据类型:

var buffer = msg.data;

var usernameView = new Uint8Array(buffer, 0, 16);
var idView = new Uint16Array(buffer, 16, 1);
var scoresView = new Float32Array(buffer, 18, 32);

console.log("ID: " + idView[0] + " username: " + usernameView[0]);
for (var j = 0; j < 32; j++) 
{ 
console.log(scoresView[j]) 
}

每个视图接受父缓冲区、起始字节偏移量和要处理的元素数量——偏移量是根据前面字段的大小计算的。因此，ArrayBuffer和WebSocket为我们的应用程序提供了所有必要的工具来在浏览器中流处理二进制数据。

发送文本和二进制数据

一旦WebSocket连接建立，客户端就可以随意发送和接收UTF-8和二进制消息。WebSocket提供了一个双向通信通道，它允许在相同的TCP连接上双向传递消息:

var ws = new WebSocket('wss://example.com/socket');

ws.onopen = function () {
  socket.send("Hello server!"); 
  socket.send(JSON.stringify({'msg': 'payload'})); 

  var buffer = new ArrayBuffer(128);
  socket.send(buffer); 

  var intview = new Uint32Array(buffer);
  socket.send(intview); 

  var blob = new Blob([buffer]);
  socket.send(blob); 
}

1. 发送UTF-8编码的文本消息
2. 发送一个UTF-8编码的JSON有效负载
3. 将ArrayBuffer内容作为二进制有效负载发送
4. 将ArrayBufferView内容作为二进制有效负载发送
5. 将Blob内容作为二进制有效负载发送

WebSocket API接受一个DOMString对象，该对象在网络上被编码为UTF-8，或者一个用于二进制传输的ArrayBuffer、ArrayBufferView或Blob对象。但是，请注意，后面的二进制选项只是为了API的方便:在网络上，WebSocket框架通过单个位标记为二进制或文本。因此，如果应用程序或服务器需要关于负载的其他内容类型信息，那么它们必须使用额外的机制来通信该数据。

send()方法是异步的:提供的数据由客户机排队，然后函数立即返回。因此，特别是在传输大的有效负载时，不要将快速返回误认为数据已经发送的信号!要监视浏览器排队的数据量，应用程序可以查询套接字上的bufferedAmount属性:

var ws = new WebSocket('wss://example.com/socket');

ws.onopen = function () {
  subscribeToApplicationUpdates(function(evt) { 
    if (ws.bufferedAmount == 0) 
      ws.send(evt.data); 
  });
};

1. 订阅应用程序更新(例如，游戏状态更改)
2. 检查客户机上缓冲的数据量
3. 如果缓冲区为空，则发送下一个更新

前面的示例尝试将应用程序更新发送到服务器，但前提是前面的消息已从客户机的缓冲区中抽取。为什么要费心去做这样的检查呢?所有WebSocket消息都是按照客户端排队的确切顺序传递的。结果，队列消息的大量积压，甚至单个大消息，都将延迟在it后排队的消息的传递——线头阻塞!

为了解决这个问题，应用程序可以将大消息分割成更小的块，仔细监视bufferedAmount值以避免在行头阻塞，甚至为挂起的消息实现自己的优先级队列，而不是盲目地将它们全部排在套接字上。

许多应用程序生成多种类型的消息:高优先级更新，如控制流量;低优先级更新，如后台传输。为了优化传递，应用程序应该密切关注每种类型的消息如何以及何时在套接字上排队!

Subprotocol谈判

WebSocket协议对每个消息的格式不做任何假设:一个位跟踪消息是否包含文本或二进制数据，这样它可以被客户端和服务器有效地解码，但其他消息的内容是不透明的。

此外，与HTTP或XHR请求不同的是，它们通过每个请求和响应的HTTP头来通信额外的元数据，对于WebSocket消息没有这种等效的机制。因此，如果需要关于消息的额外元数据，那么客户端和服务器必须同意实现它们自己的子协议来通信这些数据:

• 客户端和服务器可以预先就固定的消息格式达成一致。，所有通信都将通过json编码的消息或自定义二进制格式完成，必要的消息元数据将成为编码结构的一部分。
• 如果客户机和服务器需要传输不同的数据类型，那么它们可以就一致的消息头达成一致，该消息头可用于通信指令来解码剩余的有效负载。
• 可以使用文本和二进制消息的混合来传递有效负载和元数据信息。时，文本消息可以与等效的HTTP头通信，然后与应用程序有效负载通信二进制消息。

这个列表只是一个可能的策略的小样本。WebSocket消息的灵活性和低开销是以额外的应用逻辑为代价的。但是，消息序列化和元数据管理只是问题的一部分!一旦我们确定了消息的序列化格式，我们如何确保客户机和服务器相互理解，以及如何保持它们同步?

幸运的是，WebSocket提供了一个简单而方便的子协议协商API来解决第二个问题。作为初始连接握手的一部分，客户端可以向服务器发布它支持的协议:

var ws = new WebSocket('wss://example.com/socket',
                       ['appProtocol', 'appProtocol-v2']); 

ws.onopen = function () {
  if (ws.protocol == 'appProtocol-v2') { 
    ...
  } else {
    ...
  }
}

1. 在WebSocket握手期间发布的子协议数组
2. 检查服务器选择的子协议

如前面的示例所示，WebSocket构造函数接受子协议名称的可选数组，它允许客户端发布它理解或愿意为这个连接使用的协议列表。指定的列表被发送到服务器，服务器被允许选择一个由客户机发布的协议。

如果子协议协商成功，那么onopen回调在客户端上被触发，并且应用程序可以查询WebSocket对象上的协议属性来确定所选择的协议。另一方面，如果服务器不支持任何客户端发布的客户端协议，那么WebSocket握手是不完整的:onerror回调被调用，连接被终止。

子协议名称由应用程序定义，并在初始HTTP握手期间按指定的方式发送到服务器。除此之外，指定的子协议对核心WebSocket API没有影响。

 

原文：https://hpbn.co/websocket/

本文：http://jiagoushi.pro/node/1110

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】

WebSocket API为客户机和服务器之间的文本和二进制数据的双向、面向消息流提供了一个简单的接口:向构造函数传递一个WebSocket URL，设置几个JavaScript回调函数，然后我们就启动并运行了——其余的由浏览器处理。再加上WebSocket协议，它提供了二进制帧、可扩展性和子协议协商，WebSocket成为在浏览器中交付定制应用协议的完美工具。

然而，就像任何关于性能的讨论一样，尽管WebSocket协议的实现复杂性对应用程序是隐藏的，但它仍然对如何以及何时使用WebSocket有重要的性能暗示。WebSocket不是XHR或SSE的替代品，为了获得最佳性能，我们必须充分利用每种传输的优势!

要查看每个传输的性能特征，请参考XHR用例和性能以及SSE用例和性能。

请求和响应流

WebSocket是唯一允许在同一个TCP连接上进行双向通信的传输(图17-2):客户端和服务器可以随意交换消息。因此，WebSocket在两个方向上都提供了文本和二进制应用程序数据的低延迟交付。

图17-2。XHR, SSE, WebSocket的通信流程

• XHR为“事务性”请求-响应通信进行了优化:客户机向服务器发送完整的、格式良好的HTTP请求，服务器以完整的响应响应。不支持请求流，在Streams API可用之前，没有可靠的跨浏览器响应流API。
• SSE实现了基于文本数据的高效、低延迟的服务器到客户端的流化:客户端启动SSE连接，服务器使用事件源协议将更新流化到客户端。在初始握手之后，客户端不能向服务器发送任何数据。

传播和排队延迟

交换从XHR到SSE或WebSocket的传输不会减少客户端和服务器之间的往返!无论传输方式如何，数据包的传播延迟都是相同的。然而，除了传播延迟之外，还有排队延迟:消息在被路由到另一方之前必须在客户机或服务器上等待的时间。

在XHR轮询的情况下，排队延迟是客户端轮询间隔的函数:消息可能在服务器上可用，但直到下一个客户端XHR请求才能发送;请参阅XHR轮询的建模性能。相比之下，SSE和WebSocket都使用一个持久连接，这允许服务器在消息可用的时候就发送消息(以及客户端，在WebSocket的情况下)。

因此，对于SSE和WebSocket来说，“低延迟交付”是指消除消息排队延迟。我们还没有想出如何让WebSocket数据包的传输速度超过光速!

消息开销

一旦WebSocket连接建立，客户端和服务器通过WebSocket协议交换数据:应用消息被分成一个或多个帧，每个帧增加2到14字节的开销。而且，由于框架是通过自定义二进制格式完成的，因此UTF-8和二进制应用程序数据都可以通过相同的机制进行有效编码。与XHR和SSE相比如何?

1. SSE只增加了5字节的每条消息，但仅限于UTF-8内容;参见事件流协议。
2. HTTP / 1。x请求(XHR或其他)将携带额外的500-800字节HTTP元数据，加上cookie;参见测量和控制协议开销。
3. HTTP/2压缩HTTP元数据，这大大降低了开销;看到标题压缩。事实上，如果头在请求之间不改变，开销可以低至8字节!

请记住，这些开销数字不包括IP、TCP和TLS帧的开销，这些开销会增加每条消息60-100字节的综合开销，而与应用程序协议无关;参见优化TLS记录大小。

数据效率和压缩

每个XHR请求可以通过定期的HTTP协商来协商最佳的传输编码格式(例如，基于文本的数据的gzip)。类似地，由于SSE仅限于utf -8传输，所以可以通过在整个会话中应用gzip有效地压缩事件流数据。

使用WebSocket，情况会更加复杂:WebSocket可以传输文本和二进制数据，因此压缩整个会话没有意义。二进制有效负载可能已经被压缩了!因此，WebSocket必须实现自己的压缩机制，并有选择地将其应用于每个消息。

好消息是HyBi工作组正在为WebSocket协议开发每消息压缩扩展。然而，它还没有在任何浏览器中可用。因此，除非应用程序通过仔细优化其二进制有效负载(参见用JavaScript解码二进制数据)来实现自己的压缩逻辑，并为基于文本的消息实现自己的压缩逻辑，否则它可能会对传输的数据产生较高的字节开销!

Chrome和一些基于webkit的浏览器支持WebSocket协议压缩扩展的旧版本(每帧压缩);参见WebSocket多路复用和压缩。

自定义应用程序协议

浏览器针对HTTP数据传输进行了优化:它理解该协议，并提供广泛的服务，如身份验证、缓存、压缩等等。因此，XHR请求免费继承所有这些功能。

相比之下,流允许我们提供定制的客户端和服务器之间的协议,但代价的绕过许多浏览器提供的服务:最初的HTTP握手可以执行一些协商参数的连接,但是一旦建立了会话,所有进一步的客户端和服务器之间的数据流是不透明到浏览器。因此，交付自定义协议的灵活性也有其缺点，应用程序可能必须实现自己的逻辑来填补缺失的空白:缓存、状态管理、消息元数据的交付，等等!

初始的HTTP升级握手允许服务器利用现有的HTTP cookie机制来验证用户。如果验证失败，服务器可以拒绝WebSocket升级。

利用浏览器和中间缓存

使用常规HTTP具有显著的优势。问您自己一个简单的问题:客户机会从缓存接收到的数据中获益吗?或者，如果中介可以缓存资产，它是否可以优化资产的交付?

例如，WebSocket支持二进制传输，这允许应用程序流任意的图像格式而没有开销——好漂亮!然而，图像是在自定义协议中交付的这一事实意味着它不会被浏览器缓存或任何中介(例如CDN)缓存。因此，您可能需要向客户机进行不必要的传输，并向源服务器传输更多的流量。同样的逻辑也适用于所有其他数据格式:视频、文本等等。

因此，确保你为工作选择了合适的交通工具!解决这些问题的一个简单而有效的策略是使用WebSocket会话来传递非缓存数据，比如实时更新和应用“控制”消息，这可以触发XHR请求来通过HTTP协议获取其他资产。

部署WebSocket基础设施

HTTP为短时间和突发传输进行了优化。因此，许多服务器、代理和其他中介经常被配置为主动超时空闲HTTP连接，当然，这正是我们不希望看到的长时间WebSocket会话。为了解决这个问题，有三方面需要考虑:

• 路由器，负载平衡器，和代理在自己的网络
• 外部网络中的透明和显式代理(如ISP和运营商代理)
• 客户网络中的路由器、防火墙和代理

我们无法控制客户端网络的策略。事实上，一些网络可能会完全阻止WebSocket流量，这就是为什么您可能需要一个备用策略。类似地，我们无法控制外部网络上的代理。然而，这正是TLS可以帮助的地方!通过在安全的端到端连接上使用隧道，WebSocket通信可以绕过所有的中间代理。

使用TLS并不会阻止中间层对空闲TCP连接计时。然而，在实践中，它极大地提高了协商WebSocket会话的成功率，并且通常还有助于扩展连接超时间隔。

最后，还有我们自己部署和管理的基础设施，这通常也需要关注和调优。尽管责怪客户端或外部网络很容易，但问题往往是在家里。服务路径中的每个负载均衡器、路由器、代理和web服务器都必须进行调优，以允许长时间连接。

例如，Nginx 1.3.13+可以代理WebSocket流量，但默认为60秒超时!为了增加限制，我们必须明确地定义较长的超时:

location /websocket {
    proxy_pass http://backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_read_timeout 3600; 
    proxy_send_timeout 3600; 
}

1. 设置读取间隔60分钟的超时时间
2. 在写之间设置60分钟的超时时间

类似地，在一个或多个Nginx服务器前安装一个负载均衡器也很常见，比如HAProxy。毫不奇怪，我们在这里也需要应用类似的显式配置。HAProxy,因为:

defaults http
  timeout connect 30s
  timeout client  30s
  timeout server  30s
  timeout tunnel  1h

• 隧道的60分钟不活动超时

前面示例的问题是额外的“隧道”超时。在HAProxy中，连接、客户端和服务器的超时只适用于初始的HTTP升级握手，但是一旦升级完成，超时由隧道值控制。

Nginx和HAProxy只是在我们的数据中心运行的数百个不同的服务器、代理和负载平衡器中的两个。我们不能列举这些页面中所有的配置可能性。前面的示例只是说明了大多数基础设施需要自定义配置来处理长期存在的会话。因此，在实现应用程序保持生命值之前，首先要仔细检查基础设施。

长期会话和空闲会话占用所有中间服务器上的内存和套接字资源。因此，短超时通常被认为是安全、资源和操作方面的预防措施。部署WebSocket、SSE和HTTP/2(它们都依赖于长寿命会话)带来了各自的新操作挑战。

性能检查表

部署高性能WebSocket服务需要在客户端和服务器端进行仔细的调优和考虑。列入议程的标准的简短清单:

• 使用安全的WebSocket (WSS over TLS)进行可靠的部署。
• 密切关注polyfill 的性能(如有必要)。
• 利用子协议协商来确定应用程序协议。
• 优化二进制有效载荷以最小化传输大小。
• 考虑压缩UTF-8内容以最小化传输大小。
• 为接收到的二进制有效负载设置正确的二进制类型。
• 监视客户机上缓冲的数据量。
• 分割大型应用程序消息以避免线头阻塞。
• 在适用的情况下利用其他传输。

最后，但绝对不是最不重要的，优化移动!在手机上，实时推送可能是一个代价高昂的性能反模式，因为电池寿命总是非常宝贵。这并不是说WebSocket不应该在移动设备上使用。相反，它可以是一种高效的交通工具，但一定要考虑到它的要求:

• Preserve Battery Power

• Eliminate Periodic and Inefficient Data Transfers

• Nagle and Efficient Server Push

• Eliminate Unnecessary Application Keepalives

 

原文：https://hpbn.co/websocket/

本文：http://jiagoushi.pro/node/1112

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】

Best fortunes responses per second, Dell R440 Xeon Gold + 10 GbE(424 tests)

Rnk	Framework	Best performance (higher is better)		Errors	Cls	Lng	Plt	FE	Aos	DB	Dos	Orm	IA
1	drogon-core	678,278	100.0%	0	Ful	C++	Non	Non	Lin	Pg	Lin	Raw	Rea
2	actix-core	651,144	96.0%	0	Plt	Rus	Non	act	Lin	Pg	Lin	Raw	Rea
3	actix-pg	607,052	89.5%	0	Mcr	Rus	Non	act	Lin	Pg	Lin	Raw	Rea
4	drogon	553,366	81.6%	0	Ful	C++	Non	Non	Lin	Pg	Lin	Mcr	Rea
5	may-minihttp	476,965	70.3%	0	Mcr	Rus	Rus	may	Lin	Pg	Lin	Raw	Rea
6	h2o	411,176	60.6%	0	Plt	C	Non	h2o	Lin	Pg	Lin	Raw	Rea
7	lithium-postgres	401,783	59.2%	0	Mcr	C++	Non	Non	Lin	Pg	Lin	Ful	Rea
8	fasthttp-prefork-quicktemplate	363,587	53.6%	0	Plt	Go	Non	Non	Lin	Pg	Lin	Raw	Rea
9	atreugo-prefork-quicktemplate	362,342	53.4%	0	Plt	Go	Non	Non	Lin	Pg	Lin	Raw	Rea
10	hyper-db	358,511	52.9%	0	Mcr	Rus	Rus	Hyp	Lin	Pg	Lin	Raw	Rea
11	php-ngx-pgsql	356,507	52.6%	0	Plt	PHP	ngx	ngx	Lin	Pg	Lin	Raw	Rea
12	workerman-pgsql	352,508	52.0%	0	Plt	PHP	wor	Non	Lin	Pg	Lin	Raw	Rea
13	vertx-postgres	347,356	51.2%	0	Plt	Jav	ver	Non	Lin	Pg	Lin	Raw	Rea
14	ulib-postgres	344,634	50.8%	0	Plt	C++	Non	ULi	Lin	Pg	Lin	Mcr	Rea
15	fasthttp-quicktemplate	319,764	47.1%	0	Plt	Go	Non	Non	Lin	Pg	Lin	Raw	Rea
16	atreugo-quicktemplate	319,390	47.1%	0	Plt	Go	Non	Non	Lin	Pg	Lin	Raw	Rea
17	greenlightning	318,601	47.0%	0	Mcr	Jav	Non	Non	Lin	Pg	Lin	Raw	Rea
18	jooby-pgclient	312,439	46.1%	0	Ful	Jav	Utw	Non	Lin	Pg	Lin	Raw	Rea
19	fiber-prefork	301,604	44.5%	0	Plt	Go	Non	Non	Lin	Pg	Lin	Raw	Rea
20	go-pgx-prefork-quicktemplate	298,935	44.1%	0	Plt	Go	Non	Non	Lin	Pg	Lin	Raw	Rea
21	lithium	296,750	43.8%	0	Mcr	C++	Non	Non	Lin	My	Lin	Ful	Rea
22	workerman	291,339	43.0%	0	Plt	PHP	wor	Non	Lin	My	Lin	Raw	Rea
23	php-ngx-mysql	290,312	42.8%	0	Plt	PHP	ngx	ngx	Lin	My	Lin	Raw	Rea
24	aspcore-rhtx-pg	285,398	42.1%	0	Plt	C#	.NE	kes	Lin	Pg	Lin	Raw	Rea
25	swoole	283,728	41.8%	0	Plt	PHP	swo	Non	Lin	My	Lin	Raw	Rea
26	aspcore-ado-pg	273,121	40.3%	0	Plt	C#	.NE	kes	Lin	Pg	Lin	Raw	Rea
27	proteus	264,265	39.0%	0	Mcr	Jav	Utw	Non	Lin	Pg	Lin	Raw	Rea
28	kooby	258,382	38.1%	0	Ful	Kot	Utw	Non	Lin	Pg	Lin	Raw	Rea
29	gemini-postgres	258,129	38.1%	0	Ful	Jav	Svt	Res	Lin	Pg	Lin	Mcr	Rea
30	zysocket-v	257,268	37.9%	0	Ful	C#	.NE	zys	Lin	Pg	Lin	Raw	Rea
31	jooby-jaxrs	254,398	37.5%	0	Ful	Jav	Utw	Non	Lin	Pg	Lin	Raw	Rea
32	jooby	252,239	37.2%	0	Ful	Jav	Utw	Non	Lin	Pg	Lin	Raw	Rea
33	kumbiaphp-workerman	249,309	36.8%	0	Ful	PHP	wor	Non	Lin	Pg	Lin	Raw	Rea
34	light-4j	243,211	35.9%	0	Plt	Jav	lig	Non	Lin	Pg	Lin	Raw	Rea
35	cpoll_cppsp-raw	242,929	35.8%	0	Plt	C++	Non	Non	Lin	My	Lin	Raw	Rea
36	beetlex	241,339	35.6%	0	Ful	C#	.NE	bee	Lin	Pg	Lin	Raw	Rea
37	es4x	237,751	35.1%	0	Mcr	JS	ver	Non	Lin	Pg	Lin	Raw	Rea
38	ulib-postgres_fit	235,845	34.8%	0	Plt	C++	Non	ULi	Lin	Pg	Lin	Mcr	Rea
39	jooby-jetty	235,161	34.7%	0	Ful	Jav	Jty	Non	Lin	Pg	Lin	Raw	Rea
40	aspcore-mw-ado-pg	234,321	34.5%	0	Mcr	C#	.NE	kes	Lin	Pg	Lin	Raw	Rea
41	aspcore-vb-mw-ado-pg	227,638	33.6%	0	Mcr	vb	.NE	kes	Lin	Pg	Lin	Raw	Rea
42	go-pgx-quicktemplate	225,782	33.3%	0	Plt	Go	Non	Non	Lin	Pg	Lin	Raw	Rea
43	jlhttp-postgres	222,691	32.8%	0	Plt	Jav	JLH	Non	Lin	Pg	Lin	Raw	Rea
44	undertow-postgresql	222,598	32.8%	0	Plt	Jav	Utw	Non	Lin	Pg	Lin	Raw	Rea
45	jooby-netty	222,565	32.8%	0	Ful	Jav	Nty	Non	Lin	Pg	Lin	Raw	Rea
46	vertx-web-scala	214,768	31.7%	0	Mcr	Sca	ver	Non	Lin	Pg	Lin	Raw	Rea
47	fiber	210,127	31.0%	0	Plt	Go	Non	Non	Lin	Pg	Lin	Raw	Rea
48	revenj-jvm	210,121	31.0%	0	Ful	Jav	Svt	Res	Lin	Pg	Lin	Ful	Rea
49	kemal	208,775	30.8%	0	Ful	Cry	Non	Non	Lin	Pg	Lin	Mcr	Rea
50	rapidoid-postgres	208,499	30.7%	0	Plt	Jav	Rap	Non	Lin	Pg	Lin	Mcr	Rea
51	crystal	207,551	30.6%	0	Plt	Cry	Non	Non	Lin	Pg	Lin	Raw	Rea
52	grip	207,490	30.6%	0	Mcr	Cry	Non	Non	Lin	Pg	Lin	Raw	Rea
53	crystal-radix	204,596	30.2%	0	Plt	Cry	Non	Non	Lin	Pg	Lin	Raw	Rea
54	raze	202,714	29.9%	0	Ful	Cry	Non	Non	Lin	Pg	Lin	Mcr	Rea
55	http4k-apache	202,537	29.9%	0	Mcr	Kot	apa	Non	Lin	Pg	Lin	Raw	Rea
56	kumbiaphp-workerman-mysql	201,807	29.8%	0	Ful	PHP	wor	Non	Lin	My	Lin	Mcr	Rea
57	aspcore-mw-dap-pg	198,450	29.3%	0	Mcr	C#	.NE	kes	Lin	Pg	Lin	Mcr	Rea
58	openresty	198,054	29.2%	0	Plt	Lua	OpR	ngx	Lin	My	Lin	Raw	Rea
59	act-eclipselink-pgsql	196,017	28.9%	0	Ful	Jav	Utw	Non	Lin	Pg	Lin	Ful	Rea
60	ubiquity-workerman	190,634	28.1%	0	Ful	PHP	wor	Non	Lin	Pg	Lin	Ful	Rea
61	zebra	188,840	27.8%	0	Ful	f#	.NE	kes	Lin	Pg	Lin	Raw	Rea
62	hexagon-resin-postgresql	188,288	27.8%	0	Mcr	Kot	Svt	Non	Lin	Pg	Lin	Raw	Rea
63	http4k-undertow	188,273	27.8%	0	Mcr	Kot	Utw	Non	Lin	Pg	Lin	Raw	Rea
64	aspcore-ado-my	187,309	27.6%	0	Plt	C#	.NE	kes	Lin	My	Lin	Raw	Rea
65	cutelyst-thread-pg	186,461	27.5%	0	Ful	C++	cut	Non	Lin	Pg	Lin	Raw	Rea
66	cutelyst-pf-pg-nodelay	186,376	27.5%	0	Ful	C++	cut	Non	Lin	Pg	Lin	Raw	Rea
67	cutelyst-thread-pg-nodelay	185,641	27.4%	0	Ful	C++	cut	Non	Lin	Pg	Lin	Raw	Rea
68	simps	182,191	26.9%	0	Mcr	PHP	swo	Non	Lin	My	Lin	Raw	Rea
69	cutelyst-pf-pg	179,972	26.5%	0	Ful	C++	cut	Non	Lin	Pg	Lin	Raw	Rea
70	ulib-mysql	179,425	26.5%	0	Plt	C++	Non	ULi	Lin	My	Lin	Mcr	Rea
71	vertx-web-postgres	176,093	26.0%	0	Mcr	Jav	ver	Non	Lin	Pg	Lin	Raw	Rea
72	act-hibernate-pgsql	175,656	25.9%	0	Ful	Jav	Utw	Non	Lin	Pg	Lin	Ful	Rea
73	helidon	173,306	25.6%	0	Mcr	Jav	Nty	Non	Lin	Pg	Lin	Raw	Rea
74	aspcore-mw-ado-my	170,573	25.1%	0	Mcr	C#	.NE	kes	Lin	My	Lin	Raw	Rea
75	aspcore-vb-mw-ado-my	169,856	25.0%	0	Mcr	vb	.NE	kes	Lin	My	Lin	Raw	Rea
76	chi-gojay-prefork	165,126	24.3%	0	Mcr	Go	Non	Non	Lin	My	Lin	Raw	Rea
77	http4k	164,684	24.3%	0	Mcr	Kot	Svt	Non	Lin	Pg	Lin	Raw	Rea
78	fasthttp-prefork	163,706	24.1%	0	Plt	Go	Non	Non	Lin	Pg	Lin	Raw	Rea
79	actix-diesel	161,892	23.9%	0	Mcr	Rus	Non	act	Lin	Pg	Lin	Ful	Rea
80	atreugo-prefork	161,479	23.8%	0	Plt	Go	Non	Non	Lin	Pg	Lin	Raw	Rea
81	giraffe	161,005	23.7%	0	Ful	f#	.NE	kes	Lin	Pg	Lin	Mcr	Rea
82	chi-prefork	160,869	23.7%	0	Mcr	Go	Non	Non	Lin	My	Lin	Raw	Rea
83	act-hibernate-pgsql-rythm	159,866	23.6%	0	Ful	Jav	Utw	Non	Lin	Pg	Lin	Ful	Rea
84	chi-sjson-prefork	159,292	23.5%	0	Mcr	Go	Non	Non	Lin	My	Lin	Raw	Rea
85	aspcore-mw-ef-pg	157,931	23.3%	0	Mcr	C#	.NE	kes	Lin	Pg	Lin	Ful	Rea
86	aspcore-mw-dap-my	155,853	23.0%	0	Mcr	C#	.NE	kes	Lin	My	Lin	Mcr	Rea
87	warp-mysql-haskell	155,711	23.0%	0	Mcr	Hkl	Wai	wai	Lin	My	Lin	Raw	Rea
88	act-hibernate-mysql	154,441	22.8%	0	Ful	Jav	Utw	Non	Lin	My	Lin	Ful	Rea
89	act-eclipselink-pgsql-rythm	153,060	22.6%	0	Ful	Jav	Utw	Non	Lin	Pg	Lin	Ful	Rea
90	warp	152,392	22.5%	0	Mcr	Hkl	Wai	wai	Lin	Pg	Lin	Raw	Rea
91	php-ngx-async	151,834	22.4%	0	Plt	PHP	ngx	ngx	Lin	My	Lin	Raw	Rea
92	swoole-no-async	151,102	22.3%	0	Plt	PHP	swo	Non	Lin	My	Lin	Raw	Rea
93	proteus-mysql	150,380	22.2%	0	Mcr	Jav	Utw	Non	Lin	My	Lin	Raw	Rea
94	act-hibernate-mysql-rythm	147,057	21.7%	0	Ful	Jav	Utw	Non	Lin	My	Lin	Ful	Rea
95	fasthttp	146,882	21.7%	0	Plt	Go	Non	Non	Lin	Pg	Lin	Raw	Rea
96	act-eclipselink-mysql	146,534	21.6%	0	Ful	Jav	Utw	Non	Lin	My	Lin	Ful	Rea
97	atreugo	144,987	21.4%	0	Plt	Go	Non	Non	Lin	Pg	Lin	Raw	Rea
98	go-my-prefork	144,289	21.3%	0	Plt	Go	Non	Non	Lin	My	Lin	Raw	Rea
99	hexagon-jetty-postgresql	141,759	20.9%	0	Mcr	Kot	Svt	Non	Lin	Pg	Lin	Raw	Rea
100	ulib-mongodb	141,657	20.9%	0	Plt	C++	Non	ULi	Lin	Mo	Lin	Mcr	Rea
101	gemini-mysql	140,793	20.8%	0	Ful	Jav	Svt	Res	Lin	My	Lin	Mcr	Rea
102	ubiquity-swoole	140,604	20.7%	0	Ful	PHP	swo	Non	Lin	Pg	Lin	Ful	Rea
103	act-eclipselink-mysql-rythm	136,914	20.2%	0	Ful	Jav	Utw	Non	Lin	My	Lin	Ful	Rea
104	go-pgx-prefork	134,727	19.9%	0	Plt	Go	Non	Non	Lin	Pg	Lin	Raw	Rea
105	ratpack-jdbc	134,690	19.9%	0	Mcr	Jav	Nty	Non	Lin	Pg	Lin	Raw	Rea
106	rapidoid-mysql	133,362	19.7%	0	Plt	Jav	Rap	Non	Lin	My	Lin	Mcr	Rea
107	polkadot-postgres	131,783	19.4%	0	Plt	JS	Non	Non	Lin	Pg	Lin	Raw	Rea
108	ratpack-pgclient	131,066	19.3%	0	Mcr	Jav	Nty	Non	Lin	Pg	Lin	Raw	Rea
109	cutelyst-nginx-pg	128,097	18.9%	0	Ful	C++	uWS	ngx	Lin	Pg	Lin	Raw	Rea
110	fasthttp-mongo-prefork	124,521	18.4%	0	Plt	Go	Non	Non	Lin	Mo	Lin	Raw	Rea
111	aspcore-mvc-ado-pg	124,455	18.3%	0	Ful	C#	.NE	kes	Lin	Pg	Lin	Raw	Rea
112	warp-hasql	122,305	18.0%	0	Mcr	Hkl	Wai	wai	Lin	Pg	Lin	Raw	Rea
113	atreugo-mongo-prefork	122,256	18.0%	0	Plt	Go	Non	Non	Lin	Mo	Lin	Raw	Rea
114	imi-raw	121,648	17.9%	0	Mcr	PHP	swo	Non	Lin	My	Lin	Raw	Rea
115	workerman-async	118,772	17.5%	0	Plt	PHP	wor	Non	Lin	My	Lin	Raw	Rea
116	nodejs-mongodb-raw	115,477	17.0%	0	Plt	JS	njs	Non	Lin	Mo	Lin	Raw	Rea
117	aspcore-mvc-dap-pg	115,329	17.0%	0	Ful	C#	.NE	kes	Lin	Pg	Lin	Mcr	Rea
118	ubiquity-swoole-mysql-async	115,321	17.0%	0	Ful	PHP	swo	Non	Lin	My	Lin	Ful	Rea
119	lwan	114,729	16.9%	0	Mcr	C	Lwa	lwa	Lin	My	Lin	Raw	Rea
120	vertx-web-susom-postgres	114,654	16.9%	0	Mcr	Jav	ver	Non	Lin	Pg	Lin	Raw	Rea
121	go-mgo-prefork	111,343	16.4%	0	Plt	Go	Non	Non	Lin	Mo	Lin	Raw	Rea
122	polkadot-mongodb	111,286	16.4%	0	Plt	JS	Non	Non	Lin	Mo	Lin	Raw	Rea
123	go-pgx	111,168	16.4%	0	Plt	Go	Non	Non	Lin	Pg	Lin	Raw	Rea
124	fintrospect	110,211	16.2%	0	Mcr	Sca	Nty	Non	Lin	My	Lin	Raw	Rea
125	servlet-postgresql	109,125	16.1%	0	Plt	Jav	Svt	Res	Lin	Pg	Lin	Raw	Rea
126	cutelyst-thread-my	107,101	15.8%	0	Ful	C++	cut	Non	Lin	My	Lin	Raw	Rea
127	cutelyst-thread-my-nodelay	106,740	15.7%	0	Ful	C++	cut	Non	Lin	My	Lin	Raw	Rea
128	php-unit	106,582	15.7%	0	Plt	PHP	uni	Non	Lin	My	Lin	Raw	Rea
129	cutelyst-thread-pg-grantlee	105,911	15.6%	0	Ful	C++	cut	Non	Lin	Pg	Lin	Raw	Rea
130	php-pgsql-raw	104,730	15.4%	0	Plt	PHP	fpm	ngx	Lin	Pg	Lin	Raw	Rea
131	aspcore-mvc-ado-my	104,075	15.3%	0	Ful	C#	.NE	kes	Lin	My	Lin	Raw	Rea
132	polkadot-mysql	103,016	15.2%	0	Plt	JS	njs	Non	Lin	My	Lin	Raw	Rea
133	cutelyst-pf-my-nodelay	101,653	15.0%	0	Ful	C++	cut	Non	Lin	My	Lin	Raw	Rea
134	cutelyst-pf-my	101,536	15.0%	0	Ful	C++	cut	Non	Lin	My	Lin	Raw	Rea
135	toro	101,088	14.9%	282	Mcr	Cry	Non	Non	Lin	Pg	Lin	Raw	Rea
136	chi-gojay	99,528	14.7%	0	Mcr	Go	Non	Non	Lin	My	Lin	Raw	Rea
137	aspcore-mvc-dap-my	99,238	14.6%	0	Ful	C#	.NE	kes	Lin	My	Lin	Mcr	Rea
138	akka-http	99,237	14.6%	0	Mcr	Sca	Akk	Non	Lin	My	Lin	Raw	Rea
139	chi	98,889	14.6%	0	Mcr	Go	Non	Non	Lin	My	Lin	Raw	Rea
140	hexagon-resin-mongodb	98,017	14.5%	0	Mcr	Kot	Svt	Non	Lin	Mo	Lin	Raw	Rea
141	php	97,727	14.4%	0	Plt	PHP	fpm	ngx	Lin	My	Lin	Raw	Rea
142	chi-sjson	96,765	14.3%	0	Mcr	Go	Non	Non	Lin	My	Lin	Raw	Rea
143	aah-postgresql	96,699	14.3%	0	Ful	Go	Non	Non	Lin	Pg	Lin	Raw	Rea
144	php-h2o	96,667	14.3%	0	Plt	PHP	fpm	h2o	Lin	My	Lin	Raw	Rea
145	php-pools	96,572	14.2%	0	Plt	PHP	fpm	ngx	Lin	My	Lin	Raw	Rea
146	treefrog-mongodb	96,231	14.2%	0	Ful	C++	Non	Non	Lin	Mo	Lin	Mcr	Rea
147	chi-scratch	95,476	14.1%	0	Mcr	Go	Non	Non	Lin	My	Lin	Raw	Rea
148	fastify-postgres	95,088	14.0%	0	Mcr	JS	njs	Non	Lin	Pg	Lin	Raw	Rea
149	aspcore-mvc-ef-pg	94,107	13.9%	0	Ful	C#	.NE	kes	Lin	Pg	Lin	Ful	Rea
150	fastify-mysql	93,665	13.8%	0	Mcr	JS	njs	Non	Lin	My	Lin	Raw	Rea
151	servlet-mysql	92,967	13.7%	0	Plt	Jav	Svt	Res	Lin	My	Lin	Raw	Rea
152	nodejs	91,799	13.5%	0	Plt	JS	njs	Non	Lin	My	Lin	Raw	Rea
153	nodejs-chakra	91,778	13.5%	0	Plt	JS	njs	Non	Lin	My	Lin	Raw	Rea
154	fastify	91,769	13.5%	0	Mcr	JS	njs	Non	Lin	Mo	Lin	Raw	Rea
155	wt	90,647	13.4%	0	Ful	C++	Non	Non	Lin	My	Lin	Ful	Rea
156	micronaut	90,601	13.4%	0	Mcr	Jav	Nty	Non	Lin	Pg	Lin	Raw	Rea
157	act-morphia-mongo	89,840	13.2%	0	Ful	Jav	Utw	Non	Lin	Mo	Lin	Ful	Rea
158	redkale-postgres	89,236	13.2%	0	Ful	Jav	red	Non	Lin	Pg	Lin	Raw	Rea
159	act-morphia-mongo-rythm	89,013	13.1%	0	Ful	Jav	Utw	Non	Lin	Mo	Lin	Ful	Rea
160	servant-psql-simple	88,759	13.1%	0	Mcr	Hkl	Wai	Wrp	Lin	Pg	Lin	Raw	Rea
161	pedestal	88,252	13.0%	0	Mcr	Clj	Jty	Non	Lin	My	Lin	Mcr	Rea
162	go-my	87,930	13.0%	2	Plt	Go	Non	Non	Lin	My	Lin	Raw	Rea
163	hexagon	87,718	12.9%	0	Mcr	Kot	Svt	Non	Lin	Mo	Lin	Raw	Rea
164	play2-java-jpa-hikaricp-netty	85,449	12.6%	0	Ful	Jav	Nty	Non	Lin	My	Lin	Ful	Rea
165	minijax	85,399	12.6%	0	Ful	Jav	JAX	Utw	Lin	My	Lin	Ful	Rea
166	fasthttp-mongo	83,915	12.4%	0	Plt	Go	Non	Non	Lin	Mo	Lin	Raw	Rea
167	cutelyst-nginx-my	83,551	12.3%	0	Ful	C++	uWS	ngx	Lin	My	Lin	Raw	Rea
168	atreugo-mongo	81,040	11.9%	0	Plt	Go	Non	Non	Lin	Mo	Lin	Raw	Rea
169	treefrog-postgres	79,580	11.7%	8	Ful	C++	Non	Non	Lin	Pg	Lin	Mcr	Rea
170	duct	79,059	11.7%	0	Mcr	Clj	Rin	Non	Lin	Pg	Lin	Raw	Rea
171	vertx-web-mongodb	78,538	11.6%	0	Mcr	Jav	ver	Non	Lin	Mo	Lin	Raw	Rea
172	hamlet-workerman	78,214	11.5%	0	Ful	PHP	wor	Non	Lin	My	Lin	Mcr	Rea
173	compojure-raw	76,832	11.3%	0	Mcr	Clj	Svt	Res	Lin	My	Lin	Raw	Rea
174	cutelyst-thread-my-grantlee	75,816	11.2%	0	Ful	C++	cut	Non	Lin	My	Lin	Raw	Rea
175	http-kit-raw	75,309	11.1%	0	Plt	Clj	Rin	Non	Lin	My	Lin	Raw	Rea
176	kumbiaphp	74,171	10.9%	0	Ful	PHP	fpm	ngx	Lin	My	Lin	Mcr	Rea
177	kumbiaphp-raw	73,714	10.9%	0	Ful	PHP	fpm	ngx	Lin	My	Lin	Raw	Rea
178	duct-mongodb	73,630	10.9%	0	Mcr	Clj	Rin	Non	Lin	Mo	Lin	Raw	Rea
179	echo	73,300	10.8%	0	Mcr	Go	Non	Non	Lin	Pg	Lin	Raw	Rea
180	uvicorn	72,929	10.8%	0	Plt	Py	Non	Non	Lin	Pg	Lin	Raw	Rea
181	ubiquity	72,844	10.7%	0	Ful	PHP	fpm	ngx	Lin	My	Lin	Ful	Rea
182	play2-java-jooq-hikaricp-netty	72,685	10.7%	0	Ful	Jav	Nty	Non	Lin	My	Lin	Ful	Rea
183	hamlet-swoole	70,964	10.5%	0	Ful	PHP	swo	Non	Lin	My	Lin	Mcr	Rea
184	treefrog	70,769	10.4%	10	Ful	C++	Non	Non	Lin	My	Lin	Mcr	Rea
185	apidaora-core	70,659	10.4%	0	Mcr	Py	Non	Non	Lin	Pg	Lin	Raw	Rea
186	duct-aleph	70,285	10.4%	0	Mcr	Clj	Nty	Non	Lin	Pg	Lin	Raw	Rea
187	aah-mysql	69,752	10.3%	0	Ful	Go	Non	Non	Lin	My	Lin	Raw	Rea
188	roa-diesel	68,129	10.0%	0	Mcr	Rus	Non	Hyp	Lin	Pg	Lin	Ful	Rea
189	nestjs-fastify-mysql	67,920	10.0%	0	Mcr	typ	Non	Non	Lin	My	Lin	Ful	Rea
190	play2-java-jpa-hikaricp	67,361	9.9%	0	Ful	Jav	Akk	Non	Lin	My	Lin	Ful	Rea
191	nestjs-fastify	67,331	9.9%	0	Mcr	typ	Non	Non	Lin	Pg	Lin	Ful	Rea
192	blacksheep	67,321	9.9%	0	Plt	Py	Non	Non	Lin	Pg	Lin	Raw	Rea
193	gin-scratch	67,227	9.9%	0	Mcr	Go	Non	Non	Lin	My	Lin	Raw	Rea
194	play2-java-ebean-hikaricp-netty	66,647	9.8%	0	Ful	Jav	Nty	Non	Lin	My	Lin	Ful	Rea
195	luminus	66,471	9.8%	0	Mcr	Clj	Rin	Non	Lin	Pg	Lin	Raw	Rea
196	ubiquity-roadrunner	66,418	9.8%	0	Ful	PHP	roa	Non	Lin	Pg	Lin	Ful	Rea
197	ubiquity-roadrunner-mysql	65,948	9.7%	0	Ful	PHP	roa	Non	Lin	My	Lin	Ful	Rea
198	undertow-jersey-hikaricp	65,485	9.7%	0	Plt	Jav	JAX	Non	Lin	My	Lin	Ful	Rea
199	sanic	65,039	9.6%	0	Mcr	Py	Non	Non	Lin	Pg	Lin	Raw	Rea
200	lapis	64,724	9.5%	0	Ful	Lua	OpR	ngx	Lin	Pg	Lin	Ful	Rea
201	nestjs-fastify-mongo	64,206	9.5%	0	Mcr	typ	Non	Non	Lin	Mo	Lin	Ful	Rea
202	grizzly-jersey	63,557	9.4%	0	Mcr	Jav	JAX	Grz	Lin	My	Lin	Ful	Rea
203	apidaora	63,489	9.4%	0	Mcr	Py	Non	Non	Lin	Pg	Lin	Raw	Rea
204	chubbajs	63,215	9.3%	0	Mcr	JS	njs	Non	Lin	Pg	Lin	Mcr	Rea
205	starlette	62,707	9.2%	0	Mcr	Py	Non	Non	Lin	Pg	Lin	Raw	Rea
206	jawn	62,631	9.2%	0	Ful	Jav	Utw	Non	Lin	Pg	Lin	Raw	Rea
207	dropwizard-postgres	62,354	9.2%	0	Ful	Jav	JAX	Jty	Lin	Pg	Lin	Ful	Rea
208	php-raw7-tcp	60,871	9.0%	21,542	Plt	PHP	fpm	ngx	Lin	My	Lin	Raw	Rea
209	play2-scala-anorm-netty	60,767	9.0%	0	Ful	Sca	Nty	Non	Lin	My	Lin	Ful	Rea
210	quarkus-hibernate	60,752	9.0%	0	Ful	Jav	JAX	Non	Lin	Pg	Lin	Ful	Rea
211	play2-java-jooq-hikaricp	59,473	8.8%	0	Ful	Jav	Akk	Non	Lin	My	Lin	Ful	Rea
212	vibed-ldc-pgsql	59,436	8.8%	0	Plt	D	Non	Non	Lin	Pg	Lin	Raw	Rea
213	gin	58,974	8.7%	0	Mcr	Go	Non	Non	Lin	My	Lin	Raw	Rea
214	vibed-dmd-pgsql	58,795	8.7%	0	Plt	D	Non	Non	Lin	Pg	Lin	Raw	Rea
215	vibed-ldc	56,526	8.3%	0	Plt	D	Non	Non	Lin	Mo	Lin	Mcr	Rea
216	play2-scala-slick-netty	56,293	8.3%	0	Ful	Sca	Nty	Non	Lin	My	Lin	Ful	Rea
217	nodejs-postgres	55,925	8.2%	0	Plt	JS	njs	Non	Lin	Pg	Lin	Ful	Rea
218	play2-java-ebean-hikaricp	55,653	8.2%	0	Ful	Jav	Akk	Non	Lin	My	Lin	Ful	Rea
219	ktor	54,879	8.1%	0	Mcr	Kot	Nty	Non	Lin	Pg	Lin	Raw	Rea
220	roa-pg	54,664	8.1%	0	Mcr	Rus	Non	Hyp	Lin	Pg	Lin	Raw	Rea
221	nestjs	53,905	7.9%	0	Mcr	typ	Non	Non	Lin	Pg	Lin	Ful	Rea
222	dropwizard	53,256	7.9%	0	Ful	Jav	JAX	Jty	Lin	My	Lin	Ful	Rea
223	vibed	52,780	7.8%	0	Mcr	D	Non	Non	Lin	Mo	Lin	Mcr	Rea
224	lithium-postgres-1t	52,667	7.8%	0	Mcr	C++	Non	Non	Lin	Pg	Lin	Ful	Rea
225	play2-scala-anorm	52,585	7.8%	0	Ful	Sca	Akk	Non	Lin	My	Lin	Ful	Rea
226	fastapi-orjson	52,080	7.7%	0	Mcr	Py	Non	Non	Lin	Pg	Lin	Raw	Rea
227	officefloor-tpr	52,053	7.7%	0	Ful	Jav	off	woo	Lin	Pg	Lin	Raw	Rea
228	fastapi	51,981	7.7%	0	Mcr	Py	Non	Non	Lin	Pg	Lin	Raw	Rea
229	officefloor-thread_affinity	51,936	7.7%	0	Ful	Jav	off	woo	Lin	Pg	Lin	Raw	Rea
230	officefloor-micro	51,760	7.6%	0	Ful	Jav	off	woo	Lin	Pg	Lin	Raw	Rea
231	roda-sequel-postgres	50,981	7.5%	0	Mcr	Rby	Rac	Pum	Lin	Pg	Lin	Ful	Rea
232	nestjs-mysql	50,712	7.5%	0	Mcr	typ	Non	Non	Lin	My	Lin	Ful	Rea
233	nodejs-mysql	50,692	7.5%	0	Plt	JS	njs	Non	Lin	My	Lin	Ful	Rea
234	lithium-mysql-1t	50,460	7.4%	0	Mcr	C++	Non	Non	Lin	My	Lin	Ful	Rea
235	revenj	50,341	7.4%	0	Ful	C#	Non	Non	Lin	Pg	Lin	Ful	Rea
236	sw-fw-less	49,667	7.3%	2,861	Mcr	PHP	swo	Non	Lin	My	Lin	Ful	Rea
237	phoenix	49,186	7.3%	0	Ful	Eli	Cow	Non	Lin	Pg	Lin	Ful	Rea
238	roda-sequel	49,140	7.2%	0	Mcr	Rby	Rac	Pum	Lin	My	Lin	Ful	Rea
239	http-kit	49,067	7.2%	0	Plt	Clj	Rin	Non	Lin	My	Lin	Mcr	Rea
240	symfony-swoole	48,130	7.1%	0	Ful	PHP	swo	Non	Lin	My	Lin	Ful	Rea
241	blade	47,774	7.0%	0	Ful	Jav	Non	Non	Lin	My	Lin	Ful	Rea
242	nestjs-mongo	47,518	7.0%	0	Mcr	typ	Non	Non	Lin	Mo	Lin	Ful	Rea
243	redstone	46,969	6.9%	0	Mcr	Dar	Non	Non	Lin	Pg	Lin	Mcr	Rea
244	koa-postgres	46,451	6.8%	0	Mcr	JS	njs	Non	Lin	Pg	Lin	Raw	Rea
245	compojure	45,881	6.8%	0	Mcr	Clj	Svt	Res	Lin	My	Lin	Mcr	Rea
246	koa-mysql	45,846	6.8%	0	Mcr	JS	njs	Non	Lin	My	Lin	Raw	Rea
247	play2-scala-slick	45,521	6.7%	0	Ful	Sca	Akk	Non	Lin	My	Lin	Ful	Rea
248	roa-sqlx	44,869	6.6%	0	Mcr	Rus	Non	Hyp	Lin	Pg	Lin	Raw	Rea
249	express-mysql	44,166	6.5%	0	Mcr	JS	njs	Non	Lin	My	Lin	Ful	Rea
250	responder	43,647	6.4%	0	Plt	Py	Non	Non	Lin	Pg	Lin	Raw	Rea
251	tapestry	42,982	6.3%	0	Ful	Jav	Svt	Res	Lin	My	Lin	Ful	Rea
252	officefloor-netty	42,591	6.3%	0	Ful	Jav	off	woo	Lin	Pg	Lin	Ful	Rea
253	undertow-jersey	42,567	6.3%	0	Plt	Jav	JAX	Non	Lin	My	Lin	Ful	Rea
254	wicket	41,489	6.1%	0	Ful	Jav	Svt	Res	Lin	My	Lin	Ful	Rea
255	officefloor	40,849	6.0%	0	Ful	Jav	off	woo	Lin	Pg	Lin	Ful	Rea
256	start	40,689	6.0%	0	Mcr	Dar	Non	ngx	Lin	Mo	Lin	Raw	Rea
257	roda-sequel-postgres-passenger-mri	40,281	5.9%	0	Mcr	Rby	Rac	Pas	Lin	Pg	Lin	Ful	Rea
258	roda-sequel-passenger-mri	39,824	5.9%	0	Mcr	Rby	Rac	Pas	Lin	My	Lin	Ful	Rea
259	spark	39,411	5.8%	0	Mcr	Jav	Svt	Jty	Lin	My	Lin	Ful	Rea
260	redstone-mongodb	38,873	5.7%	0	Mcr	Dar	Non	Non	Lin	Mo	Lin	Mcr	Rea
261	http4k-ktorcio	38,385	5.7%	0	Mcr	Kot	kto	Non	Lin	Pg	Lin	Raw	Rea
262	aiohttp-pg-raw	36,432	5.4%	0	Mcr	Py	asy	Gun	Lin	Pg	Lin	Raw	Rea
263	ktor-reactivepg	36,141	5.3%	0	Ful	Kot	Non	Non	Lin	Pg	Lin	Raw	Rea
264	ffead-cpp-nginx-mongo	35,466	5.2%	0	Ful	C++	ffe	ngx	Lin	Mo	Lin	Ful	Rea
265	stream	35,416	5.2%	0	Mcr	Dar	Non	ngx	Lin	Mo	Lin	Raw	Rea
266	bottle-raw	35,031	5.2%	0	Mcr	Py	Mei	Non	Lin	My	Lin	Raw	Rea
267	spiral	34,641	5.1%	0	Ful	PHP	roa	Non	Lin	My	Lin	Ful	Rea
268	roda-sequel-postgres-torquebox-jruby	34,601	5.1%	0	Mcr	Rby	Rac	Tor	Lin	Pg	Lin	Ful	Rea
269	sinatra-sequel-postgres	34,114	5.0%	0	Mcr	Rby	Rac	Pum	Lin	Pg	Lin	Ful	Rea
270	imi	33,593	5.0%	0	Ful	PHP	swo	Non	Lin	My	Lin	Ful	Rea
271	sinatra-sequel	32,998	4.9%	0	Mcr	Rby	Rac	Pum	Lin	My	Lin	Ful	Rea
272	ktor-cio	32,514	4.8%	0	Mcr	Kot	kto	Non	Lin	Pg	Lin	Raw	Rea
273	ktor-jasync	31,618	4.7%	0	Ful	Kot	Non	Non	Lin	Pg	Lin	Raw	Rea
274	slim	31,441	4.6%	0	Mcr	PHP	fpm	ngx	Lin	My	Lin	Raw	Rea
275	http4s	31,328	4.6%	0	Mcr	Sca	NIO	bla	Lin	Pg	Lin	Raw	Rea
276	iron	30,908	4.6%	0	Mcr	Rus	Rus	Hyp	Lin	Pg	Lin	Raw	Rea
277	roda-sequel-torquebox-jruby	29,168	4.3%	0	Mcr	Rby	Rac	Tor	Lin	My	Lin	Ful	Rea
278	hot-mysql	28,409	4.2%	75	Plt	Grv	Jty	Jty	Lin	My	Lin	Raw	Rea
279	rocket	28,343	4.2%	0	Ful	Rus	Rus	Hyp	Lin	Pg	Lin	Ful	Rea
280	sinatra-sequel-postgres-passenger-mri	28,289	4.2%	0	Mcr	Rby	Rac	Pas	Lin	Pg	Lin	Ful	Rea
281	ffead-cpp-nginx-mysql	28,035	4.1%	0	Ful	C++	ffe	ngx	Lin	My	Lin	Ful	Rea
282	sinatra-sequel-passenger-mri	27,834	4.1%	0	Mcr	Rby	Rac	Pas	Lin	My	Lin	Ful	Rea
283	aqueduct	27,525	4.1%	0	Mcr	Dar	Non	Non	Lin	Pg	Lin	Mcr	Rea
284	spring	27,339	4.0%	0	Ful	Jav	tom	Non	Lin	Pg	Lin	Mcr	Rea
285	elixir-plug-ecto	27,062	4.0%	0	Mcr	Eli	bea	cow	Lin	Pg	Lin	Ful	Rea
286	api_hour	26,718	3.9%	0	Mcr	Py	asy	Gun	Lin	Pg	Lin	Raw	Rea
287	yii2-raw	26,652	3.9%	0	Ful	PHP	fpm	ngx	Lin	My	Lin	Raw	Rea
288	spring-mongo	26,424	3.9%	0	Ful	Jav	tom	Non	Lin	Mo	Lin	Ful	Rea
289	aspcore-mono-pg	26,280	3.9%	0	Plt	C#	.NE	kes	Lin	Pg	Lin	Raw	Rea
290	quart-uvicorn	26,082	3.8%	0	Mcr	Py	Non	uvi	Lin	Pg	Lin	Raw	Rea
291	quarkus-pgclient	25,956	3.8%	0	Ful	Jav	JAX	Non	Lin	Pg	Lin	Mcr	Rea
292	sinatra-sequel-postgres-torquebox-jruby	25,953	3.8%	0	Mcr	Rby	Rac	Tor	Lin	Pg	Lin	Ful	Rea
293	cppcms-postgres	25,706	3.8%	0	Plt	C++	Non	Non	Lin	Pg	Lin	Raw	Rea
294	roda-sequel-postgres-unicorn-mri	25,407	3.7%	0	Mcr	Rby	Rac	Uni	Lin	Pg	Lin	Ful	Rea
295	lumen-swoole	25,147	3.7%	0	Mcr	PHP	swo	Non	Lin	My	Lin	Ful	Rea
296	hamlet	24,781	3.7%	0	Ful	PHP	fpm	ngx	Lin	My	Lin	Mcr	Rea
297	cppcms	24,372	3.6%	0	Plt	C++	Non	Non	Lin	My	Lin	Raw	Rea
298	duct-httpkit	24,358	3.6%	0	Mcr	Clj	Rin	Non	Lin	Pg	Lin	Raw	Rea
299	codeigniter	24,135	3.6%	0	Ful	PHP	fpm	ngx	Lin	My	Lin	Raw	Rea
300	wildfly-ee	23,881	3.5%	0	Ful	Jav	Svt	Wil	Lin	My	Lin	Ful	Rea
301	aspcore-mono-my	23,793	3.5%	0	Plt	C#	.NE	kes	Lin	My	Lin	Raw	Rea
302	fat-free-raw	23,751	3.5%	0	Ful	PHP	fpm	ngx	Lin	My	Lin	Raw	Rea
303	flask-raw	23,136	3.4%	0	Mcr	Py	Mei	Non	Lin	My	Lin	Raw	Rea
304	aiohttp	22,972	3.4%	0	Mcr	Py	asy	Gun	Lin	Pg	Lin	Ful	Rea
305	spring-webflux-pgclient	22,607	3.3%	0	Ful	Jav	Nty	Non	Lin	Pg	Lin	Mcr	Rea
306	spring-webflux-jdbc	22,528	3.3%	0	Ful	Jav	Nty	Non	Lin	Pg	Lin	Mcr	Rea
307	sinatra-sequel-postgres-unicorn-mri	22,308	3.3%	0	Mcr	Rby	Rac	Uni	Lin	Pg	Lin	Ful	Rea
308	sinatra-sequel-unicorn-mri	22,238	3.3%	0	Mcr	Rby	Rac	Uni	Lin	My	Lin	Ful	Rea
309	aspcore-mono-mw-my	21,561	3.2%	0	Mcr	C#	.NE	kes	Lin	My	Lin	Raw	Rea
310	sinatra-sequel-torquebox-jruby	21,509	3.2%	0	Mcr	Rby	Rac	Tor	Lin	My	Lin	Ful	Rea
311	spring-webflux-mongo	21,503	3.2%	0	Ful	Jav	Nty	Non	Lin	Mo	Lin	Ful	Rea
312	php-eloquent	21,482	3.2%	0	Plt	PHP	fpm	ngx	Lin	My	Lin	Ful	Rea
313	go-mgo	21,469	3.2%	0	Plt	Go	Non	Non	Lin	Mo	Lin	Raw	Rea
314	pyramid-py2	21,461	3.2%	0	Ful	Py	Non	Mei	Lin	Pg	Lin	Ful	Rea
315	ninja-standalone	21,454	3.2%	0	Ful	Jav	Jty	Non	Lin	My	Lin	Ful	Rea
316	laravel-swoole	20,935	3.1%	0	Ful	PHP	swo	Non	Lin	My	Lin	Ful	Rea
317	tornado-py3-uvloop	20,728	3.1%	0	Plt	Py	Non	Tor	Lin	Pg	Lin	Raw	Rea
318	flask-pypy2-raw	20,654	3.0%	0	Mcr	Py	Tor	Non	Lin	My	Lin	Raw	Rea
319	api_hour-mysql	20,054	3.0%	0	Mcr	Py	asy	Gun	Lin	My	Lin	Raw	Rea
320	aspcore-mono-mw-pg	19,321	2.8%	0	Mcr	C#	.NE	kes	Lin	Pg	Lin	Raw	Rea
321	pyramid	18,538	2.7%	0	Ful	Py	Non	Mei	Lin	Pg	Lin	Ful	Rea
322	dropwizard-mongodb	18,221	2.7%	0	Ful	Jav	JAX	Jty	Lin	Mo	Lin	Ful	Rea
323	fat-free	18,048	2.7%	0	Ful	PHP	fpm	ngx	Lin	My	Lin	Ful	Rea
324	aspcore-mono-mw-ef-pg	18,022	2.7%	0	Mcr	C#	.NE	kes	Lin	Pg	Lin	Ful	Rea
325	roda-sequel-unicorn-mri	17,780	2.6%	0	Mcr	Rby	Rac	Uni	Lin	My	Lin	Ful	Rea
326	aspcore-mono-mvc-pg	17,679	2.6%	0	Ful	C#	.NE	kes	Lin	Pg	Lin	Raw	Rea
327	morepath	17,502	2.6%	0	Mcr	Py	Mei	Gun	Lin	Pg	Lin	Ful	Rea
328	activeweb	17,470	2.6%	0	Ful	Jav	Svt	Non	Lin	My	Lin	Mcr	Rea
329	weppy-pypy2	17,463	2.6%	0	Ful	Py	Tor	Non	Lin	Pg	Lin	Ful	Rea
330	play2-scala-reactivemongo-netty	16,736	2.5%	0	Ful	Sca	Nty	Non	Lin	Mo	Lin	Ful	Rea
331	sinatra-unicorn-mri	16,445	2.4%	0	Mcr	Rby	Rac	Uni	Lin	My	Lin	Ful	Rea
332	yii2	16,415	2.4%	0	Ful	PHP	fpm	ngx	Lin	My	Lin	Ful	Rea
333	weppy-py3	16,005	2.4%	0	Ful	Py	Mei	Non	Lin	Pg	Lin	Ful	Rea
334	tornado-pypy2	15,986	2.4%	0	Plt	Py	Non	Tor	Lin	Mo	Lin	Raw	Rea
335	sinatra-postgres-unicorn-mri	15,806	2.3%	0	Mcr	Rby	Rac	Uni	Lin	Pg	Lin	Ful	Rea
336	ffead-cpp	15,622	2.3%	0	Ful	C++	ffe	ffe	Lin	Mo	Lin	Ful	Rea
337	emmett	15,547	2.3%	0	Ful	Py	Non	Non	Lin	Pg	Lin	Ful	Rea
338	ktor-jetty	15,439	2.3%	0	Mcr	Kot	Jty	Non	Lin	Pg	Lin	Raw	Rea
339	hapi-postgres	15,127	2.2%	0	Mcr	JS	njs	Non	Lin	Pg	Lin	Ful	Rea
340	play2-scala-reactivemongo	15,100	2.2%	0	Ful	Sca	Akk	Non	Lin	Mo	Lin	Ful	Rea
341	django-postgresql	15,085	2.2%	0	Ful	Py	Non	Mei	Lin	Pg	Lin	Ful	Rea
342	sinatra-postgres-passenger-mri	15,015	2.2%	0	Mcr	Rby	Rac	Pas	Lin	Pg	Lin	Ful	Rea
343	sinatra-passenger-mri	14,920	2.2%	0	Mcr	Rby	Rac	Pas	Lin	My	Lin	Ful	Rea
344	weppy-nginx-uwsgi	14,751	2.2%	0	Ful	Py	uWS	ngx	Lin	Pg	Lin	Ful	Rea
345	django	14,699	2.2%	0	Ful	Py	Non	Mei	Lin	My	Lin	Ful	Rea
346	hapi-mysql	14,678	2.2%	0	Mcr	JS	njs	Non	Lin	My	Lin	Ful	Rea
347	aspcore-mono-mvc-ef-pg	14,407	2.1%	0	Ful	C#	.NE	kes	Lin	Pg	Lin	Ful	Rea
348	ringojs-convenient	14,033	2.1%	0	Mcr	JS	Rin	Non	Lin	My	Lin	Mcr	Rea
349	aspcore-mono-mvc-my	13,904	2.0%	0	Ful	C#	.NE	kes	Lin	My	Lin	Raw	Rea
350	bottle-pypy2	13,727	2.0%	0	Mcr	Py	Tor	Non	Lin	My	Lin	Ful	Rea
351	macchiato	13,493	2.0%	0	Mcr	Clj	njs	Non	Lin	Pg	Lin	Raw	Rea
352	mojolicious	12,464	1.8%	0	Ful	Prl	Non	Hyp	Lin	Pg	Lin	Raw	Rea
353	tornado-py3	12,328	1.8%	0	Plt	Py	Non	Tor	Lin	Mo	Lin	Raw	Rea
354	phalcon	12,253	1.8%	0	Ful	PHP	fpm	ngx	Lin	My	Lin	Raw	Rea
355	turbogears	11,931	1.8%	0	Mcr	Py	Non	Mei	Lin	My	Lin	Ful	Rea
356	bottle	11,880	1.8%	0	Mcr	Py	Mei	Non	Lin	My	Lin	Ful	Rea
357	fuel	11,759	1.7%	0	Mcr	PHP	fpm	ngx	Lin	My	Lin	Raw	Rea
358	grails	11,287	1.7%	0	Ful	Grv	Svt	Non	Lin	My	Lin	Ful	Rea
359	web2py-optimized	11,074	1.6%	0	Ful	Py	Mei	Non	Lin	My	Lin	Ful	Rea
360	flask	10,101	1.5%	0	Mcr	Py	Mei	Non	Lin	My	Lin	Ful	Rea
361	goframe	9,869	1.5%	0	Mcr	Go	Non	Non	Lin	My	Lin	Raw	Rea
362	flask-pypy2	9,008	1.3%	0	Mcr	Py	Non	Tor	Lin	My	Lin	Ful	Rea
363	rails	8,764	1.3%	0	Ful	Rby	Rac	Pum	Lin	My	Lin	Ful	Rea
364	tornado	8,702	1.3%	0	Plt	Py	Non	Tor	Lin	Mo	Lin	Raw	Rea
365	hapi-nginx	8,624	1.3%	0	Mcr	JS	njs	ngx	Lin	Pg	Lin	Ful	Rea
366	rails-unicorn	8,528	1.3%	0	Ful	Rby	Rac	Uni	Lin	My	Lin	Ful	Rea
367	lumen	8,435	1.2%	0	Mcr	PHP	fpm	ngx	Lin	My	Lin	Ful	Rea
368	rails-postgresql	8,434	1.2%	0	Ful	Rby	Rac	Pum	Lin	Pg	Lin	Ful	Rea
369	cakephp	7,418	1.1%	0	Ful	PHP	fpm	ngx	Lin	My	Lin	Ful	Rea
370	symfony	7,137	1.1%	0	Ful	PHP	fpm	ngx	Lin	My	Lin	Ful	Rea
371	bottle-nginx-uwsgi	6,640	1.0%	0	Mcr	Py	uWS	ngx	Lin	My	Lin	Ful	Rea
372	flask-nginx-uwsgi	6,597	1.0%	0	Mcr	Py	Non	ngx	Lin	My	Lin	Ful	Rea
373	web2py	6,014	0.9%	0	Ful	Py	Mei	Non	Lin	My	Lin	Ful	Rea
374	kitura-postgres	5,682	0.8%	0	Ful	Swi	kit	kit	Lin	Pg	Lin	Raw	Rea
375	kitura-gcd-postgres	5,605	0.8%	0	Ful	Swi	kit	kit	Lin	Pg	Lin	Raw	Rea
376	express-mongodb	5,588	0.8%	0	Mcr	JS	njs	Non	Lin	Mo	Lin	Ful	Rea
377	laravel	5,563	0.8%	0	Ful	PHP	fpm	ngx	Lin	My	Lin	Ful	Rea
378	kitura-nio-postgres	5,465	0.8%	0	Ful	Swi	kit	kit	Lin	Pg	Lin	Raw	Rea
379	httpserver-postgres	5,421	0.8%	363,929	Plt	Jav	htt	Non	Lin	Pg	Lin	Raw	Rea
380	kitura-postgres-orm	5,420	0.8%	0	Ful	Swi	kit	kit	Lin	Pg	Lin	Ful	Rea
381	kitura-gcd-postgres-orm	5,350	0.8%	0	Ful	Swi	kit	kit	Lin	Pg	Lin	Ful	Rea
382	kitura-nio-postgres-orm	5,228	0.8%	0	Ful	Swi	kit	kit	Lin	Pg	Lin	Ful	Rea
383	kitura-mongodb	4,657	0.7%	0	Ful	Swi	kit	kit	Lin	Mo	Lin	Raw	Rea
384	urweb-mysql	4,600	0.7%	0	Ful	Ur	Ur/	Non	Lin	My	Lin	Mcr	Rea
385	koa	4,528	0.7%	0	Mcr	JS	njs	Non	Lin	Mo	Lin	Raw	Rea
386	hapi	4,341	0.6%	0	Mcr	JS	njs	Non	Lin	Mo	Lin	Ful	Rea
387	padrino-unicorn	3,275	0.5%	0	Mcr	Rby	Rac	Uni	Lin	My	Lin	Ful	Rea
388	padrino	3,201	0.5%	0	Mcr	Rby	Rac	Pum	Lin	My	Lin	Ful	Rea
389	urweb	2,939	0.4%	0	Ful	Ur	Ur/	Non	Lin	Pg	Lin	Mcr	Rea
390	express-graphql-mysql	2,817	0.4%	0	Mcr	JS	njs	Non	Lin	My	Lin	Ful	Rea
391	officefloor-spring_data	2,622	0.4%	0	Ful	Jav	off	woo	Lin	Pg	Lin	Ful	Rea
392	ffead-cpp-nginx-postgresql	2,403	0.4%	0	Ful	C++	ffe	ngx	Lin	Pg	Lin	Ful	Rea
393	spyne-nginx-uwsgi	2,279	0.3%	0	Mcr	Py	Non	ngx	Lin	Pg	Lin	Ful	Rea
394	spyne-raw	1,892	0.3%	28	Mcr	Py	spy	Non	Lin	Pg	Lin	Raw	Rea
395	phalcon-micro	1,886	0.3%	53,048	Mcr	PHP	fpm	ngx	Lin	My	Lin	Raw	Rea
396	akka-http-slick-postgres	1,796	0.3%	0	Mcr	Sca	Akk	Non	Lin	Pg	Lin	Ful	Rea
397	aspnet-mono-ngx-my	1,545	0.2%	0	Plt	C#	.NE	ngx	Lin	My	Lin	Raw	Rea
398	phpixie	1,375	0.2%	53,987	Ful	PHP	fpm	ngx	Lin	My	Lin	Ful	Rea
399	express-graphql-postgres	1,087	0.2%	0	Mcr	JS	njs	Non	Lin	Pg	Lin	Ful	Rea
400	racket	883	0.1%	0	Mcr	rac	rac	rac	Lin	Pg	Lin	Raw	Rea
401	express-postgres	718	0.1%	0	Mcr	JS	njs	Non	Lin	Pg	Lin	Ful	Rea
402	klein	578	0.1%	0	Mcr	Py	Non	Twi	Lin	My	Lin	Ful	Rea
403	express-graphql-mongodb	492	0.1%	0	Mcr	JS	njs	Non	Lin	Mo	Lin	Ful	Rea
404	sailsjs	443	0.1%	0	Ful	JS	njs	Non	Lin	My	Lin	Mcr	Rea
405	http4k-netty	1	0.0%	657,083	Mcr	Kot	Nty	Non	Lin	Pg	Lin	Raw	Rea
406	amber	—	Did not complete	—	Ful	Cry	Non	Non	Lin	Pg	Lin	Ful	Rea
407	beetlex-core	—	Did not complete	—	Plt	C#	.NE	bee	Lin	Pg	Lin	Raw	Rea
408	falcore	—	Did not complete	—	Mcr	Go	Non	Non	Lin	My	Lin	Raw	Rea
409	ffead-cpp-mysql	—	Did not complete	—	Ful	C++	ffe	ffe	Lin	My	Lin	Ful	Rea
410	ffead-cpp-postgresql	—	Did not complete	—	Ful	C++	ffe	ffe	Lin	Pg	Lin	Ful	Rea
411	goji	—	Did not complete	—	Mcr	Go	Non	Non	Lin	My	Lin	Raw	Rea
412	hanami	—	Did not complete	—	Ful	Rby	Rac	Pum	Lin	My	Lin	Ful	Rea
413	hanami-unicorn	—	Did not complete	—	Ful	Rby	Rac	Uni	Lin	My	Lin	Ful	Rea
414	kami	—	Did not complete	—	Mcr	Go	Non	Non	Lin	My	Lin	Raw	Rea
415	cherrypy	—	Did not complete	—	Mcr	Py	Non	Non	Lin	My	Lin	Ful	Rea
416	cherrypy-py3	—	Did not complete	—	Mcr	Py	Non	Non	Lin	My	Lin	Ful	Rea
417	pronghorn	—	Did not complete	—	Plt	Kot	pro	Non	Lin	Mo	Lin	Raw	Rea
418	sailsjs-postgres	—	Did not complete	—	Ful	JS	njs	Non	Lin	Pg	Lin	Ful	Rea
419	quart	—	Did not complete	—	Mcr	Py	Non	hyp	Lin	Pg	Lin	Raw	Rea
420	sinatra	—	Did not complete	—	Mcr	Rby	Rac	Pum	Lin	My	Lin	Ful	Rea
421	sinatra-postgres	—	Did not complete	—	Mcr	Rby	Rac	Pum	Lin	Pg	Lin	Ful	Rea
422	spider-gazelle	—	Did not complete	—	Ful	Cry	Non	Non	Lin	Pg	Lin	Ful	Rea
423	spring-webflux-rxjdbc	—	Did not complete	—	Ful	Jav	Nty	Non	Lin	Pg	Lin	Mcr	Rea
424	spyne	—	Did not complete	—	Mcr	Py	spy	Non	Lin	Pg	Lin	Ful	Rea

 

原文：https://www.techempower.com/benchmarks/

本文：http://jiagoushi.pro/node/1118

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】