Micro Front Ends — The Conflict TERMINATOR
This article is co-authored with HsinTzu and Hydra, please find their Medium profiles at the end of the post
DBS operates across multiple markets, including Singapore, India and China. Each market has its own DBS Bank app, credit card app, and the development teams also span across the region, with those working in IT numbering in the thousands.
With the complexity of the business and number of people working in development teams, the intricacy and scale of the programming can lead to an exponential increase in the development time and cost. This is where decoupling and common modularisation come in.
Without modularisation, the same function will be executed in different places in different ways. For instance, modification of the function for balance inquiry may cause the function for wire transfer to break down. Every time version control takes place, there might be programme code conflicts as well as difficulties with unit testing.
Through modularisation and compliance with SOLID and DRY principles, we can avoid the challenges above, and if properly applied, we can even improve work efficiency and productivity, as well as reduce the chances of fallouts with colleagues due to programme code conflicts.
Introducing Micro Front Ends
Here, we will also explain how Micro Front Ends (MFE) can be used, what to consider when applying MFE, and share some of its key principles — with the most important one being that it has to be applied according to actual requirements.
In general, a large software project applies the concept of modularisation — where duplicate functions, screens and logic are packaged together — to facilitate sharing and reduce coupling. This offers several benefits:
1. It leads to functional independence, conforming to the SOLID design principle.
2. Functions can be developed in parallel, without affecting one another.
3. Each module can be replaced easily.
4. The test scope will be smaller and more convenient to test.
5. Redundancies across projects can be minimised and costs for communication and conversion are lower.
We frequently apply the MFE design approach at DBS for both, public website and mobile applications.
As the above picture shows, the user interfaces (UI) of DBS mobile applications comprise various MFE components. These components are maintained by different development teams. The key UIs are generally referred to as “core”, and all DBS applications can use these core UIs. The composition and logic of the UIs fall to the developers under the project squad, and the developers responsible for the function develop the programme logic for the UI.
Dependency inversion principle
It is a standard procedure to import and reference function libraries between platforms, and the most common, Maven or Carthage, are used to create private clouds and repositories. When you inject non-UI type common modules, such as error handling, logic control, domain use case, you can apply SOLID’s dependency reversal to protect the injected libraries, preventing the circumstance where there is a feature that needs to be modified one day.
Functions suitable for the adoption of MFE:
Before adopting MFE, we should first assess if the function is an independent one with no dependency on other functions.
For example, member account management functions that are suitable for MFE include changing the account number, changing the password, and changing personal information..
These functions are independent, do not interact with other functions, have their own API endpoints, and do not need to share data with other functions.
Functions NOT suitable for the adoption of MFE:
The shopping cart function is an example of one that is not suitable for MFE since this needs the payment function at the end. However, the reverse might not be true: The payment function may not depend on the shopping cart function. The shopping cart’s dependency on the payment function makes it unsuitable for the adoption of MFE.
Some MFE principles for reference
For the design pattern, we go for the model-view-view model (MVVM) for development. Each development team can choose any pattern, but it is recommended to have a consistent pattern.
We always see MFE as a small independent app, so it does not expose the details of the MFE unrelated to the host app, preventing the situation where others might misuse the details when they take over the development. For that to happen, complete access control is necessary. Implementing a public interface, designing the UI of the MFE, and adding some small notes or documentation on how to use it will ensure that the MFE is properly used in a multi-developer environment.
The MFE we make will not send requests. If we leave the responsibility of sending requests to the MFE, it will cause the app to send APIs everywhere, which will not only duplicate programme codes, but also increase the difficulty of maintenance. After the host app receives the endpoint from MFE, the host app will send the request.
In special cases, the MFE may need to refer to another library. For example, if we want our UI to adopt the same style, we can put all UI components into a library for easy reference by the host app and all MFEs. In this instance, the account MFE should not contain the UI component library and can only refer to the UI component library of the Host App through the account MFE, assuming an umbrella structure.
Each MFE should be presented with a simple example so that other developers can quickly understand the role of the MFE and how to use it. Also, if the MFE needs to be modified due to changes in requirements, the effect of the changes can be seen immediately through the build example, so each example needs a mock response for testing to simulate the response of API and present the complete functionality.
Last but not least, for the purpose of reusability, we will make the MFE a module that can be used on other apps. Let’s take the example of the aforementioned member account management. If other apps have the membership function, we can also use the membership management MFE directly on these other apps so that each MFE will need its own independent repo to be used in other places.
Managing MFE ：
We have created a project to manage MFEs centrally on BitBucket, which we’ve selected for its ease of use. Also, we use Carthage to install or update these MFEs.
Besides that, we add a script in every MFE with which to create a new repo on BitBucket to aid in tasks such as pushing to BitBucket, checking that the project name is in the right format, exporting frameworks, and more.
We manage MFEs through the practices of Continuous Integration/Continuous Delivery (CI/CD), which allows us to deploy a few versions of MFEs — this means we can modify an MFEs at will without worrying that it will affect other MFEs or projects.
Conclusion:
We have thus far explained how the use of MFE can help with decreasing the chances of programme code conflicts, development principles and the basic management required for the implementation of MFE. Here, it is important to note that there are no hard and fast rules. There can be some flexibility in how you decide to deploy the use of MFE, as long as you keep the principles of modularisation and SOLID in mind.
(This article is also translated in Traditional Chinese Language:
微前端模組-衝突終結者- GordonFeng - Medium)
Co-authors:
Hydra: https://medium.com/@hydrawork
Hsin: https://medium.com/@hsintzuyen
