3 Ways Micro Frontends Could Improve Your Life (, Dev Velocity, and Product).
During the last 18 months I have had the opportunity to work in a team responsible for Wix’s backoffice platform, which is built with the Micro Frontends architecture. This concept was totally new to me and pretty much rocked my (technical) world. I’ll try and explain what problems this helped us to overcome and how it could be beneficial to you.
Wait, What’s Micro-Frontends?
Cam Jackson defined it very well:
“An architectural style where independently deliverable frontend applications are composed into a greater whole”.
This means that instead of having one big application, we can break our product into independent small (or micro) apps that are decoupled from each other.
Those apps would load and unload by the micro-frontends platform. For example — a navigation bar on the top of the page that renders an iframe for each of those micro-apps (for simplicity’s sake let’s assume each micro-frontend is a page):
1 — Split the Codebase to Increase Dev-Velocity
The most naive frontend product would consist of a single javascript bundle, which we’d embed in the base HTML file which is served. That’s cool if we are a small team of developers, but once we grow, and form some more teams with different responsibilities, it would be a lot easier to make each team’s work independent of the other teams.
By applying the micro-frontends architecture, each page is maintained in a different codebase, by (at most!) one team. This greatly increases the velocity of development — no more build failures due to other teams’ mess or code-conflicts due to lack of sync between teams.
2 — Serve the Code Separately to enhance Performance
Splitting your codebase also means you have better control on how the code is sent to the client. You could have each page load on demand using lazy-loading (e.g., React Lazy Component). You can also prefetch a few pages, providing that circumstances allow it, e.g.:
<link rel=”prefetch” href=”my-page”>
`rel=”prefetch”` on link tags is now supported on all modern browsers and allows you to prefetch the rest of the pages while the user is already browsing the current page.
3 — Ship Pages Independently to Reach Users Faster
Giving each team an AtoZ responsibility on their product, allows them to control its shipping process independently. Lets review the naive iframe example from the first paragraph. If each iframe loads an independent page then each team’s shipping process doesn’t depend on others’.
This allows one team to be ready for production environment at blazing speed, without being dependent on other teams’ build, tests, deployment etc.
More than 50 Apps in Production!
One of the greatest challenges we had to overcome here at Wix, is merging a lot of independant product pages into a single product, without harming the development velocity which was already pretty high. Wix’s organizational structure consisted of a lot of small — product-dedicated teams to begin with, so moving to a micro-frontends based architecture only seemed natural.
Over the last few years we have developed and grown our micro-frontends platform to host more than 50 apps. Each of them is deployed several times a day independent of the platform, and any other app.
Interested? In my next post I’ll elaborate on other, more advanced ways to implement micro-frontends.
