Micro Frontends in Action

Michael Geers

• Verlag: Manning Publications
• Jahr: 2020
• ISBN:
  9781617296871
• Thema: Computer Science
• Thema: Software Development

Browser-based software can quickly become complex and difficult to maintain, especially when it's implemented as a large single-page application. By adopting the micro frontends approach and designing your web apps as systems of features, you can deliver faster feature development, easier upgrades, and pick and choose the technology you use in your stack. Micro Frontends in Action is your guide to simplifying unwieldy frontends by composing them from small, well-defined units.

Part 1. Getting started with micro frontends

Frontend development has evolved a lot over the last decade. The web applications we are building today have to load quickly, run on a broad range of devices, and should react swiftly to user interactions. For a lot of businesses, the web frontend is the prime interaction surface for their users. So it’s natural to put a lot of thought and attention to detail into its development.

When your project is small, and you’re working with a handful of developers, building a nice web application is a straightforward task. However, if your business has a large web application and wants to improve and add new features continually, a single team will quickly be overwhelmed. This is where the micro frontend architecture comes in. There we slice the application into pieces that multiple teams can work on independently. In chapter 1, you’ll learn the core concepts, understand the reasoning behind this architecture, and know what types of projects can benefit the most from it. In the second chapter, we’ll jump right into the code and build a minimal viable micro frontends project from scratch: The Tractor Store. This e-commerce project functions as the basis for the more advanced techniques you’ll unlock later in the book.

1 What are micro frontends?

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 t...

Inhaltsverzeichnis

• Micro Frontends in Action
• Copyright
• contents
• front matter
• Part 1. Getting started with micro frontends
• 1 What are micro frontends?
• 2 My first micro frontends project
• Part 2. Routing, composition, and communication
• 3 Composition with Ajax and server-side routing
• 4 Server-side composition
• 5 Client-side composition
• 6 Communication patterns
• 7 Client-side routing and the application shell
• 8 Composition and universal rendering
• 9 Which architecture fits my project?
• Part 3. How to be fast, consistent, and effective
• 10 Asset loading
• 11 Performance is key
• 12 User interface and design system
• 13 Teams and boundaries
• 14 Migration, local development, and testing
• index