后端和前端之间经常存在大量摩擦,而 GraphQL 可以轻松解决这些摩擦。
译自 GraphQL Federation: The Missing API for Your Platform Strategy,作者 Michelle Greer。
平台工程 已成为释放云原生架构中开发人员速度的关键学科。从使用 Terraform 和 Kubernetes 配置和编排基础设施到使用无头 CMS 提供的前端微文案,工程团队正在选择集中式平台来维护其架构的核心组件。这些工具不仅消除了冗余任务,还使产品工程团队能够更快地交付功能、以更少的工作量进行实验,并减少对基础设施的关注,更多地关注业务需求。
自动化基础设施配置和安全策略比以往任何时候都容易。在 ChatGPT 使“ AI 功能” 突然成为每个应用程序的必需品一年半后,现在出现了无数的“AI 基础设施即服务”公司。但是,云原生架构的关键要素:API 呢?
虽然无数工具简化并自动化了现代云原生架构 的其他核心组件,但我们仍然依赖于单独的手写后端到前端 (BFF) 来向每个前端提供后端的所有功能。
除非 AI 可以使用 REST 自行编写后端到前端的蔓延(可以吗?),如果我们想要减少样板代码并在所有界面中更快地交付功能,我们将需要一个更好的解决方案。
对于正在尝试 GraphQL 的个人 API 开发人员来说,GraphQL 似乎是一种减少客户端过度获取和获取不足的新颖方式。但是,当大规模交付时,GraphQL 也为提高工程团队的开发人员速度提供了关键要素。GraphQL 减少了前端和后端之间的摩擦。在大规模交付时, GraphQL 联合 使 API 平台团队能够将任意数量的 API 公开为一个自服务且自文档化的图形,称为“超图”。此超图抽象了 API 复杂性,并将前端与后端解耦,使两个团队都能更快地工作。
它的工作原理如下:
GraphQL 联合通过以下方式支持更好的平台策略:
当您考虑平台策略时,请记住它超越了基础设施。后端和前端之间通常存在很多摩擦,您可以使用 GraphQL 轻松解决这些摩擦。下载“API 的平台工程”白皮书,了解为什么 GraphQL 正迅速成为 API 平台团队采用的语言,以提高开发人员效率和速度。