Appendix A. What does the community think about micro-frontends?

Throughout this book, we have discussed what micro-frontends are, how we can create a micro-frontends architecture, and what the socio-technical impact of this paradigm is.

Note

As explained in Chapter 1, many companies implemented micro-frontends in production in many different ways.

I interviewed several industry professionals who are embracing micro-frontends in their organizations to share the breadth of uses.

Following are interviews with tech leads, architects, and developers sharing their development challenges with micro-frontends projects.

Enjoy the interviews!

Please introduce yourself.

I’m Felipe Guizar, a senior software engineer at Wizeline. I have over five years of experience working mainly with content publishing platforms for big media companies.

What is your experience with micro-frontends?

I haven’t had the opportunity to implement micro-frontends in a greenfield project yet. However, I’ve worked on several projects that migrated websites to new technologies.

On those projects, we agreed that migrating from scratch was not a good business approach because we can’t deliver new features until we finish the migration. Instead,we decided to look for an approach to gradually migrate the websites and set the basis for integrating new features easily, introducing micro-frontends to our solutions.

What benefits and pitfalls did you encounter in your journey with micro-frontends?

Context:

Frontend technologies (FE) evolve very fast. For instance, I’ve seen companies that started developing their applications using old frameworks/libraries (AngularJS, BackboneJS) years ago. At some point, new frameworks were introduced in the FE world (React, VueJs), and then developers started learning and choosing those as their main tech stack.

For those companies, it’s difficult to keep developers engaged and hire developers who are glad to maintain applications using old technologies.

Benefits:

Micro-frontends help to evolve applications along with the technologies. However, it’s not only about bringing the application up to date in terms of technology; it’s also about aligning the company tech stack with the developer’s expertise.

Pitfalls:

This architecture adds more complexity for managing different pipelines, versioning and integrating the micro-frontends in the host application. Additionally, managing authentication is one of the trickier parts.

Did you contribute to any OSS project related to micro-frontends? If so, which one?

Yes, I’m the creator of Ara Framework.

Ara Framework makes developing micro-frontends easier by integrating any view library (React, VueJS, Svelte) on any web technology/framework, such as NuxtJS, GatsbyJS, WordPress, Flask, and more.

When would you suggest using micro-frontends, and when we should avoid them?

I believe having good knowledge of the business domains is necessary to identify each micro-frontend’s boundaries; otherwise, it leads to bad abstractions that can introduce more complexity for integrating and communicating them.

At the end of your last micro-frontends project, what worked and what didn’t?

Server-side includes using a proxy server works well for integrating non-authenticated micro-frontends in non-JavaScript frameworks. This approach helps us to migrate partial views from WordPress to React along with the content necessary to render those views.

In the early days of the project, we tried to use authenticated micro-frontends using server-side rendering through the SSL proxy server (Nova Proxy). We faced issues forwarding the authentication header, but we realized we could just render those views from the client side using a kind of client-side includes (Nova Bridge).

https://ara-framework.github.io/website/docs/nova-architecture

https://ara-framework.github.io/website/docs/nova-bridge

Also, centralizing the SSL proxy server created the main point of failure. We tackled it by using the server as a sidecar proxy.

https://docs.microsoft.com/en-us/azure/architecture/patterns/sidecar

What are the must-have tools for developers to have an efficient experience with micro-frontends?

A command-line interface (CLI) for scaffolding, running services locally, and easily deploying micro-frontends.

For example, Ara Framework has a CLI to create new micro-frontends for different view libraries, and commands to run Nova Proxy and Nova Cluster locally.

What would you suggest for a person who wants to embrace this architecture?

Evaluate the problems you’re trying to solve against the challenges you’ll face implementing this architecture.

What was the impact of introducing micro-frontends to developers who didn’t know about them? What challenges have you faced?

It encouraged developers to be more involved in the business side, promoting a common language that improves communication. It also encouraged developers to be more involved in making architectural decisions.

However, when micro-frontends were announced in 2019 in the ThoughtWorks Radar as an “adopt technique” in the social networks, there were some misunderstandings about the main goal of micro-frontends. It’s still challenging to introduce the architecture to developers biased by those comments.

What was the developer experience like in your last project?

As I mentioned before a CLI tool significantly improves the developer experiences. However, we needed to extend the Ara CLI to automate deployments and provisioning infrastructure necessary to run the application.

Many developers are concerned about performance and design consistency with micro-frontends. What are your suggestions for overcoming these challenges?

I believe performance issues related to loading several micro-frontends views on the same page is a sign that micro-frontends boundaries are not well defined. A user flow can involve several subdomains but the user only interacts with one at a time. For example, when a user navigates to the product listing page (product subdomain) and chooses a product, they finally go to the payment page (payment subdomain).

I recommend lazy-loading each micro-frontend entry point based on routing (routes usually represent a subdomain involved in a user flow).

Obviously, there are cases when we have several subdomains on the same page. For example, in an article page, we have the content itself (content subdomain) and the comments and rating section (content feedback subdomain). Users mainly view an article to read the content. Micro-frontends give us the flexibility to server-side render the content and make it available as soon the user opens the page, and we can let the browser client-side render the other sections on demand (lazy-loading based on scrolling).

Regarding design consistency, I suggest using design systems with reusable components that are domain agnostic. Atomic design is a good methodology for implementing design systems in micro-frontends.

What are the first steps for working with micro-frontends?

Define the micro-frontends’ boundaries based on the business subdomains, and identify subdomains that interact together in the user flows.

Can you share the main thing to avoid when working with micro-frontends?

Avoid thinking of micro-frontends as components we can deploy and integrate independently (we can use Module Federation instead). Micro-frontends are views that represent a business subdomain.

What are the main challenges in embracing this architecture from your perspective?

  • - Identifying the business subdomains and defining the micro-frontend boundaries

  • - Looking for an approach to aggregate them in the host application

  • - Handling authentication and authorization

Would you like to share some useful resources about micro-frontends?

Micro-frontends in three words…

Evolutionary, resilient, agile

===================================

Please introduce yourself.

I’m Anthony Frehner. I currently work as a frontend architect, which means I have the privilege of working on just about anything related to the frontend :). I’ve spoken at React Rally, I’m helping drive the W3C CSS proposal for “vhc” units (name subject to change), and I’m a core-team member of single-spa. You can find me on GitHub at github.com/frehner and Twitter at twitter.com/aahfrena.

