This chapter covers:

• Discovering what micro frontends are
• Comparing the micro frontends approach to other architectures
• Pointing out the importance of scaling frontend development
• Recognizing the challenges that this architecture introduces

I’ve worked as a software developer on many projects over the last 15 years. In this time, I’ve had multiple chances to observe a pattern that repeats itself throughout our industry: working with a handful of people on a new project feels fantastic. Every developer has an overview of all functionality. Features get built quickly. Discussing topics with your coworkers is straightforward. This changes when the project’s scope and the team size increases. Suddenly one developer can’t know every edge of the system anymore. Knowledge silos emerge inside your team. Complexity rises--making a change on one part of the system may have unexpected effects on other parts. Discussions inside the team are more cumbersome. Before, team members made decisions at the coffee machine. Now you need formal meetings to get everyone on the same page. Frederick Brooks described this in the book The Mythical Man-Month back in 1975. At some point, adding new developers to a team does not increase productivity.

Projects often are divided into multiple pieces to mitigate this effect. It became fashionable to divide the software, and thereby also the team structure, by technology. We introduced horizontal layers with a frontend team and one or more backend teams. Micro frontends describes an alternative approach. It divides the application into vertical slices. Each slice is built from the database to the user interface and run by a dedicated team. The different team frontends integrate in the customer’s browser to form the final page. This approach is related to the microservices architecture. But the main difference is that a service also includes its user interface. This expansion of the service removes the need for a central frontend team. Here are the three main reasons why companies adopt a micro frontends architecture:

• Optimize for feature development --A team includes all skills needed to develop a feature. No coordination between separate frontend and backend teams is required.

• Make frontend upgrades easier --Each team owns its complete stack from frontend to database. Teams can decide to update or switch their frontend technology independently.

• Increase customer focus --Every team ships their features directly to the customer. No pure API teams or operation teams exist.

In this chapter, you’ll learn what problems micro frontends solve and when it makes sense to use them.

1.1 The big picture

Figure 1.1 is an overview of all the parts that are important when implementing micro frontends. Micro frontends are not a concrete technology. They’re an alternative organizational and architectural approach. That’s why we see a lot of different elements in this chart--like team structure, integration techniques, and other related topics. We’ll go through the complete figure step by step. We start with the three teams above the dashed line and work our way up. When we reach the magic lamp at the top, we’ll discuss frontend integration. At the bottom of this diagram, you can see the contents of this box zoomed in. It illustrates the three different aspects we need to address to create an integrated application. Our diagram journey ends at the three shared topics at the right.

1.1.1 Systems and teams

The three boxes with Teams A, B, and C demonstrate the vertically arranged software systems. They form the core of this architecture. Each system is autonomous, which means it can function even when the neighboring systems are down. Every system has its own data store to achieve this. Additionally, it doesn’t rely on synchronous calls to other systems to answer a request.

Figure 1.1 Here is the big picture overview of the micro frontends approach. The vertically arranged teams at the bottom are the core of this architecture. They each produce features in the form of pages or fragments. You can use techniques like SSI or Web Components to integrate them into an assembled page that reaches the customer.

One system is owned by one team. This team works on the complete stack of the software from top to bottom. In this book, we will not cover the backend aspects like data replication between these systems. Here, established solutions from the microservices world apply. We’ll focus on organizational challenges and frontend integration.

Team missions

Each team has its area of expertise in which it provides value for the customer. In figure 1.2 you see an example for an e-commerce project with three teams.

Figure 1.2 An e-commerce example with three teams. Each team works on a different part of the e-commerce shop and has its mission statement that clarifies their responsibility.

Every team should have a descriptive name and a clear user-focused mission. In our projects we align the teams along the customer journey--the stages a customer goes through when buying something.

Team Inspire’s mission, as the name implies, is to inspire the browsing customer and to present products that might be of interest.

Team Decide helps in making an informed buying decision by providing excellent product images, a list of relevant specs, comparison tools, and customer reviews.

Team Checkout takes over when the customer has decided on an item and guides them through the checkout process.

A clear mission is vital for the team. It provides focus and is the basis for dividing the software system.

Cross-functional teams

