Many of you might ask: why bother with microfrontends? This is totally new architectural approach and perhaps its benefits could be replaced with just proper front-end components codebase. Still, “microfrontend” is rather new term that hasn't yet established its position in the world of frontend development.

So as you might assume there isn't really a lot of articles, helpers, standards and tools, yet, those who work in webdev for a long time really get the idea just when they hear it. In short: Microfrontend is a webapp architecture design where front-end is decomposed into individual, semi-independent “frontend microservices” whose communication is kept on a minimum level.

Enough theory, here's the real deal we had to handle.

The myWorld frontend team has a lot of work to do and lately with new business needs arising they had to share some of their tasks with external teams- including ours. We were asked to create interactive map with filters and user interactions. Ideally, map should be deployed as some kind of external component, because there are several places on different websites where map shall be embedded. And questions immediately arose:

Well, Iframe comes to mind as a quickest solution. We can prepare independent app with one of our favourite frameworks like react or vue and just embed it wherever. We don't have to worry about current myworld codebase and deployment process. Yet, on the second glance there's something wrong with this approach. So, what really bothers me here:

—   Possible display problems on mobile devices
—   No direct possibility to inherit styles without hacks
—   Clunky way of passing parameters within url's GET attribute
—   Problems with direct communication with parent wrapper
—   Possible problems with warnings and errors reporting (to user and error log service)
—   Unexpected unwanted scroll situations
—   Modal windows will look ridiculous
—   Accesibility concerns
—   Any other iframe issues you may think of

We didn't want to go with direct framework embed, because, although it solves some of iframe issues, in the mean time creates new ones. For example: conflicts with other libraries, dependency chain, global scope pollution, multiple framework versions for different features, bundle size.

To avoid listed issues we could go with super clean, pure javascript approach, it would be trully safe solution, implementation should be as easy, as:

So there is no conflict whatsoever, but also: no help from our favourite tools which is just painful. Rendering methods and DOM helpers would have to be written from ground up, native events handling and all that fun with re-registration when DOM changes, only low level nodes creation available, so lot's of abstraction to do, custom implementation of change detection- in short, reinventing the wheel.

Our subject from the very start was intended to be used on several websites, which slightly differ in style and perhaps in language. Maybe even different points on the map should be focused, so we have to find a proper way to initiate our component with different starting attributes. And again, passing json config to our constructor smells the best and seemed to be the way we are heading to.

Ok, so at this point we agreed we want some sort of WebComponent even if we directly didn't named it that way. And yay! Both vue and react allow us to wrap whole app inside custom web elements that separates framework itself from any further conflicts and also wraps styles to cut the cascade to the given namespace. Last little issue is bundle size. For sure additional 100-150kb for every component is not a big deal, but it's unnecessary and often redundant. If we only could...

And here comes preact all in white. It's just like react we all love, but it comes with tiny footprint (20kb with babel and webpack) and supports containerization out of the box with official template.

Just a tiny addition to preact config file and we're at home:

What we did here is a simple versioning system. This way we can bundle new version with new features and don't worry about previous implementations' incompatibilities. Everyone can upgrade just when they need to. Our preact template allow us to build as a npm module as well as a umd script, this way we can easily allow other teams to implement our micro frontend with such piece of code:

Cascading nature of styles stands in a little opposition to code encapsulation and separation of concerns. There are two issues on the horizon. First: we need to be assured that our styles won't flood anywhere else on the parent container. Second: We have to allow somehow for slight external changes.

First things first- to prevent our styles from flooding outside we are going to use CSS modules. This way we are able to write styles just like they were normal css, but the output generated by webpack will limit styles to local scope by using random names. This solution is not as good as shadow dom separation, but is surely sufficent.

To allow external containers for slight style overwrites we will introduce special classnames for every important piece of markup so it will be easier to inline our micro frontend with parent app.

There is also few things to remember:

—   Always inherit fonts
—   Provide light and dark theme
—   Use transparent background whereever possible
—   Do not add any margins and paddings to outer container
—   Use relative rem & em for sizing

This is a bit tricky, as there might be situations where user will have to authenticate before he might see some data. Right now, as a company, we are working on new SSO implementation, so hopefully all we will have to do in future will be simply passing token down to every microfrontend implementation.

Still, right now we decided- because of versioning- that every microfrontend has its own backend that is versioned internally as well. This way we also cut down possibilities of inproper backend implementations that might cause unexpected errors. This also makes testing and maintaining lots easier.

Next step for us will be server-side rendering, as right now this module doesn't require any seo, but surely we have to handle this somehow. Probably every microfrontend will have express service next to it that will be able to just simply render it's content to html.

Also, our eyes are directed towards Module Federation and Single Spa as a meta framework.

There's of course lots more things to consider, like shared components library, shared ui communication and behaviour, assets management.

Still, this is our first approach to handle microfrontends architecture and check how it behaves and fits to our company model.