What is your experience with micro-frontends?

I was introduced to micro-frontends (MFEs) when I joined CanopyTax, which is the company where Joel Denning and Bret Little (the creators of single-spa and related tools) worked. It was an amazing transition to be in a place where anywhere from six to twelve— depending on the situation—squads were able to work autonomously. (Squads is a term that was taken from the Spotify model, but essentially they’re full teams that are centered around a feature instead of being organized by role.)

I left Canopy because another company was interested in setting single-spa up for two reasons: 1) to enable future growth and scale, and 2) to help gradually sunset their legacy application and write new code, while running both side-by-side. I like to think we were successful at both, and the company was later acquired.

I think that was one of the first implementations of single-spa which used SystemJS 3.0 with import maps, so it was fun to see how these new standards greatly simplified the infrastructure required for single-spa. That infrastructure would also later help form the foundation for single-spa’s “recommended setup.”

My current company is currently investigating using single-spa because it acquired a company that built a tool in a different frontend framework than the one we use, and we would like to potentially integrate the two without having to do a major rewrite of either.

What benefits and pitfalls did you encounter in your journey with micro-frontends?

You’ve heard this a thousand times, but MFEs aren’t a silver bullet. That being said, they have some great pros and a couple of cons to be aware of:

Pros:

  • * Team/squad independence. No release trains, code freezes, merge conflicts, long-lived feature branches, QA frustration with testing environments changing/not changing, etc.

  • * A shared infrastructure that means that everyone is always on the latest version of a library. For example, designers love it because changes to your style guide go out instantly to the whole app.

  • * A (variable) amount of freedom to experiment and let the best technologies rise out of those experiments, instead of being stuck on the legacy technology because of either the fear of trying something and it failing or not wanting to rework your whole app.

  • * Lazy loading built in, which means a better and faster user experience.

  • * Bundle sizes and speeds comparable to a monolithic app. There’s a misconception that MFEs are significantly bigger and slower than a monolith, and that’s simply not true.

  • * Ability to seamlessly combine legacy software with new software and to integrate software that may have come through an acquisition with in-house software.

  • * An amazing developer experience. You only have to run a single MFE locally at a time while all the others can just run their production code. Nearly every single developer that I’ve worked with has mentioned how much better the DX is for them over a monolithic setup.

  • * For single-spa at least, it’s based on web standards: ES modules, import maps, etc.

  • * Teams that are focused on vertical slices of the app translates into teams that are specialized and know their feature set really well.

However, there are some cons as well:

  • * On rare occasions, you will need to do an update on all your MFEs, which is a monotonous task.

  • * The shared infrastructure can be a double-edge sword. For example, it’s great to have your styleguide update for everyone at the same time, until you accidentally break something and now it’s broken everywhere.

  • * This is minor, but you need to ensure that your CSS is scoped so that one MFE’s CSS doesn’t conflict with another’s.

  • * The infrastructure takes a bit more work than just building a monolith. However, to put it into perspective, in my experience the vast majority (~90%) of DevOp’s time was spent working on the backend’s microservices infrastructure

Did you contribute to any OSS projects related to micro-frontends? If so, which one?

I’m a core-team member of single-spa, so I’ve worked on the library itself as well as the documentation, browser plugin, example repos, and so on, and I am active in the Slack channel. I’ve been a participant in other projects related to MFEs, namely SystemJS, the Import Map specification, and webpack’s Module Federation plugin.

When would you suggest using micro-frontends, and when we should avoid them?

I generally don’t recommend them for small teams of one to five developers. That being said, there are still situations where that can make sense. Beyond that, it really comes down to how comfortable (or willing to learn) you are with frontend architecture, such as CI/CD pipelines and webpack/rollup configurations.

At the end of your last micro-frontends project, what worked and what didn’t?

Almost everything went well, except for one thing: the decision to support multiple frameworks by using web components. In practice that turned into everyone still only using one framework, but at the cost of additional time and overhead to support web components instead of using framework-specific components. My recommendation is to stick to just one framework when at all possible.

What are the must-have tools for developers to have an efficient experience with micro-frontends?

With single-spa, it’s really just about getting the infrastructure up and running; after that, the tools used on a day-to-day basis are exactly the same as a monolith.

For the infrastructure, you need to understand import maps and webpack/rollup configuration and have a way to scope your CSS.

It’s also important to understand coupling and cohesion and how they relate to microservices. You want MFEs that are highly cohesive and have low coupling in order to succeed.

What would you suggest for a person who wants to embrace this architecture?

Ask yourself for what purpose do you want this infrastructure: If you’re doing it because you’re a small team but you want independent deploys, it may not be worth the effort.

What was the impact of introducing micro-frontends to developers who didn’t know about them? What challenges have you faced?
When I’ve had genuine conversations with developers about it, they generally are open to the idea but don’t know how to set it all up in practice. After helping them out, they’re almost always excited about it all and love it.

I’ve had conversations with people that are very hesitant about certain aspects (e.g. “the infrastructure is difficult” or “what about consistent styles?”) and the conversations generally go well, even if they still decide to not implement them. That’s ok! Not everyone is up to the task of spending a couple days to work on infrastructure, but at least some misconceptions were dispelled.

And then there’s been conversations with people who are completely unwilling to listen and just want to make memes about MFEs. In those situations, there hasn’t been much I could say that would help them understand.

What was the developer experience on your last project?

Excellent. There are open source tools for doing MFE overrides with single-spa, so that makes working on a MFE easy. Additionally, running only a portion of your whole app locally means that when you hit the save button, webpack takes only a fraction of a second to update instead of multiple seconds to recompile.

Many developers are concerned about performance and design consistency with micro-frontends, what are your suggestions for overcoming these challenges?

Regarding performance, you mainly just need to put constraints on your team, such as saying “We’ll only support Vue, not any other framework.” Just doing that will take care of 90% of your performance issues; the other 10% is no different than taking care of performance for a monolith.

As far as design consistency goes, that’s actually a strawman put up by people who haven’t used modern MFEs. You’ll find that your designs will actually be more consistent when you only have to deploy your styleguide once and it’s updated for all apps everywhere, instead of needing to npm-install your style guide in each app.

