java前端后段_前端的建筑模式后端

java前端后段

它是什么？(What is it?)

The backends-for-frontends architectural pattern describes a world in which each client application has its own server-side component— a backend for a particular frontend.

后端到后端的架构模式描述了一个世界，每个客户端应用程序都有自己的服务器端组件—特定前端的后端。

This pattern is highly applicable if you have multiple client interfaces with significantly different needs that all consume the same underlying resources. The most common real-world example is an application that has both a web and a mobile client.

如果您有多个具有完全不同需求且都消耗相同基础资源的客户端接口，则此模式非常适用。 现实世界中最常见的示例是同时具有Web和移动客户端的应用程序。

To understand why backends-for-frontends is useful, let’s walk through some evolutions in web architecture.

为了理解为什么后端对前端有用的原因，让我们逐步了解一下Web体系结构的一些发展。

单个通用服务器上有多个客户端 (Multiple clients with a single general-purpose server)

Simplicity is great, right? Actually, it is…but only up to a point. If your application is small enough this architecture can absolutely work! However, monoliths tend to break down with scale. You might hear your teams start to say things like…

简单就好吧？ 实际上，这只是……但仅限于某一点。 如果您的应用程序足够小，则此体系结构绝对可以正常工作！ 但是，整料倾向于随尺寸分解。 您可能会听到您的团队开始说类似……

• Our server is so bloated! Client-specific control flow is littered everywhere and we are struggling to add features without introducing side effects.
  我们的服务器太肿了！ 特定于客户的控制流程随处可见，我们正在努力添加功能而不引入副作用。
• I can’t commit any changes without merge conflicts. There are N teams changing this exact piece of code; some that we barely talk to!
  没有合并冲突，我无法提交任何更改。 N个团队正在更改此确切的代码。 一些我们几乎不交谈的东西！
• Builds and tests are taking forever to run and it’s going to take us days to debug that one intermittent test failure.
  构建和测试将永远需要运行，并且调试一个间歇性测试失败将花费我们数天的时间。

These types of problems catalyzed the rise of microservices.

这些类型的问题催化了微服务的兴起。

具有微服务架构的多个客户端 (Multiple clients with a microservices architecture)

Microservices! (source: author)

微服务！ (来源：作者)

Microservices, when implemented with proper boundaries, are great for scale and help solve a bunch of problems.

如果在适当的范围内实施微服务，那么微服务非常适合扩展规模并有助于解决一系列问题。

• Backend teams are typically responsible for a single service and are no longer tripping over each other.
  后端团队通常负责一项服务，而不再互相绊倒。
• Individual microservices are lightweight, customizable, decoupled, and readily extensible.
  单个微服务是轻量级的，可定制的，分离的，并且易于扩展。

However, there are still boundary issues amongst frontend teams. The responsibility of handling multiple clients is still encoded in one or many services. Frontend engineers are struggling to jam multiple use-cases into a single API layer and the customer experience is beginning to suffer. Tension is growing between the web and mobile teams.

但是，前端团队之间仍然存在边界问题。 处理多个客户端的职责仍然编码在一项或多项服务中。 前端工程师正在努力将多个用例塞入一个API层，并且客户体验开始受到影响。 网络团队和移动团队之间的紧张关系正在加剧。

Why can’t we draw both technical and organizational boundaries around disparate clients, the same way we’ve done for microservices?

为什么我们不能围绕微不足道的客户划定技术和组织界限，就像我们对微服务所做的一样？

具有专用后端和微服务架构的多个客户端 (Multiple clients with dedicated backends and a microservices architecture)

BFF! (source: author)

BFF！ (来源：作者)

Enter backends-for-frontends! We’re using the fact that our clients have very different needs to draw helpful boundaries. The BFF applications are lightweight translation layers that decouple individual clients from downstream services and serve only a single frontend.