The most significant difference between micro frontends and other architectures is team structure. On the left side of figure 1.3 you see specialist teams. People are grouped by different skills or technologies. Frontend developers are working on the frontend; experts in handling payment work on a payment service. Business and operations experts also form their own teams. This structure is typical when using a microservices approach.

Figure 1.3 Team structure of a microservice-style architecture on the left compared with micro frontends teams on the right. Here the teams are formed around a customer need and not based on technologies like frontend and backend.

It feels natural at first sight, right? Frontend developers like to work with other frontend developers. They can discuss the bugs they are trying to fix or come up with ideas on how to improve a specific part of the code. The same is true for the other teams which specialize in a specific skill. Professionals strive for perfection and have an urge to come up with the best solution in their field. When each team does a great job, the product as a whole will also be great, right?

This assumption is not necessarily valid. Building interdisciplinary teams is becoming more and more popular. You have a team where frontend and backend engineers, but also operations and business people, work together. Due to their different perspectives, they come up with more creative and effective solutions for the task at hand. These teams might not build the best-in-class operations platform or frontend layer, but they specialize in the team’s mission. For example, they are working on becoming experts in presenting relevant product suggestions or building a seamless checkout experience. Instead of mastering a specific technology, they all focus on providing the best user experience for the area they work on.

Figure 1.4 This is the middle portion of the big picture as detailed in its entirety in figure 1.1. Each team builds its own user interface as a page or a fragment.

Cross-functional teams come with the added benefit that all members are directly involved in feature development. In the microservice model, the services or operations teams are not involved directly. They receive their requirements from the layer above and don’t always have the full picture of why these are important. The cross-functional team approach makes it easier for all people to get involved, contribute, and, most importantly, self-identify with the product. Now that we’ve discussed teams and their individual systems, let’s move to the next step.

1.1.2 The frontend

Now we’re getting to the aspect that makes the micro frontends approach different from other architectures. It’s the way we think about and build features. Teams have end-to-end responsibility for a given functionality. They deliver the associated user interface as a micro frontend. A micro frontend can be a complete page or a fragment that other teams include. Figure 1.4 illustrates this.

A team generates the HTML, CSS, and JavaScript necessary for a given feature. To make life easier, they might use a JavaScript library or framework to do that. Teams don’t share library and framework code. Each team is free to choose the tool that fits best for their use case. The imaginary frameworks Thunder.js and Wonder.js illustrate that. 1 Teams can upgrade their dependencies on their own. Team B uses Wonder.js v1.3, whereas Team C already switched to v 1.4.

Page ownership

Let’s talk about pages. In our example, we have different teams that care about different parts of the shop. If you split up an online shop by page types and try to assign each type to one of the three teams, you might end up with something like figure 1.5.

Figure 1.5 Each page is owned by one team.

Because the team structure resembles the customer journey, this page-type mapping works well. The focus of a homepage is indeed an inspiration, and a product detail page is a spot where the customer makes their buying decision.

How could you implement this? Each team could build their own pages, serve them from their application, and make them accessible through a public domain. You could connect these pages via links so that the end-user can navigate between them. Voilà--you are good to go, right? Basically, yes. In the real world, you have requirements that make it more complicated. That’s why I’ve written this book! But now you understand the gist of the micro frontends architecture:

• Teams can work autonomously in their field of expertise.

• Teams can choose the technology stack that fits best for the job at hand.

• The applications are loosely coupled and only integrate in the frontend (e.g., via links).

Fragments

The concept of pages is not always sufficient. Typically you have elements that appear on multiple pages, like the header or footer. You do not want every team to re-implement them. This is where fragments come in.

A page often serves more than one purpose, and might show information or provide functionality that another team is responsible for. In figure 1.6, you see the product page of The Tractor Store. Team Decide owns this page. But not all of the functionality and content can be provided by them.

The Recommendations block on the right is an inspirational element. Team Inspire knows how to produce those. The Mini Basket at the bottom shows all selected items. Team Checkout implements the basket and knows its current state. The customer can add a new tractor to the basket by clicking the Buy button. Since this action modifies the basket, Team Checkout also provides this button as a fragment.

Figure 1.6 Teams are responsible for pages and fragments. You can think of fragments as embeddable mini applications that are isolated from the rest of the page.