What are the first steps for working with micro-frontends?

Go to one of the example websites that exist for single-spa, and set up an override for one MFE. Try it out, and see what you like and don’t like. Then find us on GitHub, Twitter, or on Slack and ask questions.

Can you share the main thing to avoid when working with micro-frontends?

Just because you can have multiple frameworks, doesn’t mean you should. It’s still recommended to try and stick to one framework if at all possible.

What are the main challenges in embracing this architecture from your perspective?

Your willingness to be open to new ideas, and to work on infrastructure such as CI/CD pipelines and webpack/rollup. You also need to understand when you should create a new MFE versus adding to an existing one.

Would you like to share some useful resources about micro-frontends?

We try to keep the single-spa website up to date. Also, the single-spa Slack channel is open to anyone, and we frequently talk about tech-related things besides single-spa in the #randomstuff channel. The book Building Microservices is a good reference, even though it’s very backend focused.

Micro-frontends in three words…

Enables team independence

Please introduce yourself.

Joel Denning, frontend software dev and independent consultant. I’ve authored single-spa and maintain a lot of other open source, too. I made more than 4,000 GitHub contributions in the last year.

What is your experience with micro-frontends?

I’ve implemented micro-frontends at five companies, and consulted with several dozen more. I created several example repositories (github.com/vue-microfrontendss, github.com/react-microfrontends, github.com/polyglot-microfrontends). I talk to people every day in the single-spa Slack workspace and GitHub issue queues about implementing micro-frontends.

Which benefits and pitfalls did you encounter in your journey with micro-frontends?

Pros:

  1. 1. Independently deployed micro-frontends are a huge organizational win. This is the primary benefit in my opinion.

  2. 2. Incremental migration between frameworks, with “strangler pattern.” If you can convert your existing app into a Micro-Frontend, you can start adding new micro-frontends without rewriting the old one. This lets you introduce the new framework without the cost of rewriting everything.

  3. 3. Ability to hire developers with a larger range of talents, since they can work in more technologies rather than living with the one set chosen for a monolith.

  4. 4. Ability to use the “best tool for the job.” Does that React library solve everything? Use it. Does that Vue library solve everything? Use it.

Cons:

  1. 1. Conceptual complexity. It takes a while to explain what’s going on to everyone.

  2. 2. Technical complexity. Separate CI processes, in-browser module loader, Module Federation, and so on.

  3. 3. Possibility for duplicated dependencies between micro-frontends, which is worse for performance than a single monolithic build. There are solutions to this, but they are often not implemented perfectly.

  4. 4. Deployment dependencies between micro-frontends are a new thing to consider that don’t exist if you have a single deployable.

Did you contribute to any OSS project related to micro-frontends? If so, which one?

Yes, single-spa and all its helper projects (single-spa-react, single-spa-vue, single-spa-angular, import-map-deployer, import-map-overrides, systemjs, etc.).

When would you suggest using micro-frontends and when we should avoid them?

Use micro-frontends when:

  • - You’re trying to migrate away from an old framework or monolith.

  • - You want independent deploys for separate dev teams.

  • - You want some level of independent technical decision-making for separate dev teams (which date formatting lib to install, which react css lib, or perhaps even which UI framework).

  • - You want to split your UI into highly cohesive, loosely coupled sections. This comes from the Building Microservices O’Reilly book.

Avoid micro-frontends when:

  • - You don’t want to do micro-frontends.

  • - Your monolith is working well for you.

  • - There is only one dev on the project.

  • - Separate deployments cause more pain than benefit, due to deployment dependencies. This occurs especially when you have very few developers.

  • - Your micro-frontends regularly engage in heavy, chatty communication. If the micro-frontends are talking to each other all the time, perhaps you should not be using micro-frontends.

  • - Your dev team does not have the technical expertise, time, or desire to manage a more complex system.

At the end of your last micro-frontends project, what worked and what didn’t?

What worked:

  • - We created a separately deployable project with its own package.json, build, and CI process. This was a huge win over our PHP/Laravel monolith that built react with an old version of node and gulp.

  • - We were able to free ourselves from many of the technical decisions of the past.

  • - We were able to create a style guide/component library that lets us collaborate with UX a lot easier.

What didn’t work:

  • - DevOps was very resistant and took a lot of convincing. The new CI pipelines and infrastructure took a long time to build.

  • - Some devs confuse micro-frontends with react. They were new to and couldn’t tell what things came from what.

What are the must-have tools for developers to have an efficient experience with micro-frontends?

  • - import-map-overrides: It allows you to develop one micro-frontend at a time, instead of running all of them locally.

  • - single-spa: The most popular open source framework for micro-frontends that I’m aware of.

  • - import-map-deployer: A clear way to achieve independent deployments for your separate projects.

  • - import maps: A separate name of the micro-frontend from its url. This is important for independent deploys.

  • - systemjs: For in-browser module and import maps polyfill support.

What would you suggest for a person who wants to embrace this architecture?

Look at your backend code’s architecture and evaluate whether it is working for you. It often makes sense for your backend and frontend architecture to match. If one is a monolith, the other should be. If one is microservices, the other should also be microservices.

Look at how your organization gets things done. If your organization’s culture is geared toward product ownership, team autonomy, and distributed decision-making, then micro-frontends might make sense. If it’s more of a centralized decision-making process, then it might not make sense.

What was the impact of introducing micro-frontends to developers who didn’t know about them? What challenges have you faced?

Where are the lines between micro-frontends and a UI framework? What is doing what? How do the pieces fit together? What does this repo (or that repo) do? What’s the mental model for the whole system?

What was the developer experience on your last project?

See https://github.com/joeldenning/import-map-overrides. You do `npm install` and `npm start`. Then you go to a deployed environment and set up an override so that it uses your local version of the micro-frontend instead of the deployed version.

Many developers are concerned about performance and design consistency with micro-frontends. What are your suggestions for overcoming these challenges?

For shared dependencies, see https://single-spa.js.org/docs/recommended-setup#shared-dependencies

For design consistency, create a shared style guide module and/or choose a design system such as bootstrap. See https://single-spa.js.org/docs/microfrontends-concept#types-of-microfrontends and https://github.com/react-microfrontends/shared-dependencies.

