Shulou(Shulou.com)06/02 Report--

This article mainly explains "how to understand and support the back-end of the front-end". The content in the article is simple and clear, and it is easy to learn and understand. let's study and learn how to understand and support the back-end of the front-end.

Microservices customized by the client

What is it?

The back-end-to-back architecture pattern describes a world in which each client application has its own server-side component-the back end of a particular front end.

This model works well if you have multiple client interfaces that have completely different requirements and all consume the same underlying resources. The most common example in the real world is an application with both Web and mobile clients.

To understand why the back end is useful to the front end, let's take a step-by-step look at some developments in the network architecture.

Multiple clients on a single general-purpose server

> Monolithic application with multiple clients (source: author)

Just keep it simple, okay? Actually, it's just. But only at a certain point. If your application is small enough, this architecture will definitely work! However, the whole material tends to decompose with size. You may hear your team start to say something like...

Our server is too bloated! Customer-specific control flows are everywhere, and we are trying to add features without introducing side effects.

I cannot commit any changes without merge conflicts. N teams are changing this exact code. Something we hardly ever talk to!

Builds and tests will run forever, while debugging an intermittent test failure will take several days.

These types of problems catalyze the rise of microservices.

Multiple clients with micro-service architecture

> Microservices! (source: author)

If microservices are implemented within the appropriate scope, microservices are well suited for scaling up and helping to solve a range of problems.

Back-end teams are usually responsible for a service instead of tripping over each other.

A single microservice is lightweight, customizable, separate, and easy to extend.

However, there are still boundary issues between front-end teams. The responsibility to handle multiple clients is still encoded in one or more services. Front-end engineers are trying to cram multiple use cases into a single API layer, and the customer experience is starting to suffer. Tensions between online and mobile teams are rising.

Why can't we draw technical and organizational boundaries around different customers as we do with microservices?

Multiple clients with dedicated backend and microservice architectur

> BFF! (source: author)

Enter the back end to change the front end! We take advantage of the fact that our customers have different needs to draw useful boundaries. BFF applications are lightweight translation layers that separate a single client from downstream services and serve only one front end.

Benefits of BFF

Front-end teams can enjoy ownership of their client applications and their underlying resource consumption layer; leading to rapid growth.

The mobile team will eventually be able to make changes, such as payload size and frequency reduction, without having to extend and dispatch the API originally developed for Web-based use cases.

Client applications only need to know one resource server-encapsulation rules!

BFF is customer-specific, one-dimensional and language-independent. Choosing the right API technology has never been easier.

Client applications are protected from API changes in downstream services.

Web and mobile teams no longer fight over who merges first and who has to deal with merger conflicts.

TL; DR, if... , then use BFF

You have multiple clients with different needs that are using the same underlying resources.

You want to optimize the back-end API, data processing, or technology stack on a per-client basis.

Your customers need to use data that requires a lot of back-end aggregation.

The development team has conflicts over functional delivery and can benefit from increased autonomy.

... But make sure to avoid these traps.

Replicate logic across BFF. The copy code is multiple instances of the same code that solve the same use case and will undergo the same changes. For example, execute specific business rules.

Do not follow good DevOps practices. More backends mean more deployable services and increased operational complexity.

Inadvertently convert your BFF into a full-featured API server that contains business logic, database, security, and kitchen receivers. Keep BFF lightweight and focus on the main use case: efficiently converting data to customers.

The fact that your BFF cannot be recognized or adjusted is a single point of failure. The fact that your BFF may communicate with many services means that any failure of downstream services can be propagated to your BFF. Consider using redundancy and asynchrony to solve these problems, just like using other types of microservices.

Thank you for your reading. the above is the content of "how to understand the back-end of supporting the front-end". After the study of this article, I believe you have a deeper understanding of how to understand the back-end of the front-end architecture pattern, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.