Micro Front-End Architecture at Enterprise Scale (Updated July 2020)

tldr;

• Micro front-ends enable you to compose your front-end and structure your business domains into re-usable and manageable chunks.
• Your enterprise can be aligned with your business domains.
• Technical debt can be deprecated and removed in a controlled way over time.
• Micro front-ends and federated APIs are intrinsically linked. There should be a natural alignment with your business domains.
• Simplicity and low-level standards are essential for a micro front-end architecture to ensure success, agility and to prevent technical debt.
• Consistency for the customer and delivery must prevail over change, fragmentation and time.

Introduction

This article tries to compress years of experience in enterprise architecture into a useful guide with a focus on micro front-end architecture.

I tried to keep it reasonably brief and within these four chapters:

Fundamentals is a deep dive into the background knowledge necessary to understand enterprise scale environments, organizations and structures.

Micro front-ends is an exploration of the nature, requirements and constraints of micro front-end architecture.

Principles will guide our decision making for the actual micro front-end architecture.

Example web micro front-end architecture according to our fundamentals and principles.

Conclusion

Fundamentals

To really understand the concepts and reasoning behind micro front-end architecture, one has to analyze it in the context of enterprise environments. While ever changing technology and the inevitably complex legacy stacks are often the drivers for people to look at micro front-end solutions, we have to go deeper into the nature of enterprise scale organizations to really understand the potential and challenges of micro front-end architectures.

Enterprise environments

To be considered enterprise scale, multiple of the following attributes would have to apply.

• Dozens of delivery teams working across
• numerous business domains with
• hundreds of business solutions (or features) within
• a huge and usually diverse legacy code and technology base

Those attributes already imply the challenges enterprise scale organizations face.

Delivery teams

Due to the nature of enterprise organizations, delivery teams usually experience a lot of people movement. Delivery team members switch between teams, change roles, leave and getting replaced by new starters. The result is constant loss of knowledge and the need for retraining. This becomes even more challenging in organizations where delivery teams work across multiple domains and technologies.

Groups, Streams, Tribes, Verticals, …

To help delivery teams to focus, reduce cognitive load and enhance ownership, enterprises often organize delivery teams in groups aligned to the major business domains.

While this improves the delivery teams situation, it also introduces new challenges. Most business domains are not strictly separated but rather overlap in many areas.

Business domains

Like any company enterprises sell products to their customers. Customers pay for solutions that solve their problems. Enterprises usually offer huge amounts of business solutions and organize them within business domains. This gives structure and reduces cognitive load on the customer as well as on the enterprise.

It is essential for an enterprise to properly identify and understand the customers problems and requirements. These might change over time, but properly identified, the resulting major business domains and solutions are very stable and long lasting.

The Business domains are the foundation that allows us to organize the enterprise in a meaningful and productive way.

We can structure our teams, streams, tribes, verticals as well as all our business solutions according to our business domains.

Business Solutions

The enterprise exists to sell products to customers that can solve their problems. Each customer problem and requirement can be properly identified and refined in an agile process. The result is a business solution that can be build and sold to the customer as part of a product.

Business solutions should fit naturally into the business domains. Sometimes a business solution might fit into multiple business domains. This is where business domains overlap.

Business solutions are the building blocks of all products. Initially a business solution might actually contain multiple business solutions that could be re-usable. In this case the re-usable parts should be taken out and turned into individual business solutions. This gives much more clarity, avoids duplications, enables re-usability and improves productivity for the entire enterprise.

Micro front-ends

Business Solutions represent the smallest building blocks of the enterprise products. But they are purely business contracts describing customer expectations.

Micro front-ends are the actual customer facing implementations of business solutions.

Resources

To be able for a micro front-end to implement and fulfill the requirements of a business solution it must have access to all the necessary resources.

At enterprise scale we need a unified approach for all micro front-ends to access resources. This allows teams to focus and work on the essential value of the business solution and micro front-end.

Resource APIs

Micro front-ends access resources using APIs.

At enterprise scale APIs must be aligned with the business domains. This ensures clear ownership and structure.

Sometimes it might be tempting to align APIs with individual business solutions and micro front-ends. This is an anti-pattern which eventually leads into a huge mess of duplication, redundancy, dependency chaos and technical debt.

Resource API Federation

An enterprise with clear business domains will have groups, teams, tribes, verticals that take ownership of each domain. They are the experts of those domains and they build the necessary APIs for their specific domain.

Business solutions and micro front-ends often require resources from several business domains.

A naïve approach would be to let micro front-ends directly access multiple business domain APIs. This is an anti-pattern which eventually leads into a huge mess of unmanageable dependencies, prevents deprecation and causes massive over-fetching and cache synchronization issues.

This is where the principle of API federation shines. The federated API is a controlled way of providing information from several domain APIs in a single strongly typed place. This clearly separates the ownership of each domain API and the federated API. It also adds a clear contract between the federated API and each domain API. This allows the independent evolution and deprecation of all APIs without impeding dependencies.

Front-end platform