A team can decide to include functionality from another team by adding it somewhere on the page. Some fragments might need context information, like a product reference for the Related Products block. Other fragments like the Mini Basket bring their own internal state. But the team that is including the fragment in their code does not have to know about state and implementation details of the fragment.

1.1.3 Frontend integration

Figure 1.7 shows the upper part of our big-picture diagram. In this part, it all comes together.

Figure 1.7 The term frontend integration describes a set of techniques you use to assemble the user interfaces (pages and fragments) of the teams into an integrated application. You can group these techniques into three categories: routing, composition, and communication. Depending on your architectural choices, you have different options to solve these categories.

Frontend integration describes the set of tools and techniques you use to combine the team’s UIs into a coherent application for the end user. The zoomed-in Frontend Integration box at the bottom of the diagram highlights three integration aspects. Let’s go through them one by one.

Routing and page transitions

Here we are talking about integration on page level. We need a system to get from a page owned by Team A to a page owned by Team B. The solutions can be straightforward. You can achieve this by merely using an HTML link. If you want to enable client-side navigation, which renders the next page without having to do a reload, it gets more sophisticated. You can implement this by having a shared application shell or using a meta-framework like single-spa. We will look into both options in this book.

Composition

The process of getting the fragments and putting them in the right slots is performed here. The team that ships the page typically does not fetch the content of the fragment directly. It inserts a marker or placeholder at the spot in the markup where the fragment should go.

A separate composition service or technique does the final assembly. There are different ways of achieving this. You can group the solutions into two categories:

1. Server-side composition, for example with SSI, ESI, Tailor or Podium

2. Client-side composition, for example with iframes, Ajax, or Web Components

Depending on your requirements, you might pick one or a combination of both.

Communication

For interactive applications, you also need a model for communication. In our example, the Mini Basket should update after clicking the Buy button. The Recommendation Strip should update its product when the customer changes the color on the detail page. How does a page trigger the update of an included fragment? This question is also part of frontend integration.

In part two of this book, you’ll learn about different integration techniques and the benefits and drawbacks they provide. In chapter 9 we’ll round off this part with some guidance to help you make a good decision.

1.1.4 Shared topics

The micro frontends architecture is all about being able to work in small autonomous teams that have everything they need to create value for the customer. But some shared topics are essential to address when working like this (figure 1.8).

Figure 1.8 To ensure a good end result and avoid redundant work, it’s important to address topics like web performance, design systems, and knowledge sharing from the start.

Web performance

Because we assemble a page from fragments made by multiple teams, we often end up with more code that our user must download. It’s crucial to have an eye on the performance of the page from the beginning. You’ll learn useful metrics and techniques to optimize asset delivery. It’s also possible to avoid redundant framework downloads without compromising team autonomy. In chapters 10 and 11 we dive deeper into the performance aspects.

Design systems

To ensure a consistent look and feel for the customer, it is wise to establish a common design system. You can think of the design system as a big box of branded LEGOTM pieces that every team can pick and choose from. But instead of plastic bricks, a design system for the web includes elements like buttons, input fields, typography, or icons. The fact that every team uses the same basic building blocks brings you a considerable way forward design-wise. In chapter 12 you’ll learn different ways of implementing a design system.

Sharing knowledge

Autonomy is essential, but you don’t want information silos. It’s not productive when every team builds an error-logging infrastructure on their own. Picking a shared solution or at least adopting the work of other teams helps you to stay focused on your mission. You need to create spaces and rituals that enable information exchange regularly between teams.

1.2 What problems do micro frontends solve?

Now you have an idea of what micro frontends are. Let’s take a closer look at the organizational and technical benefits of this architecture. We’ll also address the most prevalent challenges you have to solve to be productive with this approach.

1.2.1 Optimize for feature development

The number one reason why companies choose to go the micro frontend route is to increase development speed. In a layered architecture, multiple teams are involved in building a new feature. Here is an example: suppose the marketing department has the idea to create a new type of promotion banner. They talk to the content team to extend the existing data structure. The content team talks to the frontend team to discuss changes to their API. Meetings are arranged, and the specification is written. Every team plans its work and schedules it in one of the next sprints. If everything works as planned, the feature is ready when the last team finishes implementing it. If not, more meetings are scheduled to discuss changes.

