Micro Frontend - Ideation of Micro Services in UI - Knoldus Blogs

Ideation of Micro Services in UI

Reading Time: 2 minutes

The frontend is becoming bigger and bigger by each day in web applications. The growing requirements in the frontend space make the scalability in frontend a bit difficult.

The term Micro Frontend came in picture in late 2016 at ThoughtWorks Technology Radar. It extended the concept of micro-services to the frontend world. The current trend states to build a powerful and feature-rich browser-based application, in simple words, Single Page Application (SPA) that sits on the top of micro-service. Over time when the application is developed by different teams grows, it gets more difficult to maintain. This is what was known as Monolith Frontend.

The idea behind the Micro Frontend is that each feature should be owned by separate teams. Each team has a distinct area to work on and specializes in that only. The separate team is responsible to develop that feature end-to-end, i.e., from the database to the user interface. The best part of creating these micro frontends is that we can develop our every micro frontend in different language or framework, irrespective of what others are using. For example, we have an e-commerce website that needs to be developed, the category or product view can be made in Angular whereas our cart functionality can be in React. This way each team can choose to work on their own favorite framework or language.

Core Ideas behind Micro Frontend

1. Be Technology Independent – Each team should be able to choose and upgrade their technology stack without having to coordinate with other teams. Custom elements created provides a neutral interface to others and also hides the implementation stack details.
2. Isolate Team Code – Never share the runtime even if all the teams are using the same framework. Build an independent application that is self-contained and do not rely on shared state or global variables.
3. Create Team Prefixes – Use naming conventions where isolation is not possible. Namespace CSS, Local Storage, Events, Cookies, etc. to avoid collisions and clarifying ownership.
4. Favor Native Browser Features over Custom APIs – Instead of building a global PubSub system, use the browser events for communication. If there is a need to create custom API to interact between two teams, try to keep it as simple as possible.
5. Build a Web Design that is resilient – The features should be useful even if JavaScript fails or does not get executed. To improve performance, use Universal Rendering or Progressive Enhancement.

What is needed to create a Micro Frontend Application?

To create a Micro Frontend Application, following is needed:

1. A shared codebase in pure JavaScript which maintains routing, user sessions, and other commonly needed things.
2. A collection of separate modules, i.e., our mini-apps which are blocks of our main application. They can be built in different frameworks and stored in different repositories.
3. A deployment system that bundles all the modules together from all our repositories and deploys to the server, whenever a module gets updated.

Conclusion

We saw that micro frontend is a great way of achieving isolated features independent of each other and at the same time working in conjunction with each other.

At the same time, we should also make sure to keep the core and integrations as simple as possible. One of the critical problems is to standardize UI/UX principles. A solution to that is to use a style guide, like, Material Design, Bootstrap, etc. Also, communication with the team, creating standards and rules are the essentials to ensure that everything runs smoothly and minimize the conflicts with the different teams working on one product.

At the end of the day, all the solutions are meant to solve one problem – Scalability.