What are the first steps for working with micro-frontends?

  1. 1. Create a POC to help you decide whether you want to do it.

  2. 2. Convert your existing app to be a single micro-frontend. Release that to production.

  3. 3. Pull out shared navigation into its own micro-frontend. Release that to production.

  4. 4. Implement your next new feature as its own micro-frontend. Release that to production.

  5. 5. Pull out a small part of your monolithic app into its own micro-frontend. Release that to production.

Can you share the main thing to avoid when working with micro-frontends?

  • - Splitting them up too much or incorrectly, such that they’re all highly coupled

  • - Shared, single deployment for all your micro-frontends

What are the main challenges in embracing this architecture from your perspective?

  1. 1. Converting your existing code into a Micro-Frontend, so that future code can be split into separate micro-frontends.

  2. 2. Setting up CI/CD

  3. 3. Organizational buy-in, trust, and training

Would you like to share some useful resources about micro-frontends?

This YouTube playlist is great: https://www.youtube.com/playlist?list=PLLUD8RtHvsAOhtHnyGx57EYXoaNsxGrTU.

Micro-frontends in three words…

Microservices for frontends

Please introduce yourself.

Zack Jackson, principal engineer of lululemon.

I focus on distributed JavaScript application architecture and how to scale a company’s codebase, teams, and platforms. I’m passionately involved in open source! I created the first code-split SSR system for React, and I’m the creator of webpack 5’s flagship feature, Module Federation.

What is your experience with micro-frontends?

I have exclusively built micro-frontend stacks for companies since 2015. The largest stack I’ve built consisted of 150 separate micro-frontends. It consisted of a shared component library; feature-based components used the component library but most features were deployed independently as a micro-frontend. The range of what the micro-frontends were made of was pretty wide. Some were a single component, some were full features, and others were whole pages or user flows.

I designed the Starbucks inventory management platform, used by all its stores. This stack consisted of six separate micro-frontend applications with helper services for authentication.

At lululemon, I am building a powerful stack that leverages an AppShell and Module Federation and that enables drag-and-drop refactors as features or code that can be moved between servers with no need for regression or extra engineering time. I’ve extended Module Federation beyond managing seamless micro-frontend experiences, into analytics, A/B testing, and configuration management—all while remaining standalone and independently deployable at any time providing evergreen code to consumers.

What benefits and pitfalls did you encounter in your journey with micro-frontends?

One pitfall was poor code sharing. Sharing vendor code is manual and primitive, causing centralized dependency on an external set of vendors, and upgrading package versions is complex as breaking changes would require all micro-frontends to be prepared for the upgrade of a shared vendor.

Another was poor UX. When moving between micro-frontends, a page will reload. There are very few solutions to sharing global state or making micro-frontends work as well as a monolithic SPA. Huge amounts of time can go into improving the UX.

The benefits of micro-frontends outweigh the pitfalls at scale. Code can be deployed independently, builds are faster, regressions are easier to run, and the blast radius of a critical failure is well contained. It saves engineering time and company money, as features can be delivered at a fast rate, unlike in a monolith, where the rate of delivery slowly degrades as the codebase increases in size and complexity. Micro-frontends remove the harsh requirement of communication and coordination overhead between teams. They are also cheaper to run and scale because you can use cheaper, less-powerful servers. Unlike a monolith, you can scale per page or per component on cheaper hardware instead of scaling expensive and powerful hardware to meet the base demands and memory consumption of the entire monolith.

Micro-frontends are far more agile and they safeguard companies against site-wide critical failures. Redundancy layers can be built easier, and teams can model a platform to fit their needs instead of using a one-fits-all model that monolithic platforms enforce.

Did you contribute to any OSS project related to micro-frontends? If so, which one?

Next.js, webpack 5 Core, single-spa, React Static, and Module Federation extensions and enhancements.

When would you suggest using micro-frontends, and when we should avoid them?

Small companies will likely not benefit from the engineering overhead. Larger companies with challenges at scale or companies with multiple teams who rapidly deploy are likely best suited to benefit from distributed JavaScript applications.

Regardless of use case and scale, it’s very important to design your platform from the ground up to handle scale. If you foresee rapid scale in the future, designing a system that can be migrated into a distributed application model is key. You’ll save time and money by avoiding a full-scale rewrite.

At the end of your last micro-frontends project, what worked and what didn’t?

Automatic vendor sharing was challenging, routing between the separate apps and making that route transition seamless were a major challenge, and maintaining authentication sessions and sharing state were very challenging as well. My current micro-frontend project has been designed to avoid these issues by rethinking how applications interface with each other and are designed in general.

What are the must-have tools for developers to have an efficient experience with micro-frontends?

Webpack 5 Module Federation is a massive unlock, single-spa provides a strong orchestration layer, Next.js with a custom AppShell, and yarn workspaces that serve as sub-apps is a robust design pattern, which can enable scale and can integrate with Module Federation if or when needed. Micro is another fantastic tool for creating an ingress to route a user to the correct micro-frontend as well. Leveraging monorepos keeps code organized but will still have the pitfall of having only one master branch, bottlenecking deployments. Semantic-release is vital for micro-frontend architecture, where semver plays an important role in the scalability and reliable code distribution.

What would you suggest for a person who wants to embrace this architecture?

Give Module Federation a try. Most importantly, design a system that supports scale. Think about monorepos, feature binding, how bound a page or feature is to a specific server, and how hard it would be to split some of the app into another micro-frontend at a later point in time. Avoid hard binding to a server; build software that can be easily migrated to a new stack. Globals like shared state should encapsulate a page or feature, keeping it independent and unbound to the server. Moving a page or feature to another server instance should be built in a way that will provide any globals needed out the box, not involve multiple copy-pastes of various parts of the application. Gitlab CI is powerful and a strong contender for sophisticated infrastructure requirements.

What was the impact of introducing micro-frontends to developers who didn’t know about them? What challenges have you faced?

Development time and efficiency usually quadruples. Introducing the pattern has given development teams a better experience and the ability to move more code through the pipeline at a faster rate. Challenges revolved around performance concerns from SRE and getting developers used to working in more than one repo at the same time. In highly granular MFE stacks, it can be a learning curve to run multiple MFEs locally and to get used to having several IDEs open, depending on what feature is being developed.

