2021-01-31 - Micro Frontends: Difference between revisions
No edit summary |
No edit summary |
||
| Line 45: | Line 45: | ||
* Perhaps more difficult to initially setup | * Perhaps more difficult to initially setup | ||
* Less control over which app client requests are directed to | * Less control over which app 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, 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 to make the final page. | |||
Not sure whether the frontend modules get packaged and built into the frontend application or are pulled in from a separate route at runtime by the client. | |||
= References = | = References = | ||
Revision as of 14:52, 11 February 2021
Considerations
- Want different objects, eg catalogs/products etc, to be able to set default UI applications
- Many entities in the project may set their own UI app, eg catalogs can set the UI app used per catalog record
- We will not restrict objects to only be viewed through their set UI app, users can select to force view them in other apps
- 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/maintain 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
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 control over which app 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, 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 to make the final page.
Not sure whether the frontend modules get packaged and built into the frontend application or are pulled in from a separate route at runtime by the client.
References
At 15 minute mark explains different composition options clearly
Describes Lambda Edge features for server-side composition type