Micro Frontends are currently (as of October 2019) listed under, and quite recently moved to, the Adopt status of Tech Radar.

As with all “new” techniques, there is quite the hype, the web is overflowing with articles and tutorials. However, for us having worked in the industry for quite some time now, we start seeing patterns of re-packaging old concepts into new packaging and labels and giving them a new flashy name.

So what technique is this really, and why has it become so popular right now?

Micro frontends as the concept is described

From micro-frontends.org:

The term Micro Frontends first came up in ThoughtWorks Technology Radar at the end of 2016. It extends the concepts of micro services to the frontend world.

/…/

The idea behind Micro Frontends is to think about a website or web app as a composition of features which are owned by independent teams. Each team has a distinct area of business or mission it cares about and specialises in. A team is cross functional and develops its features end-to-end, from database to user interface.

From martinfowler.com:

In particular, we’re seeing patterns emerge for decomposing frontend monoliths into smaller, simpler chunks that can be developed, tested and deployed independently, while still appearing to customers as a single cohesive product. We call this technique micro frontends, which we define as:

“An architectural style where independently deliverable frontend applications are composed into a greater whole“

/…/

For this to work, our teams* need to be formed around vertical slices of business functionality, rather than around technical capabilities

* the teams need to be split this way, and therefore the micro frontends need to be split this way

Nothing to argue about there. Makes sense, sounds like a great way to develop and deliver your frontend.

Micro services, as the concept is described

Now, look at this statement about micro services, from martinfowler.com, published five years earlier:

The microservice approach to division is different, splitting up into services organized around business capability. Such services take a broad-stack implementation of software for that business area, including user-interface, persistant storage, and any external collaborations.

Ok, so it is stated that micro services be split by business capability, and that the user-interface is also included in this split, and is really included in/belonging to the particular micro service, which is responsible for a specific business capability.

Now, what was stated about micro frontends? That they are a composition of features, with distinct area of business, and also that they are formed around vertical slices of business functionality. What is basically a synonym for area of business / vertical slice of business functionality?

Well, business capability of course. Meaning that micro frontends are sliced on the exact same criteria as micro services.

Oh, but wait, weren’t micro services supposed to include also the user-interface a.k.a the frontend? Well yes.

So doesn’t this all mean that the “new” hyped concept of micro frontends really is the part you should already have done if you are doing micro services? Well yes it is!

The difference here being only that the micro frontend concept only states how you should work with the frontend development, while the micro services really are the full stack of layers from frontend all the way down to the database.

In the next blog post I will elaborate a little on why micro frontends have blown up i popularity and hype right now, although it is something you already should be practicing if you say you are doing micro services.