Salesforce中文网

背景与应用场景 在传统的 Salesforce 开发与集成中，我们主要依赖 REST API 和 SOAP API 进行数据交互。尽管这些 API 功能强大且成熟，但在某些场景下却面临着挑战。最常见的两个问题是 Over-fetching（过度获取） 和 Under-fetching（获取不足） 。 Over-fetching 指的是客户端从服务器获取了超出其需要的数据。例如，一个移动应用的用户信息卡片可能只需要显示客户（Account）的名称和电话，但标准的 REST API 端点（如 /services/data/vXX.X/sobjects/Account/{accountId} ）可能会返回该客户的所有可访问字段，这不仅浪费了带宽，也增加了客户端的处理负担。 Under-fetching 则恰恰相反，指的是一个 API 端点无法提供客户端所需的所有数据，导致客户端需要发起多次请求。想象一个复杂的 Lightning Web Component (LWC) 需要展示一个客户（Account）及其所有关联的联系人（Contacts）和进行中的业务机会（Opportunities）。使用 REST API，开发者可能需要至少发起三次独立的 API 调用：一次获取客户信息，一次获取联系人列表，再一次获取业务机会列表。这种“请求瀑布”会显著增加页面加载时间，影响用户体验。 为了解决这些痛点，Salesforce 引入了 GraphQL API 。GraphQL 是一种由 Facebook 开发并于 2015 年开源的 API 查询语言和运行时。它允许客户端精确地声明其数据需求，然后由服务器返回一个不多不少、结构完全匹配的 JSON 响应。这赋予了前端开发者前所未有的灵活性和控制力，使其成为构建现代、高性能应用程序的理想选择。 主要应用场景包括： 复杂的 LWC 或 Aura 组件： 当一个组件需要聚合来自多个关联对象的数据时，GraphQL 可以通过一次请求完成所有数据获取，极大地简化了前端逻辑并提升性能。 移动应用开发： 在网络环境不稳定的移动场景下，精确控制数据负载至关重要。GraphQL 的“按需索取”特性可以最小化网络传输量。 第三方系统集成： 当集成方的数据需求频繁变化时，GraphQL 的灵活性使其无...

背景与应用场景 在 Salesforce 平台的开发生态中，数据交互是构建任何复杂应用的核心。多年来， REST API 和 SOAP API 一直是开发者与 Salesforce 数据交互的主要方式。然而，随着前端应用（如 Lightning Web Components - LWC）和移动应用对数据需求的日益精细化，传统 API 的一些弊端也逐渐显现： 1. 数据过度获取 (Over-fetching): 当客户端只需要一个对象的少数几个字段时，标准的 REST API 端点往往会返回整个对象的全部可访问字段。这不仅浪费了网络带宽，也增加了客户端的处理负担。例如，为了显示一个客户列表（仅需名称和行业），REST API 可能会返回每个客户记录的几十个字段。 2. 数据获取不足 (Under-fetching): 当客户端需要来自多个关联对象的数据时（例如，一个客户及其所有联系人，以及每个联系人最近的三个订单），通常需要发起多次独立的 REST API 请求。这种“N+1”查询问题会导致网络延迟增加，应用响应变慢，用户体验下降。 为了解决这些痛点，Salesforce 引入了 GraphQL API 。 GraphQL 是一种由 Facebook 开发并开源的 API 查询语言和运行时。它允许客户端精确地声明其数据需求，然后由服务器返回不多不少、完全符合该需求的数据结构。这使得它成为构建高性能、数据驱动型应用，尤其是复杂前端界面的理想选择。 Salesforce GraphQL API 的典型应用场景包括： 复杂的 LWC 或 Aura 组件： 当一个组件需要同时展示来自父对象和多个子对象层级的数据时，使用 GraphQL 只需一次网络请求即可获取所有需要的数据，极大地简化了前端逻辑并提升了性能。 移动应用开发： 在移动网络环境下，带宽和延迟是关键考量因素。GraphQL 的精确数据获取能力可以最大限度地减少数据传输量，从而加快应用加载速度并节省用户流量。 第三方系统集成： 当外部系统需要从 Salesforce 中拉取特定、结构化的数据集时，GraphQL 提供了一种比组合多个 REST 请求更高效、更灵活的集成方式。 原理说明 Salesforce GraphQL ...