This is the first in a series of posts that will explore the concepts and practices for implementing Micro Frontends.
Several weeks ago, I came across a LinkedIn article that talked about Micro Frontends. I was intrigued by the concept, but the article wasn’t much use to me; it didn’t fit my learning style. I’m the hands-on type. I learn best if I can write the code, fix the bugs, etc.
After just a little searching I came across this site:
Micro Frontends – extending the microservice idea to frontend development (micro-frontends.org)
I liked the content, so I bought the book, which I found to be very thorough and helpful.
Micro Frontends allow you to divorce a micro-service from the UI of the applications that consume the service. By delivering the UI component as a part of the micro-service, the consuming application no longer needs to concern itself with the presentation of the data. And the service becomes completely independent; it has its own deployment cycle, which means it can deliver enhancement, bug fixes etc. as needed without impacting the cycles of any application that consumes its service.
It doesn’t matter if the consuming application is a “traditional” multi-page application, a SPA or a Progressive Web Application with a thin-client installed on the user’s machine.
Micro Frontends are merely an evolution of time tested and familiar concepts such as, Visual Studio Extension and Browser Plugins. In the WPF world, similar isolation is achieved with User Controls. Where the UC is a stand-alone project that is incorporated in other solution.
The essence of Micro Frontends is a set of very easily understood principles/concepts:
- Each micro-service produces the UI that is needed to interact with that service.
- Each micro-service has its own development team.
- Each micro-service is developed independently of any other micro-service.
- Coordination between should be kept to a minimum.
The idea here is that every micro-service will be completely independent of any other service. This isolation improves site reliability by:
- Preventing system wide bugs.
- Allowing individual services to release bug fixes as soon as they are available rather than waiting for the entire site to push to production.
- When critical bugs are encountered, only the affected service needs to be rolled back.
- Standardize namespacing and Teams related prefixing makes tracing run-time errors much easier and more reliable.
This independence also improves adaptability. Each service can push new features on the schedule that works best for them and prioritize those enhancements based on their unique priorities.
Remember, this is not a one-size-fits-all architecture. It is geared towards large to medium sized applications. Even on a medium sized application, it may not be a good fit.
Here is a short list of some major companies that are using this approach: Spotify, Dazn, OpenTable, Ikea, Skyscanner, Zalando and Amazon.
Let’s take a closer look at each of the principles mentioned above.
A Service Provides its UI
Many services require information to be gathered before the service is invoked. Many also produce data that needs to be displayed. Each service should provide the UI for the data it requires and to display the data it produces. There are many ways to do this e.g. code fragments, Components, individual pages to name a few. We will discuss the various approaches in upcoming posts.
Independent Development Teams
Each service has a team that operates independently of all other teams. They have their own codebase, change management system, development and test environments and release cycles. They are free to use whatever technology stack best suits their needs.
No Inter-Service Dependencies
Anyone who has worked on large applications that have a lot of moving parts has seen issues introduced via shared/common code and interdependencies between libraries: Jack updates a shared library to fix a bug or make an enhancement and now Sally’s module is broken because a function Jack changed longer supports her use-case.
Making service and separate project that doesn’t share code with any other service, eliminates those types of issues.
Minimal Coordination
When an application is composed of multiple services that each provide their own UI, some coordination is required. You want to maintain a consistent look and feel, otherwise you won’t have a polished, professional looking application. A few things that you should agree upon and coordinate may include:
- Color schemes and UI styling conventions. For example, are we using rectangular buttons or rounded ones?
- Calling conventions. Are we using hyperlinks, or Components, or iframes, or AJAX?
- How are we namespaces and/or prefixing our classes and components to make ownership clear for debugging and tracing?
In the next post we will look at some of the ways you can incorporate Micro Frontends into a modern web application. Feel free to post comments or questions. I’ll try my best to respond in a timely fashion.
Martin's Tech Corner 