BFF — Backends For Frontends. In my later study and work experience, I gradually deepened my understanding of BFF. This mode has more precise application scenarios and solves more specific problems. In this essay, starting from finding the origin of BFF, back to the background of the birth of BFF mode, to explore what kind of problems encountered in that special environment led to the emergence of this highly visible mode in the micro-service system.

To find the source

First of all, from technology, radar (www.thoughtworks.com/radar/techn… Some clues can be found in the BFF entry. The entry was published on November 10, 2015. Then, we Backend for Frontend in Google and set the time range from January 1, 2015 to November 10, 2015.

Next, the contrast results of time, I find the earliest Backend for Frontend entry articles (philcalcado.com/2015/09/18/…

As mentioned in the article, the name BFF was proposed by then-team TechLeader Nick Fisher (twitter.com/spadgos)… BFF mode is available on SoundCloud (zh.wikipedia.org/zh-hans/Sou… First occurrence. Then, let’s go back to the scene where BFF first came into its own.

At the beginning of problems now

To get a better sense of what SoundCloud’s challenges were, I broke them down into categories.

  • Background:

    • SoundCloud (blog.sellfy.com/make-more-m… Primarily through paid subscriptions and advertising (the more exposure there is, the more opportunities there are for SoundCloud to monetize)

    • SoundCloud is a monolithic system that serves Web clients, Android and iOS applications, the Internet, partners and more by exposing shared apis. These shared apis grow with functionality and features, eventually becoming integration points between the platform and the client.

    • Will start running 2007 SoundCloud paradigm shift from monomer to micro service mode (specific transformation process: philcalcado.com/2015/09/08/… At this point, the single service has been split into multiple microservices.

    • Support for new applications on the IOS platform (the original product was primarily a Web service)

  • Main motivation:

    • Reduce product launch time

    • Support for new applications on the IOS platform, isolating the risks associated with their different user experiences and interaction patterns

  • The challenge:

    • In order for third-party developers to integrate more freely, apis need to be designed that make no assumptions about how data will be used. As a result, many HTTP apis are required to serve even a simple experience. This results in hundreds of API requests to get the data needed to build a simple page.

    • Every time the team needed to change an existing API, it needed to make sure the change didn’t break any of our existing clients (including important third-party integrations). Whenever new content is added, a significant amount of time must be invested to ensure that the new functionality is not over-leveraged to a particular client so that all customers can easily use the new functionality. All this coordination makes the daily grind much harder than it should be, which leads to a slow release of new features.

    • Start developing new iOS apps, and the user experience of the apps on the new platform will be completely reshaped

    By analyzing the above scenarios, we can see the following issues facing the SoundCloud back-end team at the time:

  • Problem 1: It is difficult to provide an APPROPRIATE granularity of API for each third-party customer, resulting in too fine granularity of API data, and too many apis need to be requested to complete a business service.

  • Problem 2: Serious coupling between existing external APIS and consumers, high maintenance cost, long time, and slow release of new functions.

  • Problem 3: The new client of IOS platform has advanced user experience and interaction mode, so it is necessary to isolate the risks brought by the new App and find a better way to cooperate with multiple client teams.

    It seems that these three issues are common for back-end teams to encounter in their microservices transformation. Let’s take a look at how they solved the problem step by step and found the internal solution of BFF.

Backends For Frontends

The SoundCloud back-end team was very professional in dealing with these complex issues. They decided from the beginning to attack each one by providing different apis for different clients. Avoid repeating the mistake of having multiple clients rely on the same SET of apis, with overlapping coupling requirements and no flexibility to change. Meanwhile, back end Tech Lead Nick Fisher coined the acronym BFF, which was also voted in by the team. BFF finally emerged on the technology stage, with the architecture shown below.

You’ll notice some subtle differences from the current architecture diagram using the BFF pattern. That’s right, BFF hasn’t really evolved into mature mode yet. Let’s look at the circumstances under which it evolved.

In subsequent development the client team realized. Because they have apis, they can extract all the logic for making multiple calls to different services and mix it into user profiles on the back end. This simplifies code and improves performance. Instead of multiple different calls to the back-end service, a client simply requests a single resource, for example:

  • GET /user-profile/123.json

    As the back-end team experimented further with this approach, they found themselves writing a lot of Presentation models in BFF. At this point, they suddenly realized that the BFF wasn’t just an API being used by clients, but that the BFF itself was part of the application. A new form of BFF appears, as shown below:

Tick-tock, the clock moves on, and SoundCloud’s BFF continues to grow. At this point, they were maintaining five BFF’s simultaneously in production. To further improve productivity, reduce unnecessary duplication. The User Profile is extracted from each of the different microservices to become a separate application service between service and BFF. Over time, they found more and more of this. Now that SoundCloud’s BFF has clearly grown over time, this lateral growth no longer causes any problems. Finally, the ARCHITECTURE of the BFF pattern becomes the following:

conclusion

The BFF pattern provides a good way to solve the problem of multi-client development when using microservices. It allows us to control our own destiny as we build the client-facing back end. This autonomy is critical to iterating through client applications quickly and providing a good experience quickly. By supporting continuous evolution and change, this model limits consumer behavior to a manageable range, making it easier for them to cooperate and change. In addition, it can better meet the different feature requirements of different clients. If everything is expected to be reusable from the start, maintenance and coordination of the system will be a huge challenge. This is especially true in scenarios where you need to maintain multiple clients or consumers. Focus on your functionality and specific use cases before thinking about generic usage. Then on the basis of understanding the situation, low cost and reasonable general and reuse are gradually carried out.