Micro Frontends in Action
()
About this ebook
Summary
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.
Purchase of the print book includes a free eBook in PDF, Kindle, and ePub formats from Manning Publications.
About the Technology
Micro frontends deliver the same flexibility and maintainability to browser-based applications that microservices provide for backend systems. You design your project as a set of standalone components that include their own interfaces, logic, and storage. Then you develop these mini-applications independently and compose them in the browser.
About the Book
Micro Frontends in Action teaches you to apply the microservices approach to the frontend. You’ll start with the core micro frontend design ideas. Then, you’ll build an e-commerce application, working through practical issues like server-side and client-side composition, routing, and maintaining a consistent look and feel. Finally, you’ll explore team workflow patterns that maximize the benefit of developing application components independently.
What’s Inside
- Create a unified frontend from independent applications
- Combine JavaScript code from multiple frameworks
- Browser and server-side composition and routing
- Implement effective dev teams and project workflow
About the Reader
For web developers, software architects, and team leaders.
About the Author
Michael Geers is a software developer specializing in building user interfaces.
Table of Contents
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
Related to Micro Frontends in Action
Related ebooks
Testing JavaScript Applications Rating: 5 out of 5 stars5/5Microservices in .NET, Second Edition Rating: 0 out of 5 stars0 ratingsRe-Engineering Legacy Software Rating: 0 out of 5 stars0 ratingsFunctional Programming in C#, Second Edition Rating: 0 out of 5 stars0 ratingsAWS Lambda in Action: Event-driven serverless applications Rating: 0 out of 5 stars0 ratingsInfrastructure as Code, Patterns and Practices: With examples in Python and Terraform Rating: 0 out of 5 stars0 ratingsProgressive Web Apps Rating: 0 out of 5 stars0 ratingsJavaScript Domain-Driven Design Rating: 3 out of 5 stars3/5Software Mistakes and Tradeoffs: How to make good programming decisions Rating: 0 out of 5 stars0 ratingsBuilding large scale web apps Rating: 0 out of 5 stars0 ratingsHow To Build Microservices: Top 10 Hacks To Modeling, Integrating & Deploying Microservices Rating: 0 out of 5 stars0 ratingsBlazor in Action Rating: 0 out of 5 stars0 ratingsSeriously Good Software: Code that works, survives, and wins Rating: 5 out of 5 stars5/5API Design Patterns Rating: 5 out of 5 stars5/5Elasticsearch in Action Rating: 0 out of 5 stars0 ratingsFive Lines of Code: How and when to refactor Rating: 0 out of 5 stars0 ratingsUnit Testing Principles, Practices, and Patterns Rating: 4 out of 5 stars4/5Docker in Action, Second Edition Rating: 3 out of 5 stars3/5GraphQL in Action Rating: 2 out of 5 stars2/5API Security in Action Rating: 5 out of 5 stars5/5Microservices Security in Action Rating: 0 out of 5 stars0 ratingsChaos Engineering: Site reliability through controlled disruption Rating: 5 out of 5 stars5/5Microservices Patterns: With examples in Java Rating: 5 out of 5 stars5/5Secure by Design Rating: 4 out of 5 stars4/5Event Processing in Action Rating: 0 out of 5 stars0 ratingsHTTP/2 in Action Rating: 0 out of 5 stars0 ratingsGood Code, Bad Code: Think like a software engineer Rating: 5 out of 5 stars5/5Serverless Architectures on AWS: With examples using AWS Lambda Rating: 0 out of 5 stars0 ratingsMicroservices in Action Rating: 0 out of 5 stars0 ratingsRxJS in Action Rating: 0 out of 5 stars0 ratings
Internet & Web For You
How to Be Invisible: Protect Your Home, Your Children, Your Assets, and Your Life Rating: 4 out of 5 stars4/5Coding For Dummies Rating: 5 out of 5 stars5/5Coding All-in-One For Dummies Rating: 4 out of 5 stars4/5The Hacker Crackdown: Law and Disorder on the Electronic Frontier Rating: 4 out of 5 stars4/5Social Engineering: The Science of Human Hacking Rating: 3 out of 5 stars3/5Podcasting For Dummies Rating: 4 out of 5 stars4/5How To Start A Profitable Authority Blog In Under One Hour Rating: 5 out of 5 stars5/5Grokking Algorithms: An illustrated guide for programmers and other curious people Rating: 4 out of 5 stars4/5Six Figure Blogging Blueprint Rating: 5 out of 5 stars5/5No Place to Hide: Edward Snowden, the NSA, and the U.S. Surveillance State Rating: 4 out of 5 stars4/5How to Disappear and Live Off the Grid: A CIA Insider's Guide Rating: 0 out of 5 stars0 ratingsCybersecurity All-in-One For Dummies Rating: 0 out of 5 stars0 ratingsWordPress For Dummies Rating: 0 out of 5 stars0 ratingsThe Cyber Attack Survival Manual: Tools for Surviving Everything from Identity Theft to the Digital Apocalypse Rating: 0 out of 5 stars0 ratingsCybersecurity For Dummies Rating: 4 out of 5 stars4/5Six Figure Blogging In 3 Months Rating: 4 out of 5 stars4/5Python QuickStart Guide: The Simplified Beginner's Guide to Python Programming Using Hands-On Projects and Real-World Applications Rating: 0 out of 5 stars0 ratingsEverybody Lies: Big Data, New Data, and What the Internet Can Tell Us About Who We Really Are Rating: 4 out of 5 stars4/5Mike Meyers' CompTIA Security+ Certification Guide, Third Edition (Exam SY0-601) Rating: 5 out of 5 stars5/5The Gothic Novel Collection Rating: 5 out of 5 stars5/5Get Rich or Lie Trying: Ambition and Deceit in the New Influencer Economy Rating: 0 out of 5 stars0 ratingsThe Beginner's Affiliate Marketing Blueprint Rating: 4 out of 5 stars4/5Wordpress for Beginners: The Easy Step-by-Step Guide to Creating a Website with WordPress Rating: 5 out of 5 stars5/5Learn JavaScript in 24 Hours Rating: 3 out of 5 stars3/5The Digital Marketing Handbook: A Step-By-Step Guide to Creating Websites That Sell Rating: 5 out of 5 stars5/5
Reviews for Micro Frontends in Action
0 ratings0 reviews
Book preview
Micro Frontends in Action - Michael Geers
Micro Frontends in Action
Michael Geers
To comment go to liveBook
Manning
Shelter Island
For more information on this and other Manning titles go to
manning.com
Copyright
For online information and ordering of these and other Manning books, please visit manning.com. The publisher offers discounts on these books when ordered in quantity.
For more information, please contact
Special Sales Department
Manning Publications Co.
20 Baldwin Road
PO Box 761
Shelter Island, NY 11964
Email: [email protected]
©2020 by Manning Publications Co. All rights reserved.
No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher.
Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in the book, and Manning Publications was aware of a trademark claim, the designations have been printed in initial caps or all caps.
♾ Recognizing the importance of preserving what has been written, it is Manning’s policy to have the books we publish printed on acid-free paper, and we exert our best efforts to that end. Recognizing also our responsibility to conserve the resources of our planet, Manning books are printed on paper that is at least 15 percent recycled and processed without the use of elemental chlorine.
ISBN: 9781617296871
contents
preface
acknowledgment
about this book
about the author
about the cover illustration
Part 1: Getting started with micro frontends
1 What are micro frontends?
1.1 The big picture
Systems and teams
The frontend
Frontend integration
Shared topics
1.2 What problems do micro frontends solve?
Optimize for feature development
No more frontend monolith
Be able to keep changing
The benefits of independence
1.3 The downsides of micro frontends
Redundancy
Consistency
Heterogeneity
More frontend code
1.4 When do micro frontends make sense?
Good for medium-to-large projects
Works best on the web
Productivity versus overhead
Where micro frontends are not a great fit
Who uses micro frontends?
2 My first micro frontends project
2.1 Introducing The Tractor Store
Getting started
Running this book’s example code
2.2 Page transition via links
Data ownership
Contract between the teams
How to do it
Dealing with changing URLs
The benefits
The drawbacks
When do links make sense?
2.3 Composition via iframe
How to do it
The benefits
The drawbacks
When do iframes make sense?
2.4 What’s next?
Part 2: Routing, composition, and communication
3 Composition with Ajax and server-side routing
3.1 Composition via Ajax
How to do it
Namespacing styles and scripts
Declarative loading with h-include
The benefits
The drawbacks
When does an Ajax integration make sense?
Summary
3.2 Server-side routing via Nginx
How to do it
Namespacing resources
Route configuration methods
Infrastructure ownership
When does it make sense?
4 Server-side composition
4.1 Composition via Nginx and Server-Side Includes (SSI)
How to do it
Better load times
4.2 Dealing with unreliable fragments
The flaky fragment
Integrating the Near You fragment
Timeouts and fallbacks
Fallback content
4.3 Markup assembly performance in depth
Parallel loading
Nested fragments
Deferred loading
Time to first byte and streaming
4.4 A quick look into other solutions
Edge-Side Includes
Zalando Tailor
Podium
Which solution is right for me?
4.5 The good and bad of server-side composition
The benefits
The drawbacks
When does server-side integration make sense?
5 Client-side composition
5.1 Wrapping micro frontends using Web Components
How to do it
Wrapping your framework in a Web Component
5.2 Style isolation using Shadow DOM
Creating a shadow root
Scoping styles
When to use Shadow DOM
5.3 The good and bad of using Web Components for composition
The benefits
The drawbacks
When does client-side integration make sense?
6 Communication patterns
6.1 User interface communication
Parent to fragment
Fragment to parent
Fragment to fragment
Publish/Subscribe with the Broadcast Channel API
When UI communication is a good fit
6.2 Other communication mechanisms
Global context and authentication
Managing state
Frontend-backend communication
Data replication
7 Client-side routing and the application shell
7.1 App shell with flat routing
What’s an app shell?
Anatomy of the app shell
Client-side routing
Rendering pages
Contracts between app shell and teams
7.2 App shell with two-level routing
Implementing the top-level router
Implementing team-level routing
What happens on a URL change?
App shell APIs
7.3 A quick look into the single-spa meta-framework
How single-spa works
7.4 The challenges of a unified single-page app
Topics you need to think about
When does a unified single-page app make sense?
8 Composition and universal rendering
8.1 Combining server- and client-side composition
SSI and Web Components
Contract between the teams
Other solutions
8.2 When does universal composition make sense?
Universal rendering with pure server-side composition 153 Increased complexity
Universal unified single-page app?
9 Which architecture fits my project?
9.1 Revisiting the terminology
Routing and page transitions
Composition techniques
High-level architectures
9.2 Comparing complexity
Heterogeneous architectures
9.3 Are you building a site or an app?
The Documents-to-Applications Continuum
Server, client, or both
9.4 Picking the right architecture and integration technique
Strong isolation (legacy, third party)
Fast first-page load/progressive enhancement
Instant user feedback
Soft navigation
Multiple micro frontends on one page
Part 3: How to be fast, consistent, and effective
10 Asset loading
10.1 Asset referencing strategies
Direct referencing
Challenge: Cache-busting and independent deployments
Referencing via redirect (client)
Referencing via include (server)
Challenge: Synchronizing markup and asset versions
Inlining
Integrated solutions (Tailor, Podium, ...)
Quick summary
10.2 Bundle granularity
HTTP/2
All-in-one bundle
Team bundles
Page and fragment bundles
10.3 On-demand loading
Proxy micro frontends
Lazy loading CSS
11 Performance is key
11.1 Architecting for performance
Different teams, different metrics
Multi-team performance budgets
Attributing slowdowns
Performance benefits
11.2 Reduce, reuse... vendor libraries
Cost of autonomy
Pick small
One global version
Versioned vendor bundles
Don’t share business code
12 User interface and design system
12.1 Why a design system?
Purpose and role
Benefits
12.2 Central design system versus autonomous teams
Do I need my own design system?
Process, not project
Ensure sustained budget and responsibility
Get buy-in from the teams
Development process: Central versus federated
Development phases
12.3 Runtime versus build-time integration
Runtime integration
Versioned package
12.4 Pattern library artifacts: Generic versus specific
Choose your component format
There will be change
12.5 What goes into the central pattern library?
The costs of sharing components
Central or local?
Central and local pattern libraries
13 Teams and boundaries
13.1 Aligning systems and teams
Identifying team boundaries
Team depth
Cultural change
13.2 Sharing knowledge
Community of practice
Learning and enabling
Present your work
13.3 Cross-cutting concerns
Central infrastructure
Specialized component team
Global agreements and conventions
13.4 Technology diversity
Toolbox and defaults
Frontend blueprint
Don’t fear the copy
The value of similarity
14 Migration, local development, and testing
14.1 Migration
Proof of concept and building a lighthouse
Strategy #1: Slice-by-slice
Strategy #2: Frontend first
Strategy #3: Greenfield and big bang
14.2 Local development
Don’t run another team’s code
Mocking fragments
Fragments in isolation
Pulling other teams micro frontends from staging or production
14.3 Testing
index
front matter
preface
I’ve been developing applications for the web for over 20 years now. On this journey, I’ve seen a variety of different-sized projects. I’ve built tiny side-projects all by myself, have been part of smaller projects with a couple of people, and have also worked on larger projects that involved more people than can comfortably fit around our kitchen table.
In 2014, my colleagues at neuland Büro für Informatik and I had the task of rebuilding an e-commerce system for a department store chain. The existing monolithic shop not only suffered from performance issues. The major pain-point was an organizational one: adding new features took a long time and often broke unrelated parts of the system. Increasing the development team made this even worse. Our client not only wanted a cleaner-structured new software, but they also wanted to architect the new system so that multiple teams could work on it independently without stepping on each other’s toes. This parallel feature development was crucial to their plan of digitally expanding their business. We opted for an architecture we called verticalization: the establishment of different cross-functional teams that build and evolve a specific area of the shop from database to user interface. The individual team applications were able to work autonomously and only integrated in the frontend. This frontend integration looked easy on paper, but we had to learn a lot to do it effectively. In later projects, we had the chance to refine our techniques and learn from this experience.
At the same time, other companies were already building their software this way. However, there was no unique name for this architecture. What search term should I use if I want to learn about the challenges involved in building a web application with multiple autonomous teams? In November 2016, the ThoughtWorks Technology Radar changed this by coining the term micro frontends. The introduction of this name made it possible for the development community to share best practices, techniques, and tools around this architecture.
The following summer, I was able to dedicate some time to write down our experiences. I distilled the techniques we were using into standalone sample projects and published the content at https://micro-frontends.org. From that point, things took on a life of their own: people from across the internet invited me to speak at their conferences. Magazines asked me to write articles. Developers from the community volunteered to translate the site into different languages.
To top things off, I was approached by Nicole and Brian from Manning at the beginning of last year. They asked if I could see myself writing a book on this topic. My first thought was, What a hilarious idea--I’m not a book writer! I don’t even enjoy reading texts. I much prefer listening, writing code, building systems, and solving problems.
But since this seemed like a once-in-a-lifetime opportunity, I gave my reply some thought. I had long consultations with friends and family and some sleepless nights, but in the end, I accepted the challenge. After all, I like explaining things. Doing it in book form, with diagrams (I love good diagrams) and code examples would be a venture where I could learn a lot. In retrospect, I’m happy with this decision--and the final result you are looking at right now.
acknowledgments
The cover of the book prominently features my name as the author. But this is not a single-person effort. It takes a village to create a book like this. I would like to thank
Emma, Noah, and Finn for your patience and understanding. In the last year, I spent much less time with you than I’d like.
Sarah, my wonderful wife, for your repeated encouragement and your fresh perspectives. You jumped in when I did long evenings or worked through weekends. You rock!
Tricia Louvar, my editor at Manning. You guided me through this journey, aggregated feedback, challenged my decisions, and pointed me to sections that needed more clarity.
Dennis Reimann, Fabricius Seifert, Marco Pantaleo, and Alexander Knöller for bouncing ideas, reading my drafts, and iterating on graphics.
The team at Manning who worked with me to plan, develop, review, edit, produce and promote this book. Thanks to Ana Romac, Brian Sawyer, Candace Gillhoolley, Christopher Kaufmann, Ivan Martinović, Lana Klasic, Louis Lazaris, Matko Hrvatin, Mayur Patil, Nicole Butterfield, Radmila Ercegovac, Deirdre Hiam, Ben Berg, and Melody Dolab.
My folks at neuland Büro für Informatik for giving me the ability to continuously learn on new projects and providing space to create this book. Thank you, Jens and Thomas, and thanks to all the others who encouraged me to do this.
All book reviewers who read my manuscript in various stages. Your feedback helped me to improve my chapters and adjust the focus. Thanks to Adail Retamal, Alan Bogusiewicz, Barnaby Norman, David Osborne, David Paccoud, Dwight Wilkins, George Onofrei, Ivo Sánchez Checa Crosato, Karthikeyarajan Rajendran, Luca Mezzalira, Luis Miguel Cabezas Granado, Mario-Leander Reimer, Matt Ferderer, Matthew Richmond, Miguel Eduardo Gil Biraud, Mladen Đurić, Potito Coluccelli, Raushan Jha, Richard Vaughan, Ryan Burrows, Tanya Wilke, and Tony Sweets.
All MEAP readers. Receiving encouragement from good friends is one thing. Seeing that people from all over the world put in real money to get early access felt remarkable. You motivated me to pull through this, even if I’d sometimes rather have spent the evening on the couch.
Samantha, macOS’s text-to-speech voice, for relentlessly reading back every version of every paragraph I’ve written. Take that, dyslexia! A toast to accessibility.
about this book
I’ve written Micro Frontends in Action to explain the concepts and motivations for adopting a micro frontends architecture. You’ll learn a series of practical techniques to accomplish frontend integration and communication. Since the landscape is pretty new and use cases can be very different, I decided not to go with one specific micro frontends library, tool, or platform. Instead, you’ll learn the fundamental mechanisms by building directly on existing web standards wherever possible. At the end of the book, we’ll address overarching topics like how to ensure good performance, coherent design, and knowledge sharing in a distributed team structure.
Who should read this book
This book has the word frontend in its title, and in most chapters, we work at some aspect of the user interface. However, this is not only a book for frontend developers. If your expertise is more on the backend-side, or you are a software architect, you won’t be lost. As long as you have a basic understanding of HTML, CSS, JavaScript, and networking, you’re good to go. You don’t need to be familiar with specific libraries or frontend frameworks to understand the techniques described in this book.
How this book is organized: a roadmap
This book has three parts and a total of 14 chapters.
Part 1 explains what micro frontends are and when it’s a good idea to use them:
Chapter 1 paints the big picture. It explains what micro frontends are and goes through the benefits and drawbacks of this architecture.
Chapter 2 walks you through your first micro frontends project. We’ll start simply and won’t use fancy techniques--just plain old links and iframes. In this chapter, we create a solid basis to iterate upon.
Part 2 focuses on frontend integration techniques. It gives answers to the question How do user interfaces from different teams come together in the browser?
You’ll learn approaches for routing and composition for server- and client-rendered applications:
Chapter 3 illustrates how to do composition using Ajax calls and implement server-based routing with a shared Nginx web server.
Chapter 4 dives deep into server-side composition. You’ll learn how to compose markup from different applications via Nginx’s SSI feature. We’ll shine a light on some techniques to ensure proper performance even if something goes wrong. We’ll also discuss some alternative implementations like ESI, Tailor, and Podium.
Chapter 5 addresses composition for client-rendered applications. You’ll learn how to compose UIs written in different technologies into a single view by leveraging the power of Web Components.
Chapter 6 covers communication strategies. We focus on in-browser communication between different micro frontends. At the end of the chapter, we also address topics like backend communication and how to share information like a login status across teams.
Chapter 7 introduces the concept of the application shell. The shell enables you to build a full client-rendered user experience that consists of single-page applications built by different teams. You learn how to develop an application shell from scratch, and we finish by taking a look at the popular single-spa library.
Chapter 8 describes how you can accomplish universal rendering in a micro frontends architecture. We do this by combining server- and client-side integration techniques you’ve already learned in the preceding chapters.
Chapter 9 rounds off the second part by putting the learned techniques into context. It provides you with a set of questions and tools to decide which micro frontend architecture is the best one for your project.
Part 3 explains practices to ensure good end-user performance and a consistent user interface. It guides how to organize your teams to get the most value out of the micro frontends architecture:
Chapter 10 dives into asset-loading strategies to deliver the required JavaScript and CSS code to the customer’s browser in a performant way without introducing inter-team coupling.
Chapter 11 describes how techniques like performance budgets can work even if code from multiple teams are active on a single page. We discuss methods to reduce the amount of vendor code like framework runtimes.
Chapter 12 illustrates how to design systems that can help to deliver a consistent user interface to your customers, even if different teams build it. You’ll learn some organizational patterns that have proven valuable. We compare different ways of integrating a pattern library with the micro frontends and discuss their technical implications.
Chapter 13 focuses on the organization. It answers the questions How cross-functional should my teams be?
and How do I identify good system boundaries?
You’ll learn about ways to effectively share knowledge and organize cross-cutting concerns and shared infrastructure components.
Chapter 14 highlights some migration strategies for moving from a monolithic application to a micro frontends architecture. It also addresses the challenges of local development and testing.
About the code
All source code in the book is presented in a monospaced typeface like this, which sets it off from the surrounding text. In many listings, the code is annotated to point out key concepts, and numbered bullets are used in the text to provide additional information about the code. Throughout this book, we’ll build an e-commerce application. We start small and expand on it chapter by chapter. Most listings are shortened [...] to avoid repeating code.
The full source code is available for download from the publisher’s website at https://www.manning.com/books/micro-frontends-in-action and GitHub at https:// github.com/naltatis/micro-frontends-in-action-code. I recommend downloading and running the code on your machine as you move through the chapters. You can also find a hosted version at https://the-tractor.store. There you can interact with all book examples and look at the associated code directly in your browser.
The applications in this book are built using static files. You don’t need to know a specific backend language like Java, Python, C#, or Ruby. To start the applications we use ad hoc web servers which require Node.js to be installed on your machine. In the chapters that cover server-side routing and composition, we use Nginx. You’ll find the installation instructions in the first chapter that requires it.
Online resources
Purchase of Micro Frontends in Action includes free access to a private web forum run by Manning Publications where you can make comments about the book, ask technical questions, and receive help from the author and from other users. To access the forum, go to https://livebook.manning.com/book/micro-frontends-in-action. You can also learn more about Manning’s forums and the rules of conduct at https://livebook .manning.com/#!/discussion.
Manning’s commitment to our readers is to provide a venue where a meaningful dialogue between individual readers and between readers and the author can take place. It is not a commitment to any specific amount of participation on the part of the author, whose contribution to the forum remains voluntary (and unpaid). We suggest you try asking the author some challenging questions lest his interest stray! The forum and the archives of previous discussions will be accessible from the publisher’s website as long as the book is in print
about the author
Michael Geers is a software developer specializing in building user interfaces. He has written software for the web since he was a teenager. In the last few years, he has worked on various customer projects with verticalized architectures. He shares his experiences on this topic at international conferences, and in a series of magazine articles, and runs the site https://micro-frontends.org.
about the cover illustration
The figure on the cover of Micro Frontends in Action is captioned Habitante de la Calabre,
or a Woman from Calabria. The illustration is taken from a collection of dress costumes from various countries by Jacques Grasset de Saint-Sauveur (1757-1810), titled Costumes de Différents Pays, published in France in 1797. Each illustration is finely drawn and colored by hand. The rich variety of Grasset de Saint-Sauveur’s collection reminds us vividly of how culturally apart the world’s towns and regions were just 200 years ago. Isolated from each other, people spoke different dialects and languages. In the streets or in the countryside, it was easy to identify where they lived and what their trade or station in life was just by their dress.
The way we dress has changed since then and the diversity by region, so rich at the time, has faded away. It is now hard to tell apart the inhabitants of different continents, let alone different towns, regions, or countries. Perhaps we have traded cultural diversity for a more varied personal life--certainly for a more varied and fast-paced technological life.
At a time when it is hard to tell one computer book from another, Manning celebrates the inventiveness and initiative of the computer business with book covers based on the rich diversity of regional life of two centuries ago, brought back to life by Grasset de Saint-Sauveur’s pictures.
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