From Micro Frontends in Action by Michael Geers
This article covers:
- Contrasting the difference between a web site and a web app and investigating the implications this has on picking an integration technique.
- Comparing different micro frontend architectures by their benefits and challenges.
- Figuring out the best architecture and composition technique for your project’s needs.
You can save 40% off Micro Frontends in Action, as well as of all other Manning books and videos.
Just enter the code psfrontend20 at checkout when you buy from manning.com.
In this article, we go over the terminology and highlight the key advantages of different techniques and architectures. After that, you’ll learn about the Documents-to-Applications Continuum. It’s a concept that helps you with the decision of whether to render your markup on the server, client, or both. This distinction is crucial because it determines which architectures and integration patterns are suitable for your use-case. We’ll end with an architecture decision guide. You’ll learn how you can make a sound choice based on a handful of questions. These questions lead you through the different options.
Revisiting the terminology
When you’re setting up a micro frontends project with different teams, everyone must use the same vocabulary. This is why we take a moment to sort the terms. We’ll start with the basic building blocks: the integration techniques. Then we’ll look at different high-level architectures that you can build with them.
Figure 1 shows several integration techniques.
Figure 1. The integration techniques required for a micro frontend architecture. On the left, we see two techniques for handling cross-team page transitions. The right side shows a list of methods to compose different user interfaces onto one page.
We can group them into two categories: Page-Transition and Composition. Let’s look at the transitions first.
When we talk about page transitions as an integration technique, we mean inter-team page transitions. How does a user get from a page owned by Team A to a page owned by Team B? From an architectural standpoint, it’s unnecessary to know how a team handles transitions between its pages. This is an implementation detail.
The plain old hyperlink is the most basic form for doing a micro frontends integration. Each team is responsible for a set of pages. Handing over the user to another part of the application is as easy as placing a link to the other team’s work. In its cleanest form, there’s no extra coordination needed. Teams could even host their part of the applications under different domains.
In practice, you often want to show user interface parts from different teams on one page. A typical example of this is a header or navigation micro frontend. One team builds and owns it. All the other teams integrate it on their page. It could also be functionality like the buy button or mini basket on our product page.
In this article, we call an includable micro frontend a fragment. To make the integration happen, we need a shared format. The owner of the fragment must provide it in a standardized format. The fragment consumer uses this format to integrate the desired micro frontend on his page.
We can broadly group the composition techniques into two buckets: server-side integration and client-side integration. We’ve also included the iframe and AJAX techniques because they’re a hybrid between server and client.
Implementing a server-side integration technique makes sense when teams generate their markup server-side. The markup for all fragments of a page gets assembled before it reaches the customer’s browser. A central piece of infrastructure, like a web-server, performs the markup assembly. You can use the SSI technique in the NGINX to perform this task, but an alternative approach is the team which owns the page fetches the required fragments directly from the other teams. The server-side integration libraries Tailor and Podium work like this.
If teams generate their markup in the browser, you need a client-side integration technique.
An essential part of client-side integration is communication. How can fragment A inform fragment B about an event that might be interesting? Micro frontends can communicate via Custom Events or an event-bus/broadcasting solution.
These are the basic integration techniques you’ve learned. Let’s zoom out a bit and have a look at different architectural styles.
One of the micro frontends benefits is that teams are free to use the technology that fits their slice of the application best. Before you start setting up a micro frontends project, all teams need to be on the same page when it comes to the high-level architecture. Are we building static pages that integrate solely via links, or is the goal to create a highly dynamic and tighter integrated single-page app? You should consciously make this decision together with all teams. As always, there are no silver bullets and no right and wrong solutions, but having a shared vocabulary and a common understanding of what you are working towards helps everyone. It also eliminates misunderstandings down the road.
Figure 2 shows six different high-level architectures.
Figure 2. Different architectural styles to build a micro frontends project. This chart starts with the simplest form, the linked pages approach, and shows how you can extend this with extra features like single-page applications, universal rendering, or a shared application shell.
We’ll go through them from top to bottom.
Every team serves its pages as complete server-rendered HTML documents. Clicking a link reloads the complete page and shows the desired content. This hard navigation happens if you move between pages from the same team or if you navigate across team boundaries. The simplicity of this approach is its main benefit: no central infrastructure or shared code are required, debugging is straight forward, and new developers instantly understand what’s going on. From a user experience point-of-view, there’s room for improvement.
It’s identical to the Linked Pages approach, but with one difference; all requests pass through a shared web-server or reverse proxy. This server sits in front of the team’s applications. It has a set of routing rules to identify which team should handle an incoming request. The routing is often done via URL prefixes associated with a specific team.
To improve the user experience and react to input faster, a team can decide to switch from delivering static server-generated pages to implementing a client rendered single-page app for the pages they own. This way, all link clicks for pages of this team result in a fast-soft navigation. Transition between team boundaries are still hard navigations. Technically the adoption of a single-page app architecture inside one team can be seen as an implementation detail. As long as linking to a specific page from the outside still works, teams can decide to change its internal architecture. The distinction between Linked Pages and Linked Single-Page Apps is essential when we talk about more advanced architectures and suitable integration techniques later.
Linked Universal SPAs
Teams can also decide to adopt universal rendering. The markup for the first request gets rendered on the server. It enables a pretty fast first page-load experience. From this point the application behaves like a single-page app—incrementally updating the user interface as needed. From a team’s point of view, this is a more complicated setup, which requires some additional development skills. From an architectural view, this approach is identical to the other “linked” architectures. The contract between the teams is still a set of shared URL patterns. A navigation across team boundaries results in a reload of the page. But when
The Unified SPA describes a single-page application composed out of other single-page applications. It requires all teams building their software as a single-page app. These single-page apps are then unified by a parent application, which is often called the application shell. The shell typically doesn’t render any user interface. Its job is to listen to changes in the browsers address bar and pass control from one single-page app to another if necessary. With the Unified SPA architecture, all page transitions are soft navigations. This leads to a snappier and more app-like user interface. The app shell is a central piece of code. It introduces a non-trivial amount of coupling and complexity.
Unified Universal SPA
When we take the Unified SPA model and introduce universal rendering, we arrive at something we call Unified Universal SPA. With this model, each team builds a single-page app with universal rendering capabilities. To make this work, the parent application (app shell) also needs to be universal. It needs to be able to run on the server and the client. This is a pretty challenging architecture. It promises to combine the best of all worlds but comes with the most complexity.
Building a product by combining user interfaces owned by different teams comes with a considerable amount of complexity. A large part is organizational:
- Defining team boundaries and responsibilities.
- Creating a shared vision and getting everyone on the same page.
- Finding ways to exchange knowledge and experiences between the teams where necessary.
The architecture and level of integration you choose has a considerable effect on your complexity. This complexity manifests itself in different aspects:
- Initial infrastructure work which is required to get started.
- Number of moving parts (services, artifacts) that need maintenance.
- Amount of coupling: Which changes require more than one team to become active?
- Developer skill level: What concepts do new developers need to understand?
- Debugging: How easy is it to attribute a bug to a specific team.
Figure 3 sorts the described architectures in four complexity groups. Starting with simple and ending with complex.
Figure 3. Micro frontend architectures sorted by complexity. The Links & Pages approach is the simplest one to build and run. The complexity arises as you move to more sophisticated architectures. The Unified Universal SPA approach requires a lot of development skills to get it right. You also need shared infrastructure and code to make it happen.
This is of cause only general guidance. The real cost associated with an architecture depends on your team’s experience and the use-case. As a rule of thumb, you should always opt for the simplest architecture you can responsibly get away with.
Sure, it’s nice to have a Unified SPA with no hard page transitions, but does the extra work required to achieve and maintain this justify the potential benefits?
In the descriptions above, we always assumed that all teams use the same architecture, but you can also mix and match. For a team that builds fast-loading landing pages, the Links & Pages approach might be sufficient, but for a seamless browsing experience, you want to create a Unified SPA that integrates the team which owns the product list and the team managing the product pages. These architectures can work side-by-side: Some teams are doing Links & Pages, and others share an application shell to deliver a Unified SPA.
This way, you only increase the complexity in the areas where it’s needed.
Having a heterogeneous architecture also has drawbacks:
- A new team has no go-to architecture. Teams need to analyze and discuss their use-cases beforehand. (This is not necessarily a drawback.)
- Integrating fragments from different teams might get harder. Teams need to deliver their includable micro frontend in a format that works for the page that includes it.
Are you building a site or an app?
As you’ve seen in this article, it makes a significant difference if you render your markup on the client or server. It’s a general question that everyone who’s setting up a new web project has to answer, but in a micro frontends context this decision is essential. It defines which integration techniques are suitable.
The Documents-to-Applications Continuum
In 2013 Aral Balkan wrote a blogpost , which starts with the question if the terms web site or web application provides any meaningful distinction. In day-to-day life, these terms are often used interchangeably. No unique technology magically transforms a web site into a web application. A difference arises when we look deeper. What purpose does the project we’re building serve? Do people come to our site to consume content, or
do they want to use a specific functionality we provide? For better visualization, it helps to look at extreme examples:
- content-centric: Imagine a simple blog. A user can browse the list of posts and read the complete content on a dedicated article page.
- behavior-centric: Imagine an online drawing application. People can go to the site and draw beautiful sketches with their fingers and export them as an image.
The first one is a prototypical web site where the content is essential. The second one is a pure application. It doesn’t bring any content. It’s all about the functionality it provides to the user.
In a non-trivial project, it’s typically not black and white. This is where the Documents-to-Applications Continuum comes in. The idea is that both examples are at different ends on a spectrum, as illustrated in figure 4.
Figure 4. The Documents-to-Applications Continuum provides a mental model to help you think about if your project is more of a web site or a web application. It’s a gradual scale and not a black or white decision.
Let’s look at two examples. Where does amazon.com fit on this scale? They provide a lot of functionality. You can search, sort, and filter through product lists, rate products, manage your returns, or have a live chat with their customer service. At its core, it’s a content-centric site. A good question to ask is: Would the site still be useful if we’d strip away all behavior? For amazon.com, we can answer this with a definite yes. No doubt, the extra functionality’s also important, but without products, the features would be useless. We’d put their site somewhere on the left part of the continuum.
Now to our second example. The site CodePen.io let’s web developers and designers put together HTML, CSS, and JS to get a live preview in the browser. Developers use the online code editor to sketch out ideas or isolate bugs. CodePen also has an active community of people who showcase their work and share code with others. You can go to the site and discover new exciting techniques by browsing the public catalog. How does CodePen fit on our continuum? It’s a harder question to answer because its strong on both aspects: the online editor (behavior-centric) and the public catalog (document-centric). If we’d strip away all behavior, the online editor would vanish. If we remove all content, the catalog disappears, but the editor is still there. This is why we’d probably put CodePen in the middle of the spectrum.
Server, client or both
Classifying your product onto the continuum is a good starting point to identify if your templating should live on the server or in the browser. If your product has a strong content focus, server-side rendering should be your first choice. Using progressive enhancement to add functionality should feel natural.
If you’re building an application where it’s all about interaction and not about content, a purely client-rendered solution is the best fit. Here the concept of progressive enhancement doesn’t help you at all because there is no enhanceable content.
For a project that resides in the middle of the spectrum, you need to make a choice. Server-side and client-side templating are valid options, but in this area, both have their advantages and disadvantages. If you aren’t afraid of the extra complexity, you can also pick both and go with the universal rendering option.
Let’s revisit our high-level architectures. Figure 5 highlights which of them use server-, client- and universal rendering.
Figure 5. Illustrates which architectures feature server-side, client-side or universal rendering.
Make sure the architecture you choose aligns with the nature of your project and the business. Templating and complexity considerations are two significant factors in making a decision. Next up, we’ll take another angle on this decision using a decision tree.
Picking the right architecture and integration technique
Now we’ve sharpened our vocabulary and have a mental model to pinpoint what kind of product we’re building. Let’s look at a concrete way to determine which architecture and integration your project needs. Figure 6 shows a decision tree that helps with this question. It’s inspired by Manfred Steyer’s work  for creating Angular based frontend microservices.
Take some time to understand what’s going on in this diagram. Follow the lines from top to bottom by answering the questions until you reach your high-level architecture. From there on, you can follow the dotted line to get to the compatible Composition Technique. If your use-case doesn’t require you to have different micro frontends to be active at the same time (fragments or nested micro frontends), you can skip this step.
Figure 6. The decision tree helps to pick a micro frontends architecture based on your project requirements. It also shows which kind of composition technique is appropriate for your use-case.
What does your project need?
Let’s have a look at the questions in this decision tree.
Strong isolation (legacy, 3rd party)
Do you want strong technical isolation between the code of the teams? Why wouldn’t you? Isolation and encapsulation generally lead to less unforeseen effects an reduces bugs. Sadly, opting for strong isolation eliminates a lot of other possibilities. The right question to ask is: do you need strong isolation? This is typically true if you integrate a legacy system which doesn’t respect namespacing rules and requires global state to work correctly; another reason is security. If you’re integrating with an untrusted third-party solution or one part of your application has high-security requirements (e.g., it handles credit card data), it can be necessary to better shield the micro frontends against each other.
Fast first page load / Progressive enhancement
This is a double question. If you need one of these properties, you should follow the yes arrow.
Having a fast first page view is always pleasant, but the importance of this property heavily depends on your business. If you want your site to rank high in search results, first page load performance is nothing you can ignore. Search engines like Google increasingly favor fast-loading sites in their ranking . Even if search ranking isn’t your primary goal, there are a lot of case-studies  that show how better web performance increases business metrics.
If you’d locate your project on the middle or left side of the Documents-to-Applications Continuum, I’d highly recommend adopting progressive enhancement practices. You should encourage all developer teams to learn about this approach. For developers who started their web career with frameworks like React or Angular, the concepts might sound strange at first sight. Architecting features with progressive enhancement in mind and embracing the primitives of the web leads to more maintainable, easier to understand, and more stable software. If you’re on the far right in the continuum and building a pure web application, there’s typically no content to enhance.
Then progressive enhancement won’t help you at all.
Instant user feedback
In the last question, we talked about the first page load performance, but how does your site react to further interactions from the user? The classical “click a link” and “fetch generated markup from the server” works for a lot of cases, such as when you use AJAX techniques to avoid a full page reload. In this model, the complete templating resides on the server. This means at least one server-roundtrip is necessary to update the UI in response to a user input.
If you need to be faster than this, you must adopt client-side rendering. Fetching data is a little bit faster because JSON data is more compact than rendered HTML, but the network latency stays the same. The most significant advantage of client-side rendering is that it enables us to provide instant feedback. Even if the data the user wants to see is still in transit, you can update the view and show placeholders and skeleton screens. 
It also enables you to adopt Optimistic UI patterns.  With Optimistic UI, you try to increase the perceived performance by instantly rendering the result which is most likely. Let’s look at a shopping cart example: When a user wants to delete an item, she clicks on the delete button. The browser calls the associated API on the server, and when it comes back, the item is deleted from the visual shopping cart list. With Optimistic UI, you assume that the delete API call works in most of the cases. This is why you remove the line item directly and don’t wait for the API call to return. If this assumption turns out not to be true (item remove failed), you restore the item in the user interface and show an appropriate error message. This technique is powerful, but because you are effectively lying to your user, you should use it with care.
Being able to render a response to a user input instantly improves user experience and makes your site feel more app-like.
In the “instant user feedback” question, we talked about improving the user experience inside a micro frontend. Now let’s look at what happens when the user transitions across team boundaries. This question differentiates the linked architectures from the unified architectures. How important is it that inter-team page transitions are client-side rendered?
Answering this question depends heavily on the team boundaries you establish, the number of teams and the usage pattern of your application.
If you create your team boundaries along with the user’s tasks and needs, they don’t cross team boundaries that often.
Say you’re building a website for a bank. It has to distinct areas developed by two teams: users can check their account balance (Team A), and they can also calculate and request a housing loan (Team B). For a good user experience, it might be essential to provide a high amount of interactivity inside these areas. This is something Team A and Team B can decide independently,but because users seldom switch between balance checking and loan requesting in one session it might be fine to have a hard navigation between these areas.
Let’s pick another example. We’re building a call-center application. The agents use the application to manipulate orders (Team A) and make personalized recommendations (Team B). Because the agent switches between these two micro frontends frequently, it might be a good idea to implement soft-navigation. It makes using the application faster and positively impacts the agent’s workflow.
Multiple micro frontends on one page
If you’ve answered all questions on your way down the tree and arrived at your high-level architecture, there’s one last bonus question: “Do you need composition?” Answering “yes” brings you straight down to the associated composition technique. If you’re building a pure SPA, you need to integrate client-side. If you opt for server-generated pages, you should use a server-side integration.
Having a composition technique is optional. When we look at our banking example from the section before, we might not need a composition technique. The account area and the housing loan area could be two distinct sections of the site that link to each other.
The most common example of a composition is a header and navigation fragment. Usually, one team owns it, and the others include it on their page.
Basis for all teams
Most companies adopt micro frontends to increase their development speed. Creating a structure where teams can work side-by-side without having to discuss and coordinate with other teams. All teams need to build against the chosen architecture and be compatible with the integration mechanism.
As stated earlier, you should try to pick the most straightforward architecture you can get away with. Avoid central infrastructure where possible. Major changes in central infrastructure are often hard to make when they require an action from all teams.
- Establishing a shared vocabulary across all teams avoids misunderstandings. Differentiating between transition techniques, composition techniques and your high-level architecture helps everyone to get a clear picture of what you’re building towards.
- The Documents-to-Applications Continuum is a good mental model to identify if your project is more content- or behavior-centric. This distinction helps to make good technology choices.
- Whether a solution fits or not depends on the nature of your project, its usage patterns, the amount of coupling and complexity you are willing to accept, and your teams’ size and experience level; there are no right or wrong solutions.
- Not all teams need to adopt the same architecture. Some parts of your application might be document-centric others more behavior-centric. With micro frontends it’s possible to mix-and-match, but when you need composition you must find an integration technique that works for all teams.
- Try to pick the simplest architecture which is reasonable for your business.