What was the developer experience on your last project?

Kubernetes, custom router and auth layers, shared global packages, special script to boot and run all MFE’s in one place for full workflow use.

Many developers are concerned about performance and design consistency with micro-frontends. What are your suggestions for overcoming these challenges?

Webpack 5 Module Federation is the best solution to this problem. There are no performance concerns or design consistency issues. Code is shared at runtime; it’s evergreen.

A non-webpack-5 solution would be to use renovate bot and depend on abstraction for distribution or having the micro-frontends supply a render API to allow other applications to retrieve HTML and other resources over a network call. Ultimately, these are better ways to share feature and vendor code along with automation around upgrading dependencies.

What are the first steps for working with micro-frontends?

Figure out how it’s going to scale. Centralize shared code, utilities, and data calls. Make sure the platform layer does not become fragmented when managing several independent servers. Think about routing and how you will map various routes to their MFEs.

Can you share the main thing to avoid when working with micro-frontends?

Not abstracting core code to npm. Copy pasting server infrastructure, which leads to maintenance challenges and fragmentation at the platform level. Either an application shell or server shell should exist, which holds high-level aspects, like auth, user state, tooling, and translation configurations.

What are the main challenges in embracing this architecture from your perspective?

Avoiding UX degradation in favor of DX improvement, neither should be compromised. Thinking out how your MFE stack is going to look and work in one year’s time with over 10 stacks: does it architecturally scale?

Would you like to share some useful resources about micro-frontends?

https://medium.com/@ScriptedAlchemy/webpack-5-module-federation-a-game-changer-to-javascript-architecture-bcdd30e02669?source=friends_link&sk=c779636999c8644a7fc0df3aaa96223e

Micro-frontends in three words…

Cheap, flexible, scalable

Please introduce yourself.

My name is Erik Grijzen. I’m from The Netherlands, but currently living in Barcelona, Spain where I work for New Relic, a company that has an observability platform that gives its customers insights on how their systems and software are running in real time.

About three years ago, shortly after I joined the company, I’ve been working on a new project to build a completely new platform UI, using a micro-frontend architecture. As of today, I’m still working and evolving this project as a lead software engineer on the team and the technical product manager for the UI of the platform.

I’ve worked as a software engineer for many years in a variety of different companies throughout my career. My focus has always been more on the frontend side of things, which is what I’m most passionate about.

What is your experience with micro-frontends?

My experience with micro-frontends has been solely working on this new platform within New Relic over the last three years. Let me give you some context on how we ended up deciding to use this architecture because I think this is quite interesting and I believe many other companies find themselves in a similar position.

New Relic is a fast-growing company and in the last 10 years, it has built many different products. All these products were built separately as monolithic single-page applications that were linked together through one common navigation. This approach was very successful until more or less three years ago, when we discovered that we had several problems related to the consistency of our user experience, extensibility of our UI, and the way we did UI development within our company. Let me go over each one of these problems to explain them a bit more in depth.

Many of our customers were starting to have more and more complex systems because they were adapting to a microservices architecture and moving towards the cloud. As a result of this, our users were forced to switch constantly between our separate applications to troubleshoot problems in their systems. Despite all the best efforts of our UI engineers, our products were all working and looking slightly different (in some cases very different), which led to undesirable user experiences. On top of that, switching between applications also caused our users to lose the context of the issues that they were troubleshooting, which was an even bigger problem.

The landscape of technology (software, tools, programming languages, integrations, open-source, etc.) that our customers wanted to instrument and observe was (and still is) exploding. It’s almost impossible to keep up, so it was clear that we wanted a new approach where we could provide new functionality for our users in an easy and fast manner. Besides that, we also noticed that some customers had very specific use cases that only applied to them. To also cover these cases, we wanted to provide a way to make our user interfaces programmable so that they could extend the platform for their specific needs.

We also saw that inside our company, many UI engineers were doing a lot of duplicate efforts regarding project setup, tooling, configuration, etc. We wanted to reduce the toil and boilerplate that each team has to go through to build new features so that they could spend more time on building innovative and creative product solutions for our users.

It turned out that a micro-frontends architecture was a perfect fit for us to tackle these problems. Users are demanding more unified product experiences, but it’s not easy to build a product with hundreds of UI engineers at the same time, especially when they are located in different offices around the world and in different time zones. And in our case, allowing customers to build on top of the platform as well made the problem even more difficult. In the end, we decided that a micro-frontend architecture was how we wanted to scale our UI development within our organization.

What benefits and pitfalls did you encounter in your journey with micro-frontends?

In our experience, this architecture has very similar benefits and downsides that you can expect from using a microservices architecture on the backend. However, there are a few exceptions to this due to the nature of how browsers work.

Let’s start with the benefits. I believe the main topics that we should cover where we noticed the biggest differences are the following:

  • * Team autonomy

  • * Small and decoupled codebases

  • * Modeled around a business domain

  • * Automation and standardization

To scale the UI development inside our organization, the most important thing we wanted to achieve was for teams to work autonomously. They should be able to deploy new code whenever and as many times as they want without depending on any other team. Each team should be cross-functional, meaning they have every role (designer, frontend engineer, backend engineer, QA engineer, etc.) on the team to build the functionality they want, so that they can do a complete end-to-end implementation. This means they have full ownership and can take all the responsibility for one or more related micro-frontends that are part of a specific business domain. This is important because this allows parallel development without slowing down when more and more teams are working on our platform.

To achieve this autonomy from a technical point of view, the micro-frontends must be loosely coupled, so that they don’t depend on each other and whenever they interact they should have clear contracts. Each micro-frontend is also small in size so that they are easier to reason about (you don’t need to know the whole system), easier to test and you can easily add, change or remove them over time.

Our micro-frontends are modeled around a business domain or subdomain, because this aligns better with the structure of our business. It creates fewer team dependencies, gives teams more autonomy, and improves the communication to make quick decisions so that teams can iterate over features faster. To give a more concrete example, one team could be organized around the domain of NodeJS application monitoring. They are highly specialized and are subject matter experts on that topic, which typically results in higher-quality code and better solutions for our end users.

