Micro-frontend Architecture: Replacing a Monolith from the Inside Out

How to modernize a legacy application with micro-frontend technology.

This article is part of a series on micro-frontend applications and techniques for managing them.

Read the next one here

We are making some big changes to frontend architecture. Check out our progress on Webpack Module Federation:

Webpack 5: Module Federation. A Game-changer to Javascript architecture. Unlocking micro-frontends

Merge Proposal: Module federation and code sharing between bundles. Many builds act as one · Issue…

This tutorial will discuss how to decouple your frontend from a monolith and begin migrating to micro frontend architecture immediately. This was one of my past projects

The Problem

Let us assume there’s a Monolithic codebase. This monolith uses one of the backend templating engines or systems (ex. EJS or ERB), jQuery, and it has no real considerations for frontend — or worse, it comes from a time before SPAs existed. Maybe it has some asset pipeline like Ruby on Rails does. In that case, you might have backend variables inside javascript files — like .js.erb files, or AEM Fragments. A coupled, spaghetti codebase that feels next to impossible to modernize.

You want to stop writing frontend code inside this monolith and move to a more JavaScript oriented ecosystem, but how?

Most companies cannot afford (or will not accept) the engineering downtime of a “tools down” rewrite. Features need to progress under active development. Those features are undoubtedly getting harder to release at the same speed.

The monolith needs should be broken down into smaller pieces in a progressive, transitional way. It cannot interrupt business.

However, decoupling a monolith can be tricky, primarily when new API’s to support a JavaScript…