Reducing waiting time between teams is micro frontends' primary goal.

With the micro frontends model, all people involved in creating a feature work in the same team. The amount of work that needs to be done is the same. But communication inside a team is much faster and less formal. Iteration is quicker--no waiting for other teams, no discussion about prioritization.

Figure 1.9 This diagram shows what it takes to build a new feature. On the left side, you see a layered architecture. Three teams are involved in building it. These teams have to coordinate and potentially wait for each other. With the micro frontends approach (right), one team can build this feature.

Figure 1.9 illustrates this difference. The micro frontend architecture optimizes for implementing features by moving all necessary people closer together.

1.2.2 No more frontend monolith

Most architectures today don’t have a concept for scaling frontend development. In figure 1.10 you see three architectures: the monolith, frontend/backend-split, and microservices. They all come with a monolithic frontend. That means the frontend comes from a single codebase that only one team can work on sensibly.

Figure 1.10 In most architectures, the frontend is a monolithic system.

With micro frontends, the application, including the frontend, gets split into smaller vertical systems. Each team has its own smaller frontend. Compared to a frontend monolith, building and maintaining a smaller frontend has benefits. A micro frontend

• Is independently deployable

• Isolates the risk of failure to a smaller area

• Is narrower in scope and thereby easier to understand

• Has a smaller codebase that can help when you want to refactor or replace it

• Is more predictable because it does not share state with other systems

Let’s go into detail on a few of these topics.

1.2.3 Be able to keep changing

As a software developer, constant learning and the adoption of new technologies is part of the job. But when you work in frontend development, this is especially true. Tools and frameworks are changing fast. Sophisticated frontend development started in 2005, the web 2.0 era, with Ruby on Rails, Prototype.js, and Ajax, which were essential to bringing interactivity to the (at that time) mostly static web.

But a lot has changed since then. Frontend development transformed from “making the HTML pretty with CSS” to a professional field of engineering. To deliver good work, a web developer nowadays needs to know topics like responsive design, usability, web performance, reusable components, testability, accessibility, security, and the changes in web standards and their browser support. The evolution of frontend tools, libraries, and frameworks enabled us to build higher-quality and more capable web applications to meet the rising expectations of our users. Tools like Webpack, Babel, Angular, React, Vue.js, Stencil, and Svelte play a vital role today, but, likely, we haven’t reached the end of this evolution yet. Being able to adopt a new technology when it makes sense is an essential asset for your teams and your company.

Legacy

Dealing with legacy systems is also becoming a more prevalent topic in the frontend. A lot of developer time gets spent on refactoring legacy code and coming up with migration strategies. Big players are investing a considerable amount of work in maintaining their large applications. Here are three examples:

• GitHub did a multi-year migration to remove their dependency on jQuery.2

• Trivago, a hotel search engine, made an enormous effort with Project Ironman to rework their complex CSS to a modular design system.3

• Etsy is getting rid of their JavaScript legacy baggage to reduce bundle size and increase web performance. The code has grown over the years, and one developer can’t have an overview of the complete system. To identify dead code, they’ve built an in-browser code coverage tool that runs in the customer’s browser and reports back to their servers.4

When you are building an application of a specific size and want to stay competitive, it’s essential to be able to move to new technologies when they provide value for your team. This freedom does not mean that it’s wise to rewrite your complete frontend every few years to use the currently trending framework.

Local decision making

Being able to introduce and verify a technology in an isolated part of your application without having to come up with a grand migration plan for everything is a valuable asset. The micro frontends approach enables this on a team level. Here is an example: Team Checkout is experiencing a lot of JavaScript runtime errors lately, due to references to undefined variables. Since it’s crucial to have a checkout process that’s as bug-free as possible, the team decides to switch to Elm, which is a statically typed language that compiles to JavaScript. The language is designed to make it impossible to create runtime errors. But it also comes with drawbacks. Developers have to learn the new language and its concepts. The open source ecosystem of available modules or components is still small. But for the use case of Team Checkout, the pros outweigh the cons.