With our micro-frontend architecture setup, we moved from several monolithic single-page applications to many small micro-frontends that are composed at runtime into one unified platform. This resulted in an explosion of a lot of small codebases, which are each owned by separate teams. It was very important to be prepared for this because this architecture introduces a lot of repetitive work and duplication. That’s why it’s very important to have the proper infrastructure, tools, and standardization in place. We automated every step in the development process, from project creation and pipeline build to continuous integration and continuous deployment, basically providing everything that the team needs, so they can focus on building functionality that our users love.

Let’s move now to some of the pitfalls we encountered using micro-frontends. In our journey the two hardest parts were:

  • * UX consistency

  • * Performance

Every architecture comes with tradeoffs. I don’t think we have a perfect solution to make the UI always consistent and performant, but we try to mitigate the downsides as much as we can. In most cases, this means putting certain constraints in place and reducing the autonomy of teams. For example, we have a constraint in place that every team should use a specific version of the ReactJS library to build their user interfaces. This obviously limits the teams from using any technology they want, but we think it’s worth it because this constraint reduces the performance costs a lot for our users. We don’t want to limit innovation in the organization, but when we try out new technologies and we carefully evaluate the impact it has on the system, we then update the organization standards and move this innovation to the platform level, so that everyone can benefit from it.

When you have many teams working on the same platform, the consistency of the UI is at risk. To reduce this downside as much as possible, we think it’s critical to at least have a design system in place. This won’t magically make everything consistent, but I think without it, you will definitely be in a world of trouble. In our experience, this design system is best owned and maintained by one team. This doesn’t mean others cannot contribute, but there’s one team making sure it aligns with the bigger picture. We’ve tried an open source model where everyone could contribute to the design system, but this didn’t work out for us, because when everyone is responsible for it, nobody is responsible for it. Maintenance work, bug fixes, and keeping everything aligned with the bigger picture are especially hard to do in this setup. To further improve consistency, we also implemented an SDK that all micro-frontends have access to. This SDK has all the UI components from our design system and provides several APIs to standardize certain patterns such as navigating around the platform.

To make sure our platform stays as performant as possible, we have several things in place. First of all, the platform is built with the application shell model which makes it very minimal and fast loading to achieve a good initial perceived performance for the users. When the platform is loaded, we lazy-load the micro-frontends based on the client-side routing, which allows us to only load the minimal JavaScript and CSS necessary to render the screen. To reduce the payload size of the assets we load and memory consumption of the application, we think it’s necessary to deduplicate the frontend dependencies as much as possible. On the platform level, we provide some dependencies (i.e., ReactJS) that we are sure every micro-frontend is going to need. We do that by defining those dependencies as webpack externals so that these don’t get bundled up for each micro-frontend. This alone reduces the bundle sizes by an incredible amount. For each repository that contains micro-frontends, we are code-splitting the bundles so that we can lazy-load them incrementally at runtime inside the platform. The last thing we do is provide the before mentioned SDK on the platform level by injecting it in each micro-frontend. This reduces the need to use other NPM dependencies, which should decrease bundle sizes even more.

Did you contribute to any OSS project related to micro-frontends? If so, which one?

No, I’m not contributing to any open source projects at the moment. I looked into several of the bigger micro-frontend frameworks and libraries a while back, but none of them really matched with how we wanted this architecture to look like for our platform.

I’ve been asked several times if we will open source what we’ve built at New Relic. Unfortunately, we don’t have any plans to do so. I also think that what we have right now is too tailored for our needs and we would have to change it quite a bit before it would make sense to release it to the public.

When would you suggest using micro-frontends, and when we should avoid them?

Using an architecture like this comes with a lot of tradeoffs that have to be evaluated carefully and need to make sense for your project and company. Typically the benefits outweigh the downsides when you need to scale your UI development to a lot of teams, which normally only happens for mid-sized to large companies. So my recommendation is to not use this architecture for small projects or companies. If you’re not sure you need micro-frontends, you most likely don’t need them. Just start simple; you can always slowly migrate to micro-frontends over time when there’s a need for them.

At the end of your last micro-frontends project, what worked and what didn’t?

I never officially completed a project using micro-frontends. We are continuing to evolve the architecture of the platform as the product and organization change over time. I consider it nearly impossible to get the architecture right from the start, so you are guaranteed to encounter things that are not working as you might expect. Our current architecture is very different than the one we started with three years ago.

What really worked well for us, was to set up some ways to regularly communicate and get feedback from other teams. This was very crucial in adjusting over time and refining the balance on several architectural topics. I think we have been too restrictive in some areas and we had to put some more restrictions in other places to get the results that we wanted. We try to keep a close eye on what’s not working for us and adjust over time to improve the situation.

What are the must-have tools for developers to have an efficient experience with micro-frontends?

This depends on a lot of things because there are many ways you could implement micro-frontends based on the requirements of the project, its business requirements, and how your company is organized. But generally speaking, you want to make it as easy as possible for teams to be successful, whatever that implies in your context.

At New Relic, we’ve built a command-line interface that uses our internal infrastructure and tools to give teams everything they need to develop features fast. Almost everything you can think of is automated, from project creation to the final deployment to production. We are in a very competitive market, so for us, it’s vital to have a fast time to market, be able to quickly iterate on features based on the feedback from the user and spend as little time as possible on technical configuration, setup, and other repetitive boilerplate.

What would you suggest for a person who wants to embrace this architecture?

Micro-frontends are not a silver bullet. Just like with any architecture, there are many tradeoffs to be made. You have to find the right balance between those tradeoffs that works best for your project, company culture, and organization. What typically happens is that you go from one or several big codebases to many small codebases. That’s why I think it’s important as a company to make sure you first have the necessary infrastructure, tooling, and standardization in place to support this architecture before you make the change.

What was the impact of introducing micro-frontends to developers who didn’t know about them? What challenges have you faced?

I think people don’t talk about this a lot, but introducing micro-frontends can be quite a cultural and organizational change that requires kind of a shift in the way you work. This might come as a surprise sometimes to developers who never worked with such an architecture. For us, this was a change that happened slowly over time, so as more and more teams onboarded to work on top of the new platform, the company and the people slowly transitioned to this new way of working.

