UI microservices — an anti-pattern?

Chris Kitson
Jan 11 · 3 min read

Take the microservices paradigm and try to plug It into modern UI SPA frameworks and you’ve got yourself a bit of an anti-pattern, right?

I’ve spent the last few weeks trying to bring microservices thinking to the UI, here’s some of my experiences.

What problem are you trying to solve?

Conceptually think of a single UI with a navigation element which can serve multiple components which enables users to interact with different functions of a business.

Monolithic UI — pulling together multiple application components at build time

OK — so can’t you just package up the components individually in your JS framework of choice, and then import them into your project using NPM/Yarn — done, right?

Let me take you further… what if each component was managed by a different application team and each wanted to control what and when they released. In other words, each application team delivering a component wants to be in control of their own build and release process and be completely decoupled from the parent UI container application.

Now we have our problem… Traditionally SPA frameworks (angular/react) at build time, bring lots of little components together and produce a monolithic build.

Let’s try and de-couple the functionality so lots of applications can be brought together and live in a single UI container but be managed by different teams.

Multiple UI components (interacting with lots of little microservices) orchestrated into a single UI container

What technologies are available?

There are probably several approaches to this, but I want to rule out iFrames as an obvious choice straight off, as they are likely to cause us more problems that solve including performance, stability and debugging.

There are a few JS frameworks out there which attempt to do what we described, one of the better ones I found was single-spa. They claim to support all major JS frameworks and even allow them to co-exist on the page together. Pretty cool!

Another choice would be web components which provide a standard model for encapsulation and interoperability of individual HTML elements.

Web components were introduced as a standard back in 2011 but uptake has been slow due to browser support, and framework loyalty by developers. Given it’s a proposed native standard and browser support is improving (reducing the need for pollyfills) and the fact angular are now on-board with angular elements it seems like a good choice to enable us to reach the Holy Grail of co-existing applications in a single UI container.

What are the next steps?

As the proof is often in the pudding, I am going to pull together a couple of proof of concepts…. one using single-spa and the other using web components. I will evaluate both technologies as we work towards a viable production ready solution.


I have since created a follow-on post to this one:

Thank you for taking the time to read my article.

Useful links:

Chris Kitson

Written by

UI Engineer

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade