17 From Backend to Frontend - How to Design Microservices for Backend and Frontend #
Hello, I’m Oscar Chuangxin.
Microservices architecture often adopts a front-end and back-end separation design approach. As a enterprise-level middleware, after completing the split of monolithic applications and the construction of microservices, the front-end project team will face multiple middleware microservice project teams at the same time. At this point, front-end developers are like maintenance electricians.
How can we correctly connect and assemble the APIs exposed by so many microservices to ensure that there are no errors? This is obviously not an easy task. And when there are changes to the services, how can we notify all the affected project teams? The communication cost involved in this process is also considerable.
Correspondingly, to some extent, can we consider first effectively reducing the complexity of front-end integration? Achieving front-end aggregation and back-end decoupling - this is an interesting topic. Today, let’s discuss the design thinking of Micro Frontend and explore the design and integration methods of the front-end and back-end after middleware microservices.
The dilemma of monolithic frontend #
After completing the transformation to the middle platform, traditional enterprises have upgraded the backend to a microservices architecture. However, the frontend still remains in a monolithic mode, with one team creating and maintaining a frontend application. As time goes by and the business develops, the frontend will become more and more bloated and difficult to maintain. With the application of 5G and mobile internet technology, business activities of enterprises will further shift towards mobility and online platforms. In the past, many companies developed separate apps for different businesses. However, it is obvious that users do not want to install so many apps!
In order to improve user experience and achieve unified operations, many enterprises have started to reduce and integrate apps, consolidating all the business capabilities of the company into a single app. Just imagine if the design pattern of monolithic frontend is still used. The frontend project team will face multiple middle-platform microservices teams, and will need to integrate thousands of API services, resulting in high communication costs and technical requirements. This will undoubtedly be a disaster.
Compared to internet companies, traditional enterprises have more diverse channel applications, including store-related applications for internal staff, internet e-commerce platforms or mobile apps for external customers, and API integrations for third parties. Due to the differences in channels, the frontend becomes more diversified and complex. So how can we effectively reduce the complexity of frontend integration?
From Monolithic Frontend to Micro Frontends #
To address the problems of monolithic frontend architecture, we can draw inspiration from the design principles of microservices and introduce the concept of micro frontends. By extending the concept of microservices to the frontend, we can solve the issues of complexity and bloatedness that arise when the backend undergoes a transition to a microservices architecture while the frontend remains a monolith.
When designing the frontend, we should adhere to the principles of single responsibility and code reuse. Following the domain model and boundaries of microservices, we can divide the frontend pages into smaller pieces. These individual pieces can be composed into multiple micro frontends, each responsible for a specific business unit’s UI elements and functionality. These composed micro frontends are analogous to microservices.
Similar to microservices, the goal of micro frontends is to decompose the monolithic application and reassemble it into smaller, loosely-coupled units that can be independently developed, tested, deployed, and maintained. This architecture caters to the requirements of rapidly changing business needs and enables parallel development by multiple distributed teams.
A micro frontend only includes the essential elements needed for a specific business unit’s frontend operations. It is merely a puzzle piece in the enterprise-level complete business process and does not include navigational elements. In addition to decoupling frontend pages, micro frontends also enable code reuse, aligning with the concept of shared services in the middle tier.
Combination Forms of Business Units #
We can refer to the domain model and microservice boundaries to establish a frontend operation interface corresponding to the microservices. We can combine it with microservices to form business units, and provide services externally in the form of business components. Business units include micro frontends and microservices, which can be developed, tested, deployed, and maintained independently. They can independently complete some or all of the business functions in the domain model.
Let’s take a look at the following diagram. A dashed box represents a business unit, and micro frontends and microservices are deployed independently. The micro frontends and microservices within the business unit have completed frontend and backend integration. You can understand this business unit as a component of a specific business domain. Business units can be combined in various ways to achieve different business objectives.
1. Single Business Unit #
A micro frontend and a microservice make up a single business unit. The micro frontend and microservice respectively implement the frontend-to-backend functionalities of the same domain model.
2. Composite Business Unit #
A micro frontend is combined with multiple microservices to form a composite business unit. The micro frontend has frontend functionalities of multiple microservices, and completes more complex pages and operations. Multiple microservices implement the functionalities of their respective domain models and provide composable services to the micro frontend.
Remember: it is not advisable to combine too many microservices with a micro frontend, otherwise it may easily become a monolithic frontend.
3. Universal Shared Business Unit #
A micro frontend is combined with one or more universal middleware microservices to form a universal shared business unit. The universal shared micro frontend collaborates with other micro frontend pages by sharing pages to complete business processes. Many micro frontends of universal middleware microservices are shared, such as the order and payment micro frontends corresponding to the order and payment microservices.
The functionality of all business units should be self-contained, and the boundaries between business units should be clear. Business units should avoid functional overlaps and couplings between them. Once they occur, they will affect the responsibilities of project teams and subsequently affect the independent development, testing, deployment, and maintenance of business units.
Integration Approaches for Micro Frontends #
Let’s take a look at the diagram below. Micro frontends are situated between the main frontend page and microservices, and it needs to integrate with both.
1. Integration with the Main Frontend Page #
The main frontend page is an enterprise-level frontend page, while the micro frontend is a frontend page for a specific business unit. Through the micro frontend loader on the main page and technologies like page routing and dynamic loading, the micro frontend page for a particular business unit can be dynamically loaded into the main frontend page, achieving a “jigsaw-like” integration between them.
Once the micro frontend is developed, integrated, and deployed, it can be dynamically loaded into the main frontend page by registering and configuring page routing.
2. Integration with Microservices #
Micro frontends are developed and deployed independently from microservices. Before registering with the main frontend page, the micro frontend needs to integrate with microservices. The integration approach is no different from the traditional frontend-backend separation. Microservices publish their services to the API gateway, and the micro frontend calls the services published in the API gateway, thus achieving the frontend-backend integration within the business unit.
Team Responsibilities and Boundaries #
When adopting a business unit-oriented development approach, the responsibilities and application boundaries of frontend and backend project teams become clearer, which can reduce the complexity of frontend-backend integration. Let’s take a look at the division of responsibilities within the frontend and middle-tier teams.
The frontend project team focuses on integrating the main frontend pages with micro frontends. They are responsible for building the enterprise-level main process pages and process orchestrations, as well as dynamically loading the micro frontend pages to ensure the correctness of the main process business logic and flow. In addition to designing the overall style of enterprise pages and controlling the flow of business processes, the frontend project team is also responsible for implementing frontend technologies such as dynamic loading of micro frontend pages, micro frontend registration, page routing, and page data sharing.
The middle-tier project team is responsible for the development, testing, and integration of business unit components to ensure the correctness of the business logic, pages, and processes within the business units. They provide business unit components that include both page logic and business logic.
This way, the frontend project team only needs to integrate the enterprise-level frontend main pages with the business unit components, focusing solely on the integration between the frontend main pages and micro frontend pages. This reduces the technical sensitivity, communication costs, and integration complexity of the frontend team, thereby improving delivery efficiency and user experience.
The middle-tier project team focuses on the completeness and self-contained capability of the business unit functionality. They develop, integrate, and deploy microservices and micro frontends within the business units, providing business unit components. In this way, the integration of micro frontends and microservices within the business units is handled by a dedicated middle-tier team, allowing familiar individuals to work on familiar tasks. This reduces communication and technical costs during the integration process and accelerates development efficiency.
A Case Study on Micro Frontends Design in Insurance #
Insurance companies have many insurance products targeting different scenarios. Due to the differences in business scenarios, their core domain models may also differ. The front-end interfaces, including page elements, business rules, and workflows, will vary as well. To avoid the mutual impact and interference between products with significantly different domain models, we can aggregate insurance products with similar domain models together and complete the core platform design.
However, some insurance groups implement centralized operations to achieve the sales of various types of insurance, such as life insurance and property insurance. In this case, the front-end project team needs to use a single front-end application that integrates a large number of core platform microservices for different products. The integration between the front-end application and the core platform microservices will be more complex.
If we still adopt the traditional monolithic front-end approach, we will encounter significant challenges.
First, there is the complexity of front-end development and design. Taking the policy creation front-end as an example, if we use a single front-end page to accommodate all types of insurance, we will need to compromise and accommodate the differences in front-end page elements for different products. This will increase the complexity of front-end development and also affect the user experience. On the other hand, if we develop different front-ends for each type of product, the front-end project team will need to invest a significant amount of effort in page development and design.
Second, there is the complexity of front-end and microservices integration. When integrating the front-end with microservices, the front-end project team needs to understand the detailed API information of all products, complete the integration between the front-end and microservices, and implement different product API service routing according to the main page workflows. The extensive integration of API services and service routing will increase the complexity of system integration and the possibility of errors.
Third, there is the coordination of front-end and back-end software version releases. As the number of associated applications increases, if there are significant adjustments to an API service of a microservice, it is necessary to coordinate the simultaneous version releases of all affected applications. Frequent version releases can disrupt the normal operation of different products.
So, how can we achieve the sales of various types of insurance using a single front-end application? How can we design it to reduce the complexity of integration, achieve front-end interface consolidation, and decouple the back-end core platform?
Let’s take a look at the diagram below. We draw inspiration from the e-commerce order model to implement the sales of various types of insurance products through a single front-end interface, seamlessly connecting all business processes and operations. Although there are many business units (including microservices and micro frontends) in the back-end, users always feel like they are interacting with a single front-end application.
To achieve the sales of various types of insurance through a single front-end application, the following design aspects need to be considered.
1. Microservices #
Microservices are divided into two categories: core platform microservices, including insurance application microservices that implement core policy issuance business logic, and general microservices, including services for products, orders, shopping carts, and payments, which implement shared business logic.
2. Micro Frontends #
Each microservice has its own micro frontend page, which implements front-end operations for the corresponding domain model. The core platform insurance application microservice has its own policy issuance micro frontend. The order, product, and payment microservices also have their own micro frontends.
3. Business Units #
Microservices and micro frontends combine to form a business unit. A core platform team is responsible for the development, integration, testing, and deployment of each business unit, ensuring the correctness of page operations and business logic within the business unit. For example, the insurance application microservice and the policy issuance micro frontend combine to form an insurance application business unit, which independently handles the policy issuance process from the front-end to the back-end for insurance products.
4. Front-end Main Page #
The front-end main page serves as a portal, including page navigation and shared pages such as the shopping cart. The front-end main page and all micro frontends should have a consistent interface style, conforming to unified front-end integration specifications. Following the correct business logic and rules, the front-end main page dynamically loads micro frontends of different business units. As a whole, the front-end main page coordinates the micro frontends of core and general business units, completes business operations and flows, and provides an interface for sales of various types of insurance, including product catalogs, policy creation, shopping carts, orders, and payments.
5. Business Process Description #
Let me briefly explain the main business process of insurance policy creation on the front-end main page.
Step 1: Users select insurance products from the product catalog micro frontend page on the front-end main page.
Step 2: Based on the selected product, the front-end main page retrieves the policy issuance micro frontend routing address from the main page’s configuration data. The policy issuance micro frontend page is loaded to complete policy creation. The insurance application microservice implements the policy issuance business logic, generating a policy within the business unit.
Step 3: The shopping cart micro frontend is loaded to add the policy to the shopping cart.
Step 4: Steps 1-3 are repeated to generate multiple policies.
Step 5: From the shopping cart micro frontend, select multiple policies, load the order micro frontend, and generate an order.
Step 6: Load the payment micro frontend and complete the payment.
Step 7: In the insurance application microservice, generate policies based on the policies in the order.
Although there are many business units supporting the back-end, all user interactions and flows are completed on a single front-end main page. When conducting sales of various types of insurance through the order model, users always feel like they are interacting with a single system. This design effectively demonstrates the consolidation of the front-end and the decoupling of the core platform.
Summary #
Today we mainly discussed the design methodology of micro frontends. Although both micro frontends and microservices adopt the design approach of separating the front-end and back-end, within the scope of the business unit, they implement front-end and back-end business logic respectively under the same domain model and provide componentized services externally.
Micro frontends and the modular design pattern of business units can alleviate the complexity of enterprise-level middleware, front-end and back-end application development, and integration, truly achieving front-end integration and middleware decoupling. Its main values and significances are as follows:
1. Simplified front-end integration: Front-end projects only need to focus on integrating the main page with micro frontends, achieving modular integration and puzzle-like development, reducing the complexity and cost of front-end integration.
2. Specific project responsibilities: Middleware projects complete end-to-end development of domain logical functions from databases, middleware microservices to micro frontend interfaces, providing services as a whole in the form of business components. Within the business unit, the front-end and back-end integration is completed by the team, which can reduce communication costs and integration complexity within the development and integration teams.
3. Isolation and dependencies: Business units are isolated in terms of code, logic, and physical boundaries, which can reduce dependencies between applications. When problems occur, they can be quickly identified and fixed, and the issues can be contained within a business unit. There is no impact between business units.
4. Reduced communication and testing costs: The middleware team realizes the logical development of the business unit from the micro frontend page to the middleware microservice, and manages the full process and lifecycle of the development, testing, integration, and deployment of the business unit as a whole, reducing the testing and communication costs of front-end and back-end integration.
5. Faster releases: There is good isolation and low dependencies between business units, and the changes in business units can be controlled within the respective units. Project teams can independently iterate and develop at their own pace, achieving faster release cycles. The release of a version will not affect the normal operation of other business units.
6. Reduced technical sensitivity: Front-end projects focus on integrating the main page with micro frontends, reducing the sensitivity of the front-end project team to the technology of the middleware microservices. The middleware project team can more independently explore new technologies and architectures, achieving architectural evolution.
7. High reusability: Both micro frontends and middleware microservices have a high degree of reusability. Micro frontends can be quickly loaded into multiple apps, and can also be directly released as apps or WeChat mini-programs, achieving flexible front-end combination, reusability, and rapid deployment.