**五个你该使用的前端后端工具，WunderGraph、Istio、AWS EventBridge、Clerk、Auth.js、Axiom、Grafana 等。了解那些让构建前端后端 (BFF) 变得轻而易举的工具。
在现代的网页和移动应用程序开发中，单一的通用后端 API 很快会因要处理多种前端数据消耗方式而变得过于庞大和复杂。任何权宜之计都会模糊前后端组件间的关注点分离，使代码库难以维护和扩展。
为了解决这些挑战，前端后端 (BFF) 模式应运而生，成为一种流行的解决方案。然而，设计良好的 BFF 涉及许多部分，开发者们常常发现自己在不断重新发明这些部分。
让我们来解决这个问题吧！在这篇文章中，我们将探索五个在构建 BFF 时你应该掌握的开发工具，了解每个工具如何缓解特定问题，以及你为什么需要它们。让我们开始吧！
WunderGraph 是一个免费开源（Apache 2.0 协议）的前端后端框架，允许你以声明式方式将你的数据依赖关系——微服务、数据库以及第三方 API——转化为一个安全、统一且可扩展的 API，通过 JSON-RPC 暴露。
这意味着什么？在构建网络应用时，一个常见的问题是管理数据依赖。随着应用的增长，由于需要将多个部分组合或拼接在一起，应用变得数据密集：
a) 不同的 APIs（GraphQL/OpenAPI REST），
b) 数据库（SQL，NoSQL，或通过像 Prisma 这样的 ORM），
c) 和身份验证提供商（Auth0、GitHub 等），
所有这些可以用不同的语言编写，使用不同的架构设计，并以不同的格式提供数据（许多旧式服务例如使用 XML 而非 JSON）。
管理这一切没有标准。BFF 模式帮助解决了一部分问题，每个前端有一个扮演反向代理角色的“后端”，但是实际上构建这些 BFF 也没有标准方法。没有什么能不涉及手动构建和整合多个层和横切关注点的。
这就是 WunderGraph 可以帮助的地方。
WunderGraph 是一个开源的、见解性的全栈开发工具，基本上是一个 BFF 框架，支持 Next.js、Remix、Nuxt、SvelteKit、Astro、Expo 等，允许你构建你想要的 BFF，而不是浪费时间重造轮子和粘贴样板代码。
WunderGraph 允许定义数据和身份验证依赖关系（基础的 SQL 和 NoSQL 数据库、GraphQL 或 OpenAPI REST APIs、gRPC、Apollo 联邦、OIDC 和非 OIDC 兼容的身份验证提供商等），这些可能是第三方服务、身份验证，或者是完全内部的服务，这些服务甚至没有对外暴露。
随后，WunderGraph 组合这些 APIs，将其汇聚并抽象为命名空间虚拟图，然后可以使用 GraphQL 或 TypeScript 操作从中获取数据，根据需要进行处理和转换，并通过类型安全的数据获取钩子（如果使用基于 React 的框架）或通过调用 JSON-RPC 端点从前端访问它们。
WunderGraph 模糊了 API 网关和 BFF 模式之间的界线，使 API 和数据源的组合就像使用软件包管理器 NPM 一样，而是针对数据依赖，简化所有开发人员的工作，无论他们在哪个领域工作：
-
前后端的解耦意味着前端开发人员可以针对模拟的或部分的 APIs 进行开发，从而加快开发速度和上市时间。你的 WunderGraph BFF 在这里增加了额外的安全层，因为这种解耦——加上 GraphQL 仅在开发中使用，而非生产中——意味着设计中的任何面向消费者的体验不必直接反映内部服务。
-
你可以有效地组合和整理来自各种来源的数据，而无需担心它们是如何实现的，也无需在前端/下游微服务中进行跨 API 数据连接。
-
WunderGraph 通过 RPC 以 JSON 形式提供数据；你不需要公开一个公共 GraphQL 端点。因此缓存、安全性等不是问题。
要开始使用 WunderGraph 构建 BFF，请查看这里。
Istio 是一个开源的服务网格，使你能管理、保护、控制所有微服务之间的通信，还可以增加可观察性，所有这些都无需你编写相关代码，无论你的分布式架构如何部署。
在微服务架构中，流量可以有两种方向：南北流量和东西流量。南北流量指的是网络集群内外流动的流量，如前端与后端服务之间的流量。东西流量则指的是网络集群内部服务之间的流量。
虽然 API 网关负责处理后端集群和前端客户端之间的南北流量，抽象掉实现细节，服务网格如 Istio 则专为东西流量而建，为集群内服务之间提供更可管理和安全的通信。
-
在微服务之间路由和整形流量，增加负载平衡和服务发现功能。这意味着你可以使用 Istio 实现 A/B 测试、金丝雀发布以及其他部署策略，而无需更改底层的微服务本身。
-
在后端服务之间提供安全性、基于角色的访问控制和加密，确保敏感数据被适当地隐藏，且对集群中任何微服务的请求是来自受信任源（身份验证）并被允许进行该请求（授权）的。
-
添加可观察性 - 分布式追踪、日志和服务所有组件的指标等。作为服务网格，Istio 默认监控集群内所有流量，因此将其用于任何和所有日志需求是显而易见的选择。
-
使微服务的独立测试更容易。 这些系统的分布式和互联特性使得复制和诊断问题变得更具挑战性。Istio 默认截获所有服务间流量，使其成为注入故障、延迟和其他条件的极好途径，以模拟不同场景并测试系统的响应。
-
提高系统弹性 - 如果由多个微服务调用的单个下游组件（例如数据库）失效，它可能会导致所有这些微服务随之失效。如果这些服务再失败，依靠它们的 API 网关就停止正常工作，并沿链进行传播。此外，如果这些下游组件之一运行缓慢，整个后端集群的响应时间就等于最慢下游调用的速度。服务网格如 Istio 可以通过以下方式解决这个问题：
-
自动重试直到调用成功，
-
实施电路断路器模式意味着在几次失败的重试尝试后，我们在一段时间内不再尝试该调用以避免拥堵。
-
限制速率确保我们的微服务不会泛滥下游调用。
总之，Istio 是管理基于微服务的应用程序的强大平台。它提供流量管理、安全和可观察能力，使得在不同平台和云环境中部署、管理和保护微服务变得更加简单。
无服务器计算 是一种云计算模型，在该模型中，你可以构建和运行应用程序而无需管理底层基础设施。如果你使用 Amazon 的 AWS 提供的多种服务，它将负责服务器管理、扩展和维护，这样你就可以专注于编写应用程序代码。
-
你无需进行基础设施的配置或管理 - 云提供商可以根据需要创建资源，这是托管服务。你不需要管理本地/裸机服务器/数据库。
-
服务器不是“真实”的物理实体，在你看来，它们可以随时被完全丢弃并重建，使得易于迭代和实验成为可能。
-
自动扩展 - 如果你的流量需求增加，会自动添加更多资源。
-
高可用、容错、安全 - 如果一个服务器出现故障，没有停机时间。可以立即启动另一个服务器来代替它。
-
按需付费，即只为你消费的部分付费 - 数据、计算资源、处理时间等。对于小型的、使用频率较低的后端服务特别有利，否则这些服务需要专用服务器来运转。
**一句话总结：**Amazon API Gateway（负责从前端到后端的路由请求）+ AWS Lambda（包含业务逻辑、数据转换或从后端处理数据的功能）+ DynamoDB（用于存储下游微服务的数据）。
当然，接下来的逻辑问题是，**如何收集您的下游微服务的数据并将其存入 DynamoDB 层？**以下是几个选项：
-
**使用 Webhooks：**下游服务将会使用 Webhooks（作为 HTTP 请求）将更新推送到您的 Lambda 函数。AWS Lambda Function URLs 使这个过程变得简单——您不需要额外的 API 网关。您的 Lambda 中可以包含 BFF 逻辑，这样就不需要事件驱动架构。
-
**使用事件消费者：**但是如果事件驱动架构更符合您的用例，并且您的微服务能够发布事件，您可以使用 Amazon EventBridge 收集这些推送的事件，并根据规则将它们路由至 Lambda 函数。
-
**使用轮询：**如果您的下游服务既不能进行 HTTP 请求，也不能发布事件？那么您需要手动轮询它们。一个适合此场景的 AWS 服务是 EventBridge Scheduler。通过它，您可以创建 cron 作业，手动触发 Lambda 函数来轮询下游微服务的 API 以获取数据。
剩下的问题是身份验证和可观察性，AWS 套件包含针对它们的解决方案，例如身份和访问管理 (IAM)、Web 应用程序防火墙 (WAF)、Cognito、Cloudwatch 等。总的来说，无服务器技术（特别是 AWS 平台）提供了一系列的服务和工具，使其成为开发 BFF 的理想选择。
Backend-for-Frontend 层是处理认证的理想场所，因为直接从公共前端客户端（即在浏览器中运行）进行认证和授权是有风险的。认证解决方案如 Clerk 和 Auth.js 使这变得更加容易：
a) 它们很容易集成到任何技术栈中，并且支持来自 Google、FB、GitHub 等提供商的单点登录（SSO）
b) 它们具有极高的定制化，可提供可定制的登录、注册和账户管理界面。
Clerk 提供了一种简单、安全、定期审计的最佳实践方式，使用即插即用的组件和页面将认证功能添加到您的应用程序中。它是专门为 JAMstack 构建的，支持 NextJS、Remix、RedwoodJS、Gatsby、React Native/Expo，并能与 Hasura、Supabase、Fauna、Firebase 和 Grafbase 等数据库集成。
Auth.js 与 Clerk 一样，用于 Web 应用程序中的认证。它是一个开源认证解决方案，最初仅为 Next.Js 应用程序开发，但现在支持其他框架如 Svelte 和 SolidJS，具有惊人的大量数据库集成。
Clerk 和 Auth.js 支持多种认证方法，包括邮箱和密码、社交登录（如 Google 和 Facebook）、单点登录（SSO）及多因素认证（MFA）。它还提供可定制的用户界面用于登录、注册和账户管理。
不论使用哪一个，这里的工作流程如下：
-
每当前端需要对用户进行认证或授权时，它会调用 BFF 的一个端点，比如 "/api/auth"。
-
BFF 使用 OpenID Connect (OIDC) 或其他方法对用户进行认证，生成 ID、访问和刷新令牌。
-
令牌被缓存，并且一个加密的 Cookie 被发给前端，代表当前用户的会话。
-
每当前端需要访问下游服务的数据时，它会将加密的 Cookie 传递给 BFF，BFF 从缓存中提取访问令牌，并将其包含在授权头中调用下游 API 或微服务。
-
下游服务将响应返回给 BFF，BFF 将其转发给前端。
Clerk 和 Auth.js 可以轻松地通过其 JavaScript API 和 React 组件集成到您的 Web 应用程序中。它还提供灵活且可定制的 API，允许您构建自定义的认证流并将它们集成到您的后端 API 和服务中。
💡 如果您使用 WunderGraph，例如，它可以将 Clerk 和 Auth.js 集成到 WunderGraph 的 API 服务器前，并明确要求认证来执行任何查询、变更或更新。想了解更多，请查看这篇文章。
为您的 BFF 添加可观察性对于理解和解决应用程序中的问题、做出优化和扩展的明智决策是至关重要的。
您不需要为此自行开发解决方案——使用如 Axiom、Grafana 和 Datadog 这样的工具，通过追踪响应时间、错误率和资源使用等指标，识别和诊断 BFF 中的问题，并在这些指标超过定义的阈值时接收警报。
Axiom 是一个数据管理和分析平台，允许组织收集、管理和分析来自不同来源的海量数据。该平台旨在为用户提供对数据的全面视图，使他们能够做出更明智的业务决策。
Grafana 是一个开源分析和可视化平台，可让您监控和分析来自各种来源的数据，包括数据库、云服务和 IoT 设备。Grafana 可以帮助您为您的应用程序和基础设施创建交互式、实时的仪表盘和警报。
Datadog 是一个基于云的监控和分析平台，提供对应用程序、基础设施和日志性能的可见性。该平台旨在实时收集、处理和分析大量数据，并提供见解和可视化，帮助用户处理问题、优化性能和提高整体效率。
这些服务甚至可以协助您可视化收集到的数据，设置仪表盘来实时监控指标，以及迅速识别到值得关注的趋势。
💡 它们甚至可以与如 AWS 和 Azure 的无服务器和云平台集成，就像之前提到的那样，如果您的 BFF 使用无服务器技术。
惊讶吗？不用惊讶！这些主要是用于全栈开发的框架，是的，但它们也可以按照定义用作 BFF。
如何做到的呢？这些框架提供必要的基础设施和特性来创建一个专门的后端应用（通常是 NodeJS 层）用于每个前端，与之紧密耦合，由前端团队自行管理，并与前端一同部署——也就是 BFF 的理想定义。
对于 NextJS，这采用 API 路由 的形式，而对于 Remix，则是 Loader 模式。如果您的项目或应用程序已经有一个成熟的后端，使用 PHP、Ruby、Elixir 等（即非 JavaScript）的代码，则两者都可以作为 BFF 层的绝佳选择。
总之，Backend-for-Frontend（BFF）模式使开发复杂的、现代的、多平台的 Web 应用程序变得更容易，但对于开发人员来说，一个常见的痛点是浪费时间来重新发明轮子，为 BFF的各个部分实施临时解决方案，并将样板代码拼凑在一起。
希望本文谈及的五种工具能帮助您简化开发、提升开发者速度，并让您无论支持哪个平台都能提供最佳的用户体验。
虽然像 Istio（用于微服务编排的服务网格）、AWS（用于构建无服务器 BFF 模式）和 Clerk/Auth.js（用于认证）这样的工具帮助您解决构建 BFF 的个别痛点，WunderGraph 则作为一个全能的 BFF 框架，就像 Next.js 一般是用于 React 开发一样。
