"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.
29. @shemag8
Questions you want to ask
● Do all teams work on same framework (and
version)?
● Single deploy or independent deploy for each
module?
● Modules should be shared between apps?
● Modules should be loaded dynamically?
● Do we need to support SSR?
● ...
40. @shemag8
<Module 1>
● Technology Agnostic
● The DOM is the API
● Native support by
most browsers
● No shared state
<Module 2>
Plain old HTML (and JS)
Web Components
42. @shemag8
server {
# Decide which HTML fragment to
insert based on the URL
location /browse {
set $PAGE 'browse';
}
location /order {
set $PAGE 'order';
}
location /profile {
set $PAGE 'profile'
}
error_page 404 /index.html;
}
<html lang="en" dir="ltr">
<body>
<h1>Common code</h1>
<!--# include file="$PAGE.html" -->
</body>
</html>
43. @shemag8
/package1
● Support SSR
● Each package has its
own dedicated page
● Can be divided into
fragments and not
full pages /package2
API Proxy
App per route
62. @shemag8
Resources
● Lerna- http://bit.ly/2VAelIc
● Web Components- http://bit.ly/2PyN5V1
● Single SPA- http://bit.ly/2DB1f3a
● Miro FE (by Martin Fowler)- http://bit.ly/2knpmMJ
● IFrames- http://bit.ly/2vse4IE
● Exploring micro-frontends- http://bit.ly/2ZIc8cX
● Micro Frontends - Think Smaller, Avoid the
Monolith Love the Backend- http://bit.ly/2DzB39e
Notas del editor
PxWe
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)