With the micro frontends approach, teams are in full control of their technology stack (micro architecture). This autonomy enables them to make the decision and switch horses. They don’t have to coordinate with other teams. The only thing they have to ensure is that they stay compatible with the previously agreed upon inter-team conventions (macro architecture). (See figure 1.11.) These might include adhering to namespaces and supporting the chosen frontend integration technique. You’ll learn more about these conventions through the course of the book.

Figure 1.11 Teams can decide about their internal architecture (micro architecture) on their own as long as they stay in the boundaries of the agreed upon macro architecture.

Doing such a switch for a large application with a monolithic codebase would be a big deal with lots of meetings and opinions. The risks are much higher, and the described trade-offs might not be the same in different parts of the application. The process of making a decision at this scale is often so painful, unproductive, and tiresome that most developers shy away from bringing it up in the first place. The micro frontends approach makes it easier to evolve your application over time in the areas where it makes sense.

1.2.4 The benefits of independence

Autonomy is one of the critical benefits of microservices and also of micro frontends. It comes in handy when teams decide to make more significant changes as described in the previous section. But even when you are working in a homogeneous environment where everyone is using the same tech stack, it has its advantages.

Self-contained

Pages and fragments are self-contained. That means they bring their own markup, styles, and scripts, and should not have shared runtime dependencies. This isolation makes it possible for a team to deploy a new feature in a fragment without having to consult with other teams first. An update may also come with an upgraded version of the JavaScript framework they are using. Because the fragment is isolated, this is not a big deal. (See figure 1.12.)

At first sight, it sounds wasteful that every team brings their own assets. This is particularly true when all teams are using the same stack. But this mode of working enables teams to move much faster and deliver features more quickly.

Figure 1.12 Fragments are self-contained and upgradeable independently of the page they are embedded in.

Technical overhead

Backend microservices introduce overhead. You need more computing resources to, for example, run different Java applications in their own virtual machine or container. But the fact that the backend services are themselves much smaller than a monolith also comes with advantages. You can run a service on smaller and cheaper hardware. You can scale specific services by running multiple instances of it and don’t have to multiply the complete monolith. You can always solve this with money and buy more or larger server instances.

This scaling does not apply to the frontend code. The bandwidth and resources of your customer’s devices are limited. However, the overhead does not scale linearly with the number of teams. It heavily depends on how teams build their applications. In chapter 11, we will explore metrics to qualify and learn techniques to mitigate these effects. But it’s safe to say that the team isolation comes with an extra cost.

So, why do we do this at all? Why don’t we build a large React application where every team is responsible for different parts of it? One team only works on the components of the product page; the other team builds the checkout pages. One source code repository, one React application.

Shared nothing

The reasoning behind this is the realization that communication between teams is expensive--really expensive. When you want to change a piece that others rely on, be it just a utility library, you have to inform everyone, wait for their feedback, and maybe discuss other options. The more people you have, the more cumbersome this gets.

The goal is to share as little as possible to enable faster feature development. Every shared piece of code or infrastructure has the potential for creating a non-trivial amount of management overhead. This approach is also called shared nothing architecture. The nothing sounds a bit harsh, and in reality, it’s not that black and white. But in general, micro frontend projects have a strong tendency to accept redundancy in favor of more autonomy and higher iteration speeds. We’ll touch on this principle at various points in this book.

1.3 The downsides of micro frontends

As stated earlier, the micro frontends approach is all about equipping autonomous teams with everything they need to create meaningful features for the customer. This autonomy is powerful but does not come for free.

1.3.1 Redundancy

Everyone who studies computer science is trained to minimize redundancy in the systems they create, be it the normalization of data in a relational database or the extraction of similar pieces of code into a shared function. The goal is to increase efficiency and consistency. Our eyes and minds have learned to find redundant code and come up with a solution to eliminate it.

Having multiple teams side by side that build and run their own stack introduces a lot of redundancy. Every team needs to set up and maintain its own application server, build process and continuous integration pipeline, and might ship redundant JavaScript/CSS code to the browser. Here are two examples where this is an issue:

• A critical bug in a popular library can’t be fixed in one central place. All teams that use it must install and deploy the fix themselves.

• When one team has put in the work to make their build process twice as fast, the other teams don’t automatically benefit from this change. This team has to share this information with the others. The other teams have to implement the same optimization on their own.

