我们可以更挑剔我们想要的数据

mdruhul13

因此如果我只需要一个有一百个对象的四个字段，我将能够真正查明这些字段，而不必将数据加载到，或者我应该说的所有数据加载到您的设备中，因为这是很多额外的工作，尤其是对于您的手机。


画：我在过去看到并使用过 REST API，它们有一个可选字段，您可以在其中传递您想要返回的数据列表，或者您可以用额外的东西来增加返回的内容。所以我想这就是确定这个问题，不是吗？也就是说，您并不总是希望每次都返回相同的数据。那么是不是 GraphQL 形式化了允许前端指定后端将返回什么数据的方法？

前夕：是的，完全正确。所以你的查询就变成了你如何询问、如何过滤、如何从任何地方获取任何类型的信息。

前夕：我还认为重要的是要注意我们不必拆除所有 REST API 才能真 阿联酋电话号码列表 正成功地使用 GraphQL。我见过很多最成功的 GraphQL 实现，它们都是 REST API 的包装器。GraphQL 查询确实为您提供了一种思考所需数据的方法。然后也许你的一些数据来自我们的用户和产品，例如，一些数据来自 REST，一些来自数据库。

画：我想熟悉的场景是，您的网站上可能有一个端点，它返回有关用户的信息以显示标题。它可能会给你他们的用户名和头像。然后你在每个页面上剔除它并填充数据，但是你发现你的应用程序中的其他地方你需要显示他们的全名。

画：所以你把它添加到端点，它开始返回它。然后你做你的账户管理部分，你需要他们的邮寄地址。所以那个端点也会返回。

画：在您不知不觉中，该端点返回了整个繁重的有效载荷，在后端将其组合在一起的成本很高，而且显然要下载很多。

画：并且在每个页面上都被剔除以显示头像。所以我想这就是那种随着时间的推移而增长的问题，它很容易陷入，特别是在大团队中，GraphQL，它是解决这个问题的首要问题。它知道如何解决这个问题，并且它是围绕解决这个问题而设计的。



前夕：确切地。是的，我认为 GraphQL Schema 的整个想法，我认为真的，它比 GraphQL 的查询语言部分更少被谈论。但我真的觉得 Schema 特别为我们提供了这个很好的 API 类型系统。

前夕：所以团队中的任何人，经理，前端开发人员，后端开发人员，任何真正处理数据的人都可以聚在一起，围绕我们真正想要在这个 API 上提供的数据进行合并，然后每个人都知道真相的来源是什么也就是说，他们可以基于此构建自己的应用程序部分。
前夕：因此，随之而来的还有一些棘手的模式管理问题。但就从微服务回到整体而言，我们正在这样做，但仍然从微服务中获得我们喜欢的所有好处。

画：我是否理解正确，设置 GraphQL 系统的典型方法是基本上只有一条路线，这是您将所有查询发送到的端点，因此您不必……通常是最困难的路线之一事情正在解决命名什么，以及这个特定查询应该在什么路径。是回馈用户和产品，是砍掉用户什么的，还是砍掉产品什么的？

画：使用 GraphQL，你只有一个端点，你只需将查询发送到该端点，你就会得到适当的响应。