Recently, I encountered some problems, that is, the background as a service, separated from very atomic operations, while the BIZ layer is only responsible for pass-through services, resulting in a lot of business assembly and multi-request coupling in the front end. So this article will focus on the analysis of how to deal with this kind of problem more gracefully.
The root cause
In order to reduce coupling and facilitate independent management and subsequent expansion, the background will generally remove the business from the very atomic, especially the underlying services. For example, a common recommendation list might include these atomic services:
- Recommended interface, get recommended ID list;
- Details obtained by id;
- Comment information obtained by id;
- Wait, other atomization operations…
Then your architectural pattern might look something like this.
Problems brought about
Let’s start with the assumption that there is no BIZ layer at all and that these atomic services are handled by the front end, which gives you an idea of how much coupling the front end has to deal with. As a simple example, the interface for obtaining comment information in the background needs to be modified from the original 2 parameters to 3 parameters, but the overall page and data display structure remain unchanged. But then the development will tell you, there will be compatibility issues, the old version will not support this data, as a product you will be confused, I just changed the way to get the data, why is there a front-end relationship?
At this time you have to pull your leader a detailed statement, if it is the WEB but also ok, if it is the client is very troublesome.
The solution
This scenario requires a BIZ layer (BFF layer), through which interface requests are collected, and we adjust the top architecture to add a BIZ layer to handle them, such as the following aspects.
The front end only needs to request an interface called get recommendation list, and the BIZ layer combines the basic information of multiple services and returns it according to the data structure requirements of the front end.
Problems brought about
The above scheme is very comfortable for the front end, but performance is a very big problem for the biz layer in the background. As long as there is one slow interface of so many interfaces, the whole data acquisition may be slow, thus affecting the user experience. In particular, if we pull the home page interface and assume that the home page contains these modules:
- Home page icon;
- Operation bit information, such as banner;
- New module information;
- Recommendation list;
Assuming that all these are organized and generated by the back end, it is bound to cause the final effect of the interface to be very slow. For example, the recommendation interface will be slow, so all the information will be displayed very slowly, affecting the user experience. So how do you solve these problems?
A second, very serious problem is that the request is enlarged. Suppose we request a page interface, but the final request is enlarged because multiple requests are called.
Performance to solve
Based on the above questions, the first thing we need to do is distinguish between core and non-core modules of the front end. For example, the core of our APP is the home page icon; for example, song details are functions related to song playing; for example, product details are information related to product pricing and optimization; and for example, the core of live broadcast is live broadcast screen playing.
All we need to do is pull out the core interface.
- On the home page of APP, remove the icon interface from the home page;
- Song details, extract the address interface to get the song playing and part of the song to display the necessary details, such as title and cover;
- For product details, remove the title and pictures necessary to obtain the product, and remove the price display and coupon interface;
- Live broadcast room, pull out the address of the live broadcast interface and the title information of live broadcast.
After the interface is removed, it is analyzed according to whether the interface can be cached.
- Those that can be cached are not closely related to users or can be cached according to user groups. Most people obtain the same information, such as the icon of the home page, the playing address of the song, the downlink address of the live room, etc.
- Non-cacheable, such as recommending related services, or personalized, such as the user’s personal coupon list, personal history, and so on.
The cacheable part is analyzed after the cacheable and non-cacheable parts are separated
- Timing cache, which is similar to the operation of the configuration, directly generated timing configuration, this directly go to the timing cache.
- Access cache, which is similar to data that needs to be cached after a single user request, this part needs to be aware of the problem of cache penetration.
Three key
Core interface, independent interface, independent module
Interfaces are classified by cache and non-cache to improve service stability and performance
Caches need to be divided between timing caches and access caches
conclusion
Therefore, the division of interfaces at the front and back ends is not a single idea. Interfaces need to be divided according to the differences of various services. It is not a single interface to solve a page. Secondly, the definition of the interface protocol is not the background to determine the line, need to discuss the end together.
The above protocol formulation is based on a core, that is, the BIZ layer (BFF layer) must exist, and must not be simple pass-through.