The reasoning behind this shared-nothing architecture is that the costs associated with these redundancies are smaller than the negative impacts that inter-team dependencies introduce.

1.3.2 Consistency

This architecture requires all teams to have their own database to be fully independent. But sometimes one team needs data that another team owns. In an online store, the product is a good example of this. All teams need to know what products the shop offers. A typical solution for this is data replication using an event bus or a feed system. One team owns the product data. The other teams replicate that data regularly. When one team goes down, the other teams are not affected and still have access to their local representation of the data. But these replication mechanisms take time and introduce latency. Thus changes in price or availability might be inconsistent for brief periods of time. A promoted product with a discount on the homepage might not have this discount in the shopping cart. When everything works as expected, we are talking about delays in the region of milliseconds or seconds, but when something goes wrong, this duration can be longer. It’s a trade-off that favors robustness over guaranteed consistency.

1.3.3 Heterogeneity

Free technology choice is one of the most significant advantages that micro frontends introduce, but it’s also one of the more controversial points. Do I want all development teams to have a completely different technology stack? That makes it harder for developers to switch from one team to another or even exchange best practices.

But just because you can does not mean that you have to pick a different stack. Even when all teams opt to use the same technologies, the core benefits of autonomous version upgrades and less communication overhead remain.

I’ve experienced different levels of heterogeneity in the projects I’ve worked on. From “Everyone uses the same tech,” to “We have a list of proven technologies. Pick what fits best and run with it.” You should discuss the level of freedom and tech-diversity that is acceptable for your project and company up front to have everyone on the same page.

1.3.4 More frontend code

As stated earlier, sites that are built using micro frontends typically require more JavaScript and CSS code. Building fragments that can run in isolation introduces redundancy. That said, the required code does not scale linearly with the number of teams or fragments. But it’s extra essential to have an eye on web performance from the start.

1.4 When do micro frontends make sense?

As with all approaches, micro frontends are not a silver bullet and won’t magically solve all your problems. It’s essential to understand the benefits and also the limitations.

1.4.1 Good for medium-to-large projects

Micro frontends architecture is a technique that makes scaling projects easier. When you are working on an application with a handful of people, scaling is probably not your main issue. The Two-Pizza Team Rule suggested by Amazon CEO Jeff Bezos is an indicator for a good team size. 5 It says that a team is too big when two large pizzas can’t feed it. In larger groups, communication overhead increases, and decision making gets complicated. In practice, this means that the perfect team size is between 5 to 10 people.

When the team exceeds 10 people, it’s worthwhile considering a team split. Doing a vertical micro frontend-style split is an option you should look into. I’ve worked on different micro frontends projects in the e-commerce field with two to six teams, and 10 to 50 people in total. For this project size, the micro frontends model works pretty well. But it’s not limited to that size.

Companies like Zalando, IKEA, and DAZN use this end-to-end approach at a much larger scale, where every team is responsible for a more narrow set of features. In addition to the feature teams, Spotify introduced the concept of infrastructure squads. They act as support teams that build tools like A/B testing for the feature teams to make them more productive. In chapter 13, we’ll dive deeper into topics like this.

1.4.2 Works best on the web

Though the ideas behind micro frontends are not limited to a specific platform, they work best on the web. Here the openness of the web plays to its strength.

Native monolith

Native applications for controlled platforms like iOS or Android are monolithic by design. Composing and replacing functionality on the fly is not possible. For updating a native app, you have to build a single application bundle that’s then submitted to Apple’s or Google’s review process. A way around this is to load parts of the application from the web. Embedded browsers or WebViews can help to keep the native part of the app to a minimum. But when you have to implement native UI, it’s hard to have multiple end-to-end teams working on it without stepping on each other’s toes.

It is of course always possible that every vertical team could have a web frontend and also expose their functionality through a REST API. You could build other user interfaces like native apps on top of these APIs. A native app would then reuse the existing business logic of the teams. But it would still form a horizontal monolithic layer that sits on top. So, if the web is your target platform, micro frontends might be a good fit. If you have to target native as well, you have to make some sacrifices. In this book, we will focus on web development and not cover strategies to apply micro frontends for building native applications.

Multiple frontends per team

