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!
- 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应用程序是轻量级转换层，可将单个客户端与下游服务分离开来，并且仅服务于一个前端。
(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.
- 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.
- Client applications are protected from API changes in downstream services.
- 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.
- 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.
- Not following good DevOps practices. More backends mean more deployable services and increased operational complexity.
- 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.
- 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.
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!
从后端到前端的模式可以帮助您扩展体系结构和组织。 试一试，在下面的评论中让我知道如何进行！
java前端后段