Enterprises usually target multiple front-end platforms. Web browser and mobile OS frameworks are the most common types of front-end platforms.

The reason for and biggest challenge of micro front-ends is the ever changing nature of those front-end platforms.

• Platforms are changing

Web Browsers and Mobile Phone Operating Systems receive constant updates, add and deprecated features and adopt technology changes.

• Compliance standards are changing

Compliance standards are considered parts of the front-end target platform like Web Content Accessibility Guidelines (WCAG), The American with Disabilities Act (ADA), Payment Card Industry Data Security Standard (PCI DSS) and many more relevant to the specific enterprise and product.

• Technology is changing

The main driver for micro front-ends is to deal with the exponentially increasing technology changes like web frameworks (JQuery, Angular, React, Web Components, …), mobile frameworks (XAML, React Native, Native Script, Flutter, …), programming languages (C#, JavaScript, Web Assembly, …), styling (CSS, SASS, Styled Components, Shadow DOM, …) and many more.

Technical debt

One of the biggest problems for enterprise organizations is the build up of technical debt. Technical debt is accumulating exponentially over time. It causes security issues, compliance failures, huge loss of productivity and prevents innovation.

Micro front-ends must become part of solving the technical debt problem rather than adding to it.

Legacy

Micro front-ends are supposed to solve problems within the enterprise. Those problems are usually a result of the accumulated technical debt. We call this the legacy stack.

To ensure a successful transition, we must make sure that there are no direct dependencies between the legacy stack and the new micro front-end architecture.

We achieve this generally by decoupling the new business domain APIs from the legacy stack with a transparent bridging layer.

Architecture of change

Since technical debt is the product of technology change, a micro front-end architecture must provide a solution to allow for technologies to change without the accumulation of technical debt.

Therefore the foundation of the micro front-end architecture should be the most basic and stable part of the targeted platform.

In case of the web platform, the Custom Element of the HTML standard would represent the lowest common denominator that has the least dependencies and is expected to be a stable foundation for the longest time. The simplicity and being part of the basic standard of the target platform makes it the perfect foundation for our micro front-end architecture targeting the web platform.

Consistency

Micro front-ends break apart the product into smaller chunks. But only the sum of all of these chunks make the final product again.

Micro front-ends will evolve at different paces. They will be build by different people and over time in different technologies.

A micro front-end architecture must ensure that the end product offers consistency in regards to the User Experience.

It is also important that the consistency across the development experience is preserved to manage cognitive load and retain productivity and transparency.

Principles

The following principles can guide our decision making on the way to our new micro front-end architecture.

All principles are equally important and only numbered for future referencing.

1. Business domain driven

Micro front-ends and APIs are strongly aligned with the business domains.

This enables the enterprise to organize itself and form expert groups, streams, tribes, teams for each business domain.

2. Business solution driven

Each micro front-end is the result of a business solution.

The business solution is the contract with the customer that describes exactly the intentions, actions, reactions, resources and expected outcomes.

3. Reusable and composable

Micro front-ends can be composed of nested micro front-ends.

We identify and extract re-usable business solutions within business solutions. As micro front-ends represent business solutions so they must also be composable accordingly.

4. Service Oriented

Micro front-ends should only use federated business domain services (APIs) to query, mutate and subscribe to state, data and resources.

Decoupling the micro front-ends from the back-end resources is essential to ensure the independent nature of each micro front-end. Using a single federated API between micro front-ends and domain APIs removes all dependencies and enables rapid evolution at each layer without any impediments.

5. Technology agnostic

Micro front-ends must not depend on specific technologies. The most basic suitable long term building block should be the integration point for each targeted platform.

To prevent the buildup of technical debt we must ensure that any technology can be deprecated and replaced without impacting the rest of the system. This can only be achieved if all technologies are encapsulated within the most stable long term API for the given platform.

6. Independent

We must be able to independently develop, test, build and deploy every individual micro front-end at any time without depending on or impacting other micro front-ends.

Rapid evolution of our micro front-ends is only possible if there are no impeding dependencies. Since micro front-ends are composable and can be nested we must make sure that appropriate packaging and versioning prevents impeding dependencies.

7. Consistent

We must ensure that the user experience is consistent across all micro front-ends. We should try to keep the development experience also as consistent as possible.

User experience must be consistent. Look and feel as well as behaviors are an essential part of the product and customer satisfaction. Development experience should be consistent to ensure productivity. Since there will be huge amounts of micro front-ends all build at different times by different teams we have to find ways to ensure consistency and maintainability.

Example

At this point we are well equipped to create a micro front-end architecture that is based on the enterprise scale environment fundamentals and the resulting principles.

We will target the web platform, since it is the most common one. Later we will see how other platforms can benefit from our architecture as well.

Context

For simplicity we assume a medium sized enterprise with multiple domains and websites for numerous redistributors as customers, who demand support for all browsers down to IE11.

Web platform

The first principle we have to consider targeting the web platform is to be technology agnostic. The native foundation of the web platform is HTML, CSS and JavaScript. Considering the IE11 constraint we can only target a limited set of HTML 5, CSS3 and ECMAScript 5.

Custom Elements

Following our principle we want to encapsulate any higher level framework within the most basic long term container. Given our constraints this would be HTML Custom Elements. As part of the official HTML standard we can safely assume that this is a suitable long term choice at the most basic level.

The following code is an example of the most basic implementation of a micro front-end according to our principle.

This allows us to wrap any future technology safely without creating any dependency on the system at large, which allows us to replace it at any time. Here we integrate React into our micro front-end without violating any of our principles.

Now we can use our micro front-end at the most basic level anywhere, even nested within other micro front-ends that internally use a complete different framework.

Following our principles we do not attempt to include extending inbuilt elements as well as Shadow DOM at this stage for multiple reasons. Mainly both are till a very wonky standards and not supported in all browsers required for this example.

Nested micro front-ends

Another important principle we have to consider in regards to our choice is to be composable and reusable. As already demonstrated custom element containers do follow this principle by design.

Now we also have to consider the principle of being independent. This is more challenging since it introduces dependency management. The principle demands that we can upgrade any micro front-end at any time without affecting any other micro front-end. But since a micro front-end can be nested within another micro front-end we have to ensure that we follow the principle. Fortunately this can easily be achieved by versioning and packaging of our micro front-ends. So upgrading a micro front-end to a newer version will become a conscious decision within a controlled process.

Build Platform

Following up on the need to version and package our micro front-ends to obey our principle of independence, we have to decide how to build.

We will follow our principles again and chose the most basic long term standard for the given platform which in this case is packaging our micro front-ends in NPM packages.

Peer Dependencies

We must avoid duplication of dependencies to reduce loading times for the customer as well as avoiding conflicting dependencies. With NPM we achieve this by specifying peer dependencies for our micro front-ends, which the web client has provide.

Dependencies

The website client has to provide all the required dependencies. At this stage we will be able to automatically discover conflicting peer dependency requirements and upgrade all necessary dependencies in a controlled process to resolve those conflicts.

Here the principle of independence is still intact. It just forces us to keep our dependencies up-to-date to prevent conflicts.

In special cases a micro front-end can still have its very own dependency that gets compiled into the micro front-end package.

Dependencies can still be loaded dynamically to reduce loading times in a process called code-splitting that is build into the website client.

Consistency

Keeping dependencies up-to-date also helps us with our principle of maintaining consistency. Styling and theming as well as other product features spanning across all micro front-ends can now simply become support packages and peer dependencies for all micro front-ends. We just have to make sure that we obey the principle of being technology agnostic for these packages as well.

APIs

Now that we have a way to implement and build our micro front-ends, we have to find a way to connect them with the required resources.

The principle of being service oriented clearly prescribes the use of APIs. Following the principle of using the most basic and long term standard for the given platform we have the choice between custom REST endpoints or the GraphQL standard.

The principles of being business domain driven, service oriented and technology agnostic all clearly point to GraphQL as being an actual standard on the web platform specifically designed for domain driven environments.

Unified micro front-end API

Choosing GraphQL also improves the simplicity and long term stability of our micro front-end API interface. We can basically provide the Query, Mutate and Subscribe native interface directly to every micro front-end as the one and only unified micro front-end API. Reducing cognitive load and complexity.

In addition we completely remove any custom interface dependencies between micro front-ends and their nested micro front-ends.

Client API and State

Micro front-ends can now query, mutate and subscribe the local state in exactly the same way they do for the backend. Improving simplicity and reducing cognitive load even further.

This allows micro front-ends to interact with each other without any dependencies in real-time through the strongly typed entities of the client schema.

Legacy transition

Using this approach also allows us to start building and deploying micro front-ends right away, since we can integrate them into our legacy stack retaining maximum isolation.

We can then either remove more and more legacy code with micro front-ends and/or switch over to a brand new website client when ready.

We can also create a micro front-end that is just wrapping legacy pages within technology agnostic iFrames.

Federated Backend APIs

And finally we can achieve our goal of supporting the enterprise to structure and organize itself aligned with the major business domains.

The principle of being business domain driven means that each domain owns its own APIs. Therefore each domain can have its own strongly typed entities within an ever evolving schema.

With GraphQL we can now combine all these domains into a single federated API that can be consumed by all micro front-ends.

Conclusion

A well planned micro front-end architecture can help enterprises to overcome the constraints of their legacy stacks.

It enables the enterprise to focus on their customers by identifying business domains and business solutions.

It allows organizational changes to verticals, stream, tribes, chapters or any other domain driven agile approach that can improve the organization as a whole.

The resulting clear boundaries, ownership and interfaces reduce cognitive load and improve productivity and quality.

Technical debt isn’t inevitable anymore but rather becomes a controlled process of deprecation and removal. This drives innovation, quality and productivity.

This article is only a high level overview and there are many more details that are specific to your enterprise. But I hope it can provide you with the necessary fundamentals and principles to get you started to transform your business.

Thank you and please leave comments on how to improve this article or get in contact with me if you want to discuss things in more detail.