A team is also not limited to only one frontend. In e-commerce, it’s common to have a front-office (customer-facing) and a back-office (employee-facing) side of your shop. The team that builds the checkout for the end user will, for example, also make the associated help desk functionality for the customer hotline. They might also build the WebView-based version of the checkout that a native app can embed.

1.4.3 Productivity versus overhead

Dividing your application into autonomous systems brings a lot of benefits, but does not come for free.

Setup

When starting fresh, you need to find good team boundaries, set up the systems, and implement an integration strategy. You need to establish common rules that all teams agree on, like using namespaces. It’s also important to provide ways for people to exchange knowledge between teams.

Organizational complexity

Having smaller vertical systems reduces the technical complexity of the individual systems. But running a distributed system adds its complexity on top.

Compared to a monolithic application, there is a new class of problems you have to think about. Which team gets paged on the weekend when it’s not possible to add an item to the basket? The browser is a shared runtime environment. A change from one team might have negative performance effects on the complete page. It’s not always easy to find out who’s responsible.

You will probably need an extra shared service for your frontend integration. Depending on your choice, it might not come with a lot of maintenance work. But it’s one more piece to think about.

When done right, the boost in productivity and motivation should be more significant than the added organizational complexity.

1.4.4 Where micro frontends are not a great fit

But of course, micro frontends are not perfect for every project. As stated earlier, they are a solution for scaling development. If you only have a handful of developers and communication is no issue, the introduction of micro frontends won’t bring much value.

It’s crucial to know the domain you are working in well to make good vertical cuts. Ideally, it should be obvious which team is responsible for implementing a feature. Unclear or overlapping team missions will lead to uncertainty and long discussions.

I’ve spoken to people working in startups that have tried this model. Everything worked fine up until the point the company needed to pivot its business model. It is of course possible to reorganize the teams and the associated software, but it creates a lot of friction and extra work. Other organizational approaches are more flexible.

If you need to create a lot of different apps and native user interfaces to run on every device, that might also become tricky for one team to handle. Netflix is famous for having an app for nearly every platform that exists: TVs, set-top boxes, gaming consoles, phones, and tablets. They have dedicated user interface teams for these platforms. That said, the web gets more and more capable and popular as an application platform, which makes it possible to target different platforms from one codebase.

1.4.5 Who uses micro frontends?

The concepts and ideas described here are not new. Amazon does not talk a lot about its internal development structure. However, several Amazon employees reported that their e-commerce site has been developed like this for many years now. Amazon also uses a UI integration technique that assembles the different parts of the page before it reaches the customer.

Micro frontends are indeed quite popular in the e-commerce sector. In 2012 the Otto Group, 6 a Germany-based mail-order company and one of the world’s largest e-commerce players, started to split up its monolith. The Swedish furniture company IKEA 7 and Zalando, 8 one of Europe’s biggest fashion retailers, moved to this model. Thalia, 9 a German bookstore chain, rebuilt its e-reader store into vertical slices to increase development speed.

But micro frontends are also used in other industries. Spotify 10 organizes itself in autonomous end-to-end teams called Squads. SAP published a framework 11 to integrate different applications. Sports streaming service DAZN 12 also rebuilt their monolithic frontend as a micro frontends architecture.

Summary

• Micro frontends are an architectural approach and not a specific technique.

• Micro frontends remove the team barrier between frontend and backend developers by introducing cross-functional teams.

• With the micro frontends approach, the application gets divided into multiple vertical slices that span from database to user interface.

• Each vertical system is smaller and more focused. It’s therefore easier to understand, test, and refactor than a monolith.

• Frontend technology is changing fast. Having an easy way to evolve your application is a valuable asset.

• Setting the team boundaries along the user journey and customer needs is a good pattern.

• A team should have a clear mission like “Help the customer to find the product they are looking for.”

• A team can own a complete page or deliver a piece of functionality via a fragment.

• A fragment is a mini-application that is self-contained, which means it brings everything it needs with it.

• The micro frontends model typically comes with more code for the browser. It’s vital to address web performance from the start.

• There are multiple frontend integration techniques. They work either on the client or the server.

• Having a shared design system helps to achieve a consistent look and feel across all team frontends.

• To make good vertical cuts it’s important to know your company’s domain well. Changing responsibilities afterward works but creates friction.

---