Hyston blog
About • RSS

Micro frontend

2023-02-12 21:02

Currently on my main job we started working on new big project with three separate teams. And even we decided from the beginning to split backend parts, it took some time to discuss how we are going to work together on frontend part. Someone suggested to use microfrontends and it was a brilliant idea, except just one detail.
No one from us knows, what it is mean.
I would tell upfront, that I still don’t know what is it, but I have seen (and tried) some frameworks, that could be used for that.


This is not a framework, but more like set of tools to setup web components repository.

A component is a reusable, independently source-controlled module, that is stored in scopes and maintained in workspaces

It really reminded me of using git. Developer set up bit workspace (init or clone git repository), created new component, snapped (git committed) changes and them exported or imported (push/pull) into external scope (git repository).
Component can be anything, from smallest tag to complete web application. Good thing is that components could use different web frameworks and the in master application they can be all used together. Actually, there is no master application in this case - any application can connect to scope and reuse its components. This is a very nice way for code reusal and horizontal splitting , but not the one that we needed.


This library provide some components, that can be shared among micro front-ends. Typically, those components are navigation bar, authorisation, user settings and some context switchers. All micro frontends are just separate applications and “main” application contain Luigi-core framework that just show iframes with each micro frontend. Very good for vertical splitting, when all micro frontends doesn’t share any internal components, but still should be accessible on one page. Everything is configurable from just one json file. Besides core, there is also client library, that each sub-application can include and use it to communicate with master app and other frontends.


At the end of our meeting nearly half of developers can pronounce name of this framework almost correctly. This is very similar to previous option, but even simpler: there is no setup for navigation bar or anything else. Just a master application, that contain links to other apps and display iframe into them. Other apps loaded as bundles and only on first open (unlike Luigi, where it needs to be properly configured). This is very simple and extremely easy to use (I’m saying that because I haven’t tried it yet by myself 😋). There are hooks to interact between applications and they can take arguments from parent app on mounting. Best of it - all sub applications can be used separately and then this “master” app with Qiankun added later in development process.

Not sure is any of this can be considered as proper micro-frontend. Of course, it would be nice and fancy to use something shiny like bit.dev, but I guess, benefits from this would only appear once developers amount would be much more than we have currently and once components can be really reused between apps. This way new micro-frontend would be build togegher like a lego from different bricks. But by now I see quantum or Luigi as simple, robust and reliable solution for teams that doesn’t want to share codebase.

Next entry → ← Prev entry