Especially for the teams that were building micro-frontends on top of the platform in the early stages, it was not always easy. They didn’t always have everything they needed and there were still dependencies and things that were blocking them from completing their work. This has improved a lot over time, with better communication, documentation, resources, and better tooling in place to support developers from day one.

What was the developer experience on your last project?

To build micro-frontends on top of our platform, you have to use a command-line interface. Both our customers and internal teams can use this to extend the platform with all different kinds of micro-frontends. This CLI automatically takes care of the project setup, pipeline build, continuous integration, and continuous delivery. This allows for very rapid feature development; you can go from idea to production within hours.

When you create a new project it automatically scaffolds the repository with all the required dependencies, structure, configuration, version control, and integration with internal tools. By default there are many NPM scripts configured to take care of typical developer experience, such as local development, linting, prettifying, bundling, testing, and other automated tasks to make sure that what you build will work within the platform. When you do pull requests we automatically generate URLs to test the changes against the platform, which makes code review much smoother. Finally, when a pull request gets merged we automatically create a release for our continuous delivery system, which makes it easy to deploy a specific version to any environment, do rollbacks, and so forth.

Many developers are concerned about performance and design consistency with micro-frontends. What are your suggestions for overcoming these challenges?

I’ve already explained how we are trying to tackle these two challenges. Like I mentioned before, we don’t have a perfect solution, but we try to reduce the downsides as much as we possibly can in the context of how we implement micro-frontends in New Relic.

My suggestion would be to carefully evaluate the importance of these topics; based on that you can define the appropriate constraints on the autonomy of the teams that are building micro-frontends. The more constraints you put in place, the more you can reduce the downsides. You will probably end up with a middle-ground solution that is best suited for your project and organization.

What are the first steps for working with micro-frontends?

It’s hard to give specific recommendations on how to start working with micro-frontends because this depends so much on the type of project, culture, organization, and the size of the company. The way we have organized, set up, and architectured our UI development with micro-frontends might be a complete disaster for another company.

Some general recommendations when you get started:

  • * Make sure you find the right balance of trade offs that work for you.

  • * Make sure to communicate and get feedback, so you can adjust architectural decisions to overcome challenges.

  • * Make sure you have enough infrastructure, tooling, and standardization in place that supports this architecture.

Can you share the main thing to avoid when working with micro-frontends?

The main goal of micro-frontends is to scale the UI development within the organization. So the main thing to avoid is creating dependencies between teams or blocking the development of teams in any way.

What are the main challenges in embracing this architecture from your perspective?

I think the main challenge is to tackle some difficult tradeoff decisions, where you are forced to choose between the autonomy of teams and the user experience of the end users. This is not always easy, but I think with time you will always find a good middle ground for each of these tradeoffs.

Would you like to share some useful resources about micro-frontends?

If you are reading this, you already have the best resource at hand. I would also recommend the talks that you can find on YouTube from Luca, especially for people that are new to micro-frontends.

Micro-frontends in three words...

Scaling UI development

Please introduce yourself.

David Leitner is co-founder of SQUER Solutions, a Viennese software company, and describes himself as an enthusiastic software professional who works on various projects using a bunch of different stacks and environments. He spends much of his time on the frontlines tackling the challenges of scaling software and complex domains. A software engineer with more than 10 years’ experience, David prefers his code simple and small instead of clever and edgy. David enjoys sharing his knowledge as speaker at conferences, as a podcast co-host, and as a lecturer for his post-diploma courses at the University of Applied Sciences Technikum Vienna.

In 2016 David was one of the first who dealt with the topic of micro-frontends intensively and proposed his ideas to international conferences.

What is your experience with micro-frontends?

When consulting with our customers, we always stress that microservices are about end-to-end verticals that enable independent deployments of autonomous parts of an application at a high pace. Following this idea, it was clear from the very beginning that we had to somehow make this possibility on the frontend parts of these architectures, as well. We experimented in a dozen of projects with different approaches, including simple ones, like linked applications, but also more sophisticated ideas, like the integration on the client side with web components.

What benefits and pitfalls did you encounter in your journey with micro-frontends?

One big lesson was the impact on the look and feel of huge frontend applications. Thus, a Micro-Frontend architecture must go hand-in-hand with a strong understanding and maturity in design systems. In addition, you also have to deal with the classical issues of distributed systems, like performance and latency. For example, over the years we discovered that a shared caching layer on the frontend is a good idea; it was a game changer for how we designed our micro-frontend architectures. And last but not least, it’s nearly always a wise decision to start with a monolith-first approach.

Did you contribute to any OSS project related to micro-frontends? If so, which one?

Unfortunately, I have not actively contributed to one of them so far, mainly because we almost never use off-the-shelf frameworks for our micro-frontend architectures. We try to keep the dependencies small and stuck to basic web standards, like web components, to build micro-frontends.

When would you suggest using micro-frontends, and when we should avoid them?

It’s really hard to answer this question without any further context, but, I think it is important that as with every new architecture or technology, micro-frontends should not be an end in itself. Still, in our experience at SQUER Solutions, it shows its benefits mainly when the team size gets too big to work on one codebase in the frontend, when resilience issues start to erase, or when the time to market is below expectations.

At the end of your last micro-frontends project, what worked and what didn’t?

I think we started to have the maturity that allowed us to spot the right points where the frontend should be split up. But especially for client-side integration, it’s a daily challenge to let the integration module of your micro-frontend architecture not sprawl too big and become a bottleneck.

What are the must-have tools for developers to have an efficient experience with micro-frontends?

In most cases the concept of monorepo makes a lot of sense: a single repo for all the micro-frontend projects, especially to share and ensure consistency for commonly used UI components. Besides this, each module that is used inside the micro-frontend architecture should, of course, strictly follow semantic versioning, and the team should have a common understanding about breaking changes.

What would you suggest for a person who wants to embrace this architecture?

As mentioned before, start with a monolith-first approach. Only start to use micro-frontends once you understand the domain well enough to split them up reasonably.

What was the impact of introducing micro-frontends to developers who didn’t know about them? Which challenges have you faced?

I have seen similarities to the introduction of micro services a few years ago, which makes total sense, as in both cases distributed architectures are introduced. The new challenges are therefore to design micro-frontends to be backward compatible and to enforce asynchronous communication over synchronous one.

