2021-01-31 - Micro Frontends: Difference between revisions
m (Sven the Barbarian moved page 2021-01-31 Micro Frontends to 2021-01-31 - Micro Frontends without leaving a redirect) |
No edit summary |
||
| (5 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
= Considerations = | = Considerations = | ||
* Want different objects, eg catalogs/products etc, to be able to set | * Want different objects, eg catalogs/products etc, to be able to set to be shown in different frontends | ||
* We will not restrict objects to only be viewed through their | * Many entities in the project may set their own frontend app, eg catalogs can set the UI frontend used on a per catalog record basis | ||
* We will not restrict these objects to only be viewed through their set frontend, users can select to force view them in any compatable frontend | |||
* SEO is important | * SEO is important | ||
* Extensibility by external teams is desired but can be applied later | * Extensibility by external teams is desired but can be applied later. Means allowing new client applications to build upon the code we have and deploy/maintained themselves | ||
= Composition options = | = Composition options = | ||
| Line 31: | Line 32: | ||
* Additional compute time/costs | * Additional compute time/costs | ||
* Slow page loading, the full app does not exist on the client | |||
== Run-time == | == Run-time == | ||
The client app is responsible for choosing which | The client app is responsible for choosing which micro frontend to load according to the route. Builds and cleans the environment for each page. | ||
=== Pros === | === Pros === | ||
| Line 43: | Line 45: | ||
* Perhaps more difficult to initially setup | * Perhaps more difficult to initially setup | ||
* Less control over which | * Less (or more difficult) control over which frontend client requests are directed to | ||
= Run-time design = | |||
Planning on using run-time design, with some serverside support, for example canary deploys. | |||
== Dynamic loading of frontends == | |||
Was considering dynamically loading frontends especially for situations where individual records might have a complex method of defining the frontend to be used, a container app could requests the frontend endpoint from the server and then pull the frontend in on a per page basis, or it could be each new page re-requests the frontend from the server and server decides which frontend to return. | |||
These options seem clunky, slow, and resource intensive, and kind of defeat the benefits of a single page application design, server-side rendering might even be more efficient. | |||
React remote components could be considered for dynamically loaded frontends. | |||
== Container app maintains list of available frontends == | |||
Each different frontend application has its own route and the container app maintains a record of these and their endpoints. | |||
Frontends can be lazy loaded so only those visited by the client get loaded into the client. Not sure whether they remain there once loaded or the spa framework cleans them up when no longer used. | |||
Records that can choose their own frontends pass this to the page so they are linked to accordingly using the correct route to their frontend. | |||
Break up frontends into applications, which are managed by each team/stack/domain, these applications can use shared micro frontend modules, eg: headers, search modules etc, which themselves are maintained separately and are pieced together by the frontend application in frames (or at build time) to make the final page. | |||
= Single SPA = | |||
Appears to be a lightweight framework that achieves what we are planning. Container app is called root config. | |||
= Authentication = | |||
Have the root config/container app maintain the users sign in token so all micro frontends can pass this with their requests to backend | |||
= Other = | |||
* [[2025-01-07 - Micro Frontends Tree Structure]] | |||
= References = | = References = | ||
Latest revision as of 10:12, 7 April 2025
Considerations
- Want different objects, eg catalogs/products etc, to be able to set to be shown in different frontends
- Many entities in the project may set their own frontend app, eg catalogs can set the UI frontend used on a per catalog record basis
- We will not restrict these objects to only be viewed through their set frontend, users can select to force view them in any compatable frontend
- SEO is important
- Extensibility by external teams is desired but can be applied later. Means allowing new client applications to build upon the code we have and deploy/maintained themselves
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
- Slow page loading, the full app does not exist on the client
Run-time
The client app is responsible for choosing which micro 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 (or more difficult) control over which frontend client requests are directed to
Run-time design
Planning on using run-time design, with some serverside support, for example canary deploys.
Dynamic loading of frontends
Was considering dynamically loading frontends especially for situations where individual records might have a complex method of defining the frontend to be used, a container app could requests the frontend endpoint from the server and then pull the frontend in on a per page basis, or it could be each new page re-requests the frontend from the server and server decides which frontend to return.
These options seem clunky, slow, and resource intensive, and kind of defeat the benefits of a single page application design, server-side rendering might even be more efficient.
React remote components could be considered for dynamically loaded frontends.
Container app maintains list of available frontends
Each different frontend application has its own route and the container app maintains a record of these and their endpoints.
Frontends can be lazy loaded so only those visited by the client get loaded into the client. Not sure whether they remain there once loaded or the spa framework cleans them up when no longer used.
Records that can choose their own frontends pass this to the page so they are linked to accordingly using the correct route to their frontend.
Break up frontends into applications, which are managed by each team/stack/domain, these applications can use shared micro frontend modules, eg: headers, search modules etc, which themselves are maintained separately and are pieced together by the frontend application in frames (or at build time) to make the final page.
Single SPA
Appears to be a lightweight framework that achieves what we are planning. Container app is called root config.
Authentication
Have the root config/container app maintain the users sign in token so all micro frontends can pass this with their requests to backend
Other
References
At 15 minute mark explains different composition options clearly
Describes Lambda Edge features for server-side composition type