网络上的数据获取仍然很糟糕

2021年，网络上的数据提取仍然很糟糕。这太疯狂了！

如果您要大规模构建网络应用，则可以使用多种方法进行数据管理：

但是这些都不是一件好事。要成为一个好的数据获取库，您需要做些什么？

提取数据时的一致性。当您的应用获取新数据时，UI会在使用该数据的所有地方自动更新。

要求批量处理。如果同时发出多个请求，则在合理的情况下应将它们合并为一个请求，以避免达到浏览器施加的并发限制。

避免网络瀑布。在获取组件的数据时，您也应该发出一个包含其所有后代数据的请求，以避免大量的网络往返。 GraphQL用片段解决了这个问题，但在现代客户端中仍然很痛苦（例如，Relay通过要求您在React树上手动组成片段以便将它们一起提取，然后将片段指针传递到树下以告诉Relay在哪里寻找，来做到这一点。提取数据；它还需要一个编译步骤）。

提取数据时的UX。工程师必须手动添加加载微调器和错误状态，这是一个沉重的负担，而工程师常常会忘记。

托管。您应该声明数据依赖关系，使其靠近使用位置，最好是在同一文件中。与将CSS与组件并置在一起的原理相同。

文件大小。您不必为了描述数据而将千字节的描述数据模式的元数据发送给客户端。

类型安全。您的代码应知道从服务器获取的数据类型。

实时更新。有时，您希望数据被推送而不是被推送（例如，用于通知之类的东西）。但是，在客户端和服务器上，用于推入和拉出数据的API通常是不同的。

更新数据时的一致性。当您更新一条数据时，您的数据获取库应自动重新获取在请求完成后将更改的相关数据（例如，如果您更新Person.FirstName，Person.FullName，则应自动重新获取）。

乐观更新。如果服务器很有可能成功执行请求，则用户界面应乐观地在服务器响应返回之前呈现成功状态。这使您的UI感觉敏捷而有趣。当今的数据提取库使这项工作变得很繁琐。

请求排队。相互依赖的请求需要排队。独立的请求可以并行发送。否则，网络天气和服务器排队可能会导致您的客户端最终处于与服务器不一致的状态。

更新数据时的UX。 产品工程师不需要手动呈现加载微调框以及成功和错误通知。 更新数据时的耐用性。 重试用于网络故障的幂等请求和幂等令牌的指数退避； 渴望持久化磁盘以防止客户端/服务器故障。 类型安全。 对于无效的一些定义，您不应将无效的输入发送到服务器。 我认为这个问题尚未解决的原因是，这是一个棘手的问题，是一堆快速发展的技术的交集： 到目前为止，解决数据获取的任何尝试都紧密地结合了所有这些层，从而导致难以获得大规模采用（想想Meteor）。 其他解决方案仅解决了一层问题，而忽略了其余部分。 这对我来说就像是抽象和香气。 每一层的API都是错误的：您不需要紧密耦合即可解决数据提取问题。 相反，您需要更好的抽象。