在传统 REST API 数据源和 Falcor 客户端之间优化 node.js falcor 路由器

Posted 2023-03-08

【中文标题】在传统 REST API 数据源和 Falcor 客户端之间优化 node.js falcor 路由器

【英文标题】：Optimising a node.js falcor router between a traditional REST API data source and a Falcor client

【发布时间】：2017-03-02 16:22:43

【问题描述】：

我有一个传统的 REST API，它返回如下数据：

用户列表 - GET /users.json

users: [
    id: 0, name: "John Smith",
    ...
]

用户 ID - GET /users/0.json

user: 
    id: 0,
    name: "John Smith"

如您所见，如果您首先从列表 (/users.json) 请求数据，然后单击用户，即使该信息存在于第一个列表中，也会通过以下方式向用户重新请求id 请求。

在 Falcor 中，这将通过在第一次调用中包含引用列表来解决。

我的问题是，如果我正在编写一个 Falcor 路由器来充当中间人，我该如何优化这样的场景？目前，路由器必须请求完整的用户列表，然后抛出信息并根据 id 将引用列表返回给客户端。这仍然可以节省客户端的带宽，但在 Falcor 路由器及其数据源 (REST API) 之间不是最理想的。

【参考方案1】：

可以解决这种情况，但首先，我想解释一下为什么您会看到这种不匹配。这是因为 Falcor 尊重 REST 原则，但您的 API 没有。 REST 声明来自 API 的数据应该是可缓存的。如果它同时驻留在两个地方，则它不能被缓存。比如我去PUT或者PATCH/users/0.json，客户端怎么知道这个操作对/users.json（不同的资源）有影响，并使其缓存失效？这不可以。在完全兼容的 HTTP REST API 和 Falcor API 中，数据仅驻留在一个地方，然后可以通过 refs 链接到它。对于 HTTP，refs 是 URL，因此对 /users.json 的 GET 调用应以 ["/users/0.json", "/users/1.json"] 之类的 URL 列表进行响应。

也就是说，这并不意味着你不走运。

您可能希望在 Falcor 方面拥有这样的路线：users[integers:indices][keys:props]。在此路由的处理程序中，您可以查询 pathSet.indices 并查看实际请求了多少索引。如果只有一个（或很少），则将请求转发至/users/$indices[i].json，否则将其转发至/users.json。

【讨论】：

是的，不幸的是我不对原始 API 负责，所以我的问题是关于如何处理糟糕的情况！

但这给我留下了更多问题 - 我知道理想情况下 /users/ 或 /users.json 应该以参考列表作为回复。但另一方面，如果您使用它来填充用户列表，实际上提供列表中的大部分数据不是更有效吗？ （考虑到显示的用户表有大约 10 列）。如果您只返回一个引用，则浏览器（或 Falcor 中间人，但这里的问题较小）必须每页发出 1 个请求 + 每个用户发出 1 个请求，很容易达到 100 或 1000 次调用来填充表格.

是的，它应该是这样工作的。 REST 意味着很多请求，但缓存可以弥补。我并不是在暗示 REST 在任何方面都更好，我只是想解释 Falcor 和您的 API 之间的不匹配。您可以观看来自 Netflix 的 Jafar Hussain 的 Falcor 演讲之一，它包含对 REST-vs-RPC 风格的 HTTP API 的很好的概述。这是一种权衡。

我查看了它并决定添加第二个 API 版本来服务 Falcor。解决原始 API 的麻烦是不值得的。使用 jsonapi 规范，稀疏字段集提供了 Falcor 所需的内容（GET /users/?fields[users]=id 仅返回 id 属性，没有其他内容）