Intro
A few months ago I have participated in the NDC Copenhagen conference together with my friend James Strachan. Together we have presented how to use micro-frontends to boost agility in a GxP regulated environment.
In this article I will go over the key points of our presentation and help you get achieve a high level of integration between applications which by their nature have been independently validated. If you are interested in our full presentation you can check it out here:
What is a regulated environment?
If your business operates in a heavily regulated industry like pharmaceuticals, finance or aeronautics you have probably encountered the concept of good practice (GxP). The 'x' represents the domain, whether it's manufacturing (GMP), distribution (GDP), laboratory (GLP), and so on.
A regulated environment is basically any controlled environment. There are rules that state which conditions must be met to produce valid results or goods of a guaranteed level of quality.
That means that at some point we should be able to demonstrate to an auditor what has been deployed or what has been deployed in the past. That we respected all the necessary approvals for deployments between environments and that we have executed full non-regression testing when necessary. As you can imagine this is a necessary but a time-consuming process.
Monolithic frontend problem
The frontend monolith is a common problem, especially arising in the enterprise applications. While the backend is usually designed to be modular these days, the frontend is still being developed as a single codebase.
In other words, while the backend is split in terms of responsibility and knowledge, the frontend remains a large monolith, requiring knowledge about the whole backend. Even worse, making changes in a single backend service may require a frontend change that comes with a new release.
As a design consequence the frontend becomes the bottleneck since it eventually becomes too hard to maintain, it is too quickly outdated, and has way too many components and responsibilities.
What is a micro-frontend?
Micro-frontends have no defined framework or API, they are an architectural concept. The main premise behind them is splitting your application into several smaller apps, where each app is focused on a single feature.
This architecture can be applied in many ways. It can be as liberal as possible, where each app could be implemented with different frameworks, or it could be more prescriptive, defining and providing tools and enforcing design decisions. There are benefits and downsides to both approaches, and they largely depend on your organisation’s needs.
An important thing to highlight regarding micro-frontends,
despite splitting the app into several projects, to the end user it all must appear to be one app, not many.
Micro-frontends take the microservices architecture concept from the backend engineering, and apply it to frontend development. But how can splitting the UI into multiple frontends help to scale your project?
Micro-frontends
Conway's Law states that “Organizations, who design systems, are constrained to produce designs which are copies of the communication structures of these organizations.”
The larger a project becomes, the longer it can take for that project to build. By splitting your app into several different projects, each with their own build pipeline, each project will be very quick to build, regardless of how your system grows.
Let's take a look into three largest benefits of using micro-frontends in a regulated environment.
Composable
The microapps within a micro frontend offer plug-and-play capabilities, making it easy for those components to be utilized across multiple applications, or to be seamlessly integrated with new applications without disrupting the larger app ecosystem.
As mentioned earlier an app built with micro frontends may be composed of many smaller, independent parts, but it shouldn’t appear that way to the user. A good micro frontend will be able to deliver a seamless user interface that can seamlessly accommodate many different user journeys while providing a consistent user experience.
Loosely coupled and isolated
Splitting your frontend into separate projects opens the possibility of having multiple teams working on the UI. Each team can be responsible for one feature of the system and have their own repositories. They can run deployments whenever they want, with their own versioning and changelogs.
Micro-frontends allow each team to be responsible for their applications unit, integration, and end to end tests, including their quality processes.
For the most part, these teams don’t need to know anything about each other. There still however needs to be a point of integration between these two apps. Each team needs to define and guarantee backwards compatibility on a public API. This API is typically implemented using the URL or by defining integration contracts between the teams.
Independently deployable
One of the nicest features about micro-frontends, is the ability to deploy new features without the need to recompile anything else. This enables many benefits such as independent deployments, migration, experimentation, and helps us build resilient applications.
Imagine if you have an existing system, rather than shipping and re-installing an entire system, you only need to ship and install the newest feature. This can be incredibly powerful and opens many new distribution possibilities.
Summary
In order to reduce administrative overhead and increase agility for regulated app development and deployment we have decided to utilize micro-frontends. By slicing our application we divide the workload amongst the teams and promote an agile approach to a regulated application development.
There are many challenges that come with micro-frontends such as a learning curve, or a how to slice a team to extract the maximum benefit. But for us these challenges are minor comparing to the benefit we get.
PS. you can find the example of how we are using the MFEs in the video above.
Let me know if you have any more questions in the comments
Learn more about me on my web kovacevic.dev
Give me a follow on Twitter/@CtrlArchiDel
Top comments (0)