输入后端换前端！ 我们利用这样一个事实，即我们的客户有非常不同的需求来划定有用的界限。 BFF应用程序是轻量级转换层，可将单个客户端与下游服务分离开来，并且仅服务于一个前端。

BFF的好处 (Benefits of BFF)

• Frontend teams get to enjoy ownership of both their client application and its underlying resource consumption layer; leading to high development velocities.
  前端团队可以享受其客户端应用程序及其底层资源消耗层的所有权； 导致高速发展。
• The mobile team is finally able to make changes such as payload size and request frequency reduction without having to extend and fork APIs originally developed for web-based use-cases.
  移动团队最终能够进行更改，例如有效载荷大小和降低频率，而不必扩展和派发最初为基于Web的用例开发的API。
• Client applications need only be aware of a single resource server — encapsulation rules!
  客户端应用程序只需要知道一个资源服务器-封装规则！
• BFFs are client-specific, single-dimensional, and language agnostic. Picking the right API technology has never been easier.
  BFF是特定于客户的，一维的且与语言无关。 选择正确的API技术从未如此简单。
• Client applications are protected from API changes in downstream services.
  客户端应用程序受到保护，免受下游服务中API的更改。
• The web and mobile teams are no longer fighting over who gets to merge first and who has to deal with the merge conflicts.
  网络和移动团队不再为谁首先合并以及谁必须处理合并冲突而战。

TL; DR，如果... ，则使用BFF (TL;DR, Use BFF if…)

• You have multiple clients with different needs that are consuming the same underlying resources.
  您有多个具有不同需求的客户端正在使用相同的基础资源。
• You want to optimize backend APIs, data handling, or tech stack on a per-client basis.
  您希望基于每个客户端优化后端API，数据处理或技术堆栈。
• Your clients need to consume data that require a significant amount of aggregation on the back-end.
  您的客户需要使用需要大量后端聚合的数据。
• Development teams are clashing on feature delivery and could benefit from increased autonomy.
  开发团队在功能交付方面存在冲突，可以从增加的自主权中受益。

…但请确保避免这些陷阱 (…but make sure to avoid these pitfalls)

• Duplicating logic across BFFs. Duplicated code is multiple instances of the same code that solves the same use-case that will be subject to the same changes. For example, the implementation of a specific business rule.
  跨BFF复制逻辑。 复制代码是同一代码的多个实例，这些实例解决了相同的用例，并且将经历相同的更改。 例如，执行特定的业务规则。
• Not following good DevOps practices. More backends mean more deployable services and increased operational complexity.
  不遵循良好的DevOps惯例。 更多的后端意味着更多的可部署服务和增加的操作复杂性。
• Inadvertently converting your BFF into a full-blown API server complete with business logic, a database, security, and the kitchen sink. Keep your BFFs lightweight and focus on the main use-case: efficient data translation to your clients.
  无意间将您的BFF转换为功能完善的API服务器，其中包含业务逻辑，数据库，安全性和厨房接收器。 使您的BFF轻巧，并专注于主要用例：高效地将数据转换为客户。
• Not recognizing or adjusting for the fact that your BFF is a single point of failure. The fact that your BFF will probably talk to many services means that a failure in any downstream service likely propagates to your BFF. Consider tackling these issues with redundancy and asynchronicity —just as you would with other types of microservices.
  无法识别或调整您的BFF是单点故障的事实。 您的BFF可能会与许多服务通信的事实意味着任何下游服务的故障都可能传播到您的BFF。 考虑使用冗余和异步性来解决这些问题，就像使用其他类型的微服务一样。

The backends-for-frontends pattern can help scale your architecture AND your organization. Give it a shot and let me know how it goes in the comments below!

从后端到前端的模式可以帮助您扩展体系结构和组织。 试一试，在下面的评论中让我知道如何进行！

翻译自: https://medium.com/frontend-at-scale/frontend-architectural-patterns-backend-for-frontend-29679aba886c

java前端后段