What was the developer experience on your last project?

I think a solid CI/CD pipeline is essential. In a micro-fronted architecture, most of the complexity moves from a developer’s machine to the build-and-deployment process. Thus, a feature in such an architecture is delivered once it’s deployed to production, not once it’s committed to the version-control system. All the tooling should support and align with this thinking.

Many developers are concerned about performance and design consistency with micro-frontends. What are your suggestions for overcoming these challenges?

Basically, it can be said that these concerns are absolutely justified. The question should be whether other advantages of micro-frontends outweigh these problems for a specific use case. My rule of thumb for performance is the more we strive for performance in a micro-frontend architecture, the more we must move the integration to the client. For design consistency, a mature design system can usually overcome most of the challenges.

What are the first steps for working with micro-frontends?

Don’t be too opinionated, search for diverse resources that will help you make decisions. In addition, conference talks are a good source for practitioners’ reports and learning from the mistakes others have already made.

Would you like to share some useful resources about micro-frontends?

As mentioned before, I usually like to listen and learn from the experiences of others; conference videos on YouTube are a good way to get those insights. In addition, the micro-frontend introduction on Martin Fowler’s blog is a good jump start to this topic. Well, and of course the book you are holding in your hands!

Micro-frontends in three words…

Go for it!

Please introduce yourself.

My name is Philipp Pracht. I work as an architect and product owner at SAP, located in Munich, and I’m a proud father and husband.

What is your experience with micro-frontends?

I’m currently working on project Luigi (luigi-project.io), a technology-agnostic micro-frontend framework for admin and business UIs. Before that, I was working on the user interface part of YaaS (a microservice-centric platform and commerce-as-a-service solution), where we successfully established a micro-frontend architecture back in 2014, before the term “micro-frontends” even existed.

What benefits and pitfalls did you encounter in your journey with micro-frontends?

The main benefit is the efficiency boost for any large-scale UI development landscape with multiple teams. In my previous project, I was part of the team responsible for the UI. There were more than 20 teams developing microservices. After we established a micro-frontend architecture (again, it wasn’t called that back then) and asked the service teams to take ownership of their UI parts, I was extremely impressed and surprised by how well it worked out. After a short technical introduction, all teams were able to develop and release completely independently, and we never heard back from most of them. It just worked.

The main pitfalls were not on a technical level but rather with some people who did not really stick to the philosophy of micro-frontends, or even of independent, self-empowered teams in general. Sometimes this led to long-lasting and unproductive discussions.

Did you contribute to any OSS project related to micro-frontends? If so, which one?

Apart from Luigi, which is open source, I contributed to Kyma (kyma-project.io), a platform based on Kubernetes for extending applications with serverless functions and microservices. Luigi started out as a Kyma side project, with the goal of extracting the micro-frontend architecture of Kyma’s admin console into a framework so that it can be reused in other applications. Of course, Kyma is now using Luigi.

When would you suggest using micro-frontends, and when we should avoid them?

In general, there is a correlation between the (predicted) functional scope and the benefits of using a micro-frontend architecture. If you are certain your UI will have a fixed set of UI components and will be developed by only one team, then you should go with a conventional approach. For all other scenarios, you should check if there is a micro-frontend framework out there that can help you. Even small projects can benefit from something like Luigi, as it offers some extra features that go beyond a pure micro-frontend framework.

At the end of your last micro-frontends project, what worked and what didn’t?

On a technical level, everything worked and there were no major issues.

What are the must-have tools for developers to have an efficient experience with micro-frontends?

Tools for reliable development and testing environments are key. Developers should feel confident at all times that what they are currently implementing will work in the bigger context. For example, in my previous project we offered a CLI tool with which developers could run an emulated main application with their micro-frontend included.

An excellent IDE is also a must.

What would you suggest for a person who wants to embrace this architecture?

As with any hype, read about the topic first, then lean back and think about it from different angles. Think about the possible impact for people in different roles and try to come to a good understanding of where micro-frontends would be a good fit—not only from a technical point of view but also when it comes to organization structures and people.

What was the impact of introducing micro-frontends to developers who didn’t know about them? What challenges have you faced?

From my experience with introducing Luigi, developers were happy with it in general. probably because Luigi helps where help is needed but doesn’t impose anything—developers still had full freedom within their boundaries. In my previous project, though, there were situations where developers had problems focusing only on their part.

What was the developer experience on your last project?

In project Luigi, we created a tool called Luigi Fiddle (fiddle.luigi-project.io), a playground where you could try out most of our core functionality. It turned out to be pretty helpful, especially for onboarding new developers.

Many developers are concerned about performance and design consistency with micro-frontends. What are your suggestions for overcoming these challenges?

This depends heavily on the approach you choose, especially the performance topic. For example, Luigi has various mechanisms (like the “viewgroups” concept, caching, preloading) to mitigate performance issues for the end user. With concerns about design consistency, I was a bit surprised when I found out people consider this an issue. I usually ask them how they ensure design consistency in an app that doesn’t use micro-frontends, and the answer is something like “This is not a problem, because we have the same CSS.” Eventually most of them realize that you can also share CSSs across different applications. You could also develop Angular components that are not consistent with the rest of the app, so it is the developer who ensures consistency, because he wants his piece of UI looking good in its context.

What are the first steps for working with micro-frontends?

Think about how you want to subdivide your UI, then have a look at Luca Mezzalira’s micro-frontends decision framework.

Also, check if there is already a framework out there that fits your requirements.

Can you share the main thing to avoid when working with micro-frontends?

Avoid introducing a monolithic layer somewhere else in your stack, because you lose most of the benefits from micro-frontends. Micro-frontends work best with micro services.

From your perspective, what are the main challenges in embracing this architecture?

The main challenge would be if your organization structure isn’t a good fit. Your management has to set up a structure where dedicated units (a single dev team in the easiest case) can independently deliver end-to-end features.

Would you like to share some useful resources about micro-frontends?

All publications from Luca Mezzalira, of course.

There is also a good explanation of micro-frontends on martinfowler.com. And of course you can look at luigi-project.io and our YouTube channel, where you can find luigi-specific content, as well as some general information about micro-frontends.

Micro-frontends in three words…

Divide and conquer!

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.94.99.173