2021-01-31 - Micro Frontends
Revision as of 09:26, 31 January 2021 by Sven the Barbarian (talk | contribs) (Created page with "= Considerations = * Want different objects, eg catalogs/products etc, to be able to set default UI applications * We will not restrict objects to only be viewed through thei...")
Considerations
- Want different objects, eg catalogs/products etc, to be able to set default UI applications
- We will not restrict objects to only be viewed through their selected UI apps, users can select to force view them in other apps
- SEO is important
- Extensibility by external teams is desired but can be applied later
Composition options
How to host/compile/deliver a set of micro frontends. All options require a wrapper app that delivers to the client that handles things like authorization.
Build-time
The client app is a single container that holds all micro frontends
Cons
- Large application to be downloaded
- Must recompile full app if any micro frontend changes
Server side
The server does all the work, creating a final html page that is delivered to the client. For example Lambda Edge directing the request to certain app/s according to rules.
Pros
- Can achieve strong SEO results
- Can do extra tasks like canary testing, url re-writing, internationalization from headers, presenting results specifically for bots
Cons
- Additional compute time/costs
Run-time
The client app is responsible for choosing which micto frontend to load according to the route. Builds and cleans the environment for each page.
Pros
- Only the required frontends are loaded
Cons
- Perhaps more difficult to initially setup
- Less control over which app client requests are directed to
References
At 15 minute mark explains different composition options clearly
Describes Lambda Edge features for server-side composition type