"Micro Frontends" is the new buzzword in the Frontend world, but too many times people use it in the wrong context or with different things in mind.
Micro Frontends can refer to different kinds of solutions that solve different types of problems - starting from using different UI frameworks on the same app or letting different teams work on separate parts of the code independently.
In this session, we'll go over the different problems we have when building a big app and how different micro-frontends solutions can help with this.
One possible solution- Fast forward months/ years: everyone frustrated, starting from scratch is inevitable.
You start with a small app, it’s all nice The product is getting bigger and the single team working on the project is starting to form some structure and patterns The project gets even bigger, the single team that was responsible can’t keep up with the pace of change Code getting bigger exponentially, complexity is too big to manage, code is duplicated all around the place and developers velocity and happiness is low
One of the engineers come up with an amazing idea (usually someone with a server side background): micro-services for front-end! =0
The code is running on the client side, so all the frameworks overhead counts. The user should feel this is a single app The heavy lifting that you do on the server side can’t happen in the client side. Bundle size is an issue, so you want to “reuse” libraries between services, while keeping those isolated There’s no standard API to communicate between apps in the client side.
There are actually a few, but each aims to solve different problems. Thus- before we pick one we need to understand what we want to solve and what are the prerequisites
Do we know that all teams will use the same framework (and same version)? Do we want single deploy for all the app or independent deploy for each module? Do we want to be framework agnostic? Do we want to have modules that can be shared between different apps? Do we want to turn on and off modules? Should it be dynamic? Do we need to support SSR? Automatic tools (flow, CI, testing infra, redux patterns, utils, global apis) VS. Freedom (teams moving at their own speed, choosing their libraries, choosing their stacks, etc)
“Micro Frontends”- You Keep Using That Word, I Don’t Think It Means What You Think It Means
You Keep Using That Word, I
Don’t Think It Means What You
Think It Means.
Shem Magnezi | @shemag8
Once upon a time in
WeWork, community managers
needed a managing tool
Questions you want to ask
● Do all teams work on same framework (and
● Single deploy or independent deploy for each
● Modules should be shared between apps?
● Modules should be loaded dynamically?
● Do we need to support SSR?