2021-01-31 - Micro Frontends - Revision history

Pack at 10:12, 7 April 2025

2025-04-07T10:12:34Z

← Older revision		Revision as of 10:12, 7 April 2025
Line 77:		Line 77:
	Have the root config/container app maintain the users sign in token so all micro frontends can pass this with their requests to backend		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 =

Sven the Barbarian at 11:06, 28 February 2021

2021-02-28T11:06:09Z

← Older revision		Revision as of 11:06, 28 February 2021
Line 1:		Line 1:
	= Considerations =		= Considerations =

	* Want different objects, eg catalogs/products etc, to be able to set ~~default UI applications~~		* 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 UI app, eg catalogs can set the UI ~~app~~ used per catalog record		* 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 objects to only be viewed through their set ~~UI app~~, users can select to force view them in ~~other apps~~		* 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. Means allowing new client applications to build upon the code we have and deploy/~~maintain~~ themselves		* 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 32:		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 ==
Line 44:		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 (or more difficult) control over which frontend client requests are directed to

	= Run-time design =		= Run-time design =
Line 66:		Line 67:
	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.		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 to make the final page.		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

	~~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 =

Sven the Barbarian: /* Container app maintains list of available frontends */

2021-02-13T13:15:13Z

Container app maintains list of available frontends

← Older revision		Revision as of 13:15, 13 February 2021
Line 66:		Line 66:
	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.		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.		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 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.		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.

Sven the Barbarian at 14:52, 11 February 2021

2021-02-11T14:52:10Z

@@ Line 45: / Line 45: @@
 * Perhaps more difficult to initially setup
 * Less control over which app client requests are directed to
 = References =

Sven the Barbarian at 01:33, 11 February 2021

2021-02-11T01:33:10Z

← Older revision		Revision as of 01:33, 11 February 2021
Line 2:		Line 2:

	* Want different objects, eg catalogs/products etc, to be able to set default UI applications		* 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		* 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		* 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/maintain themselves

	= Composition options =		= Composition options =

Sven the Barbarian: /* Run-time */

2021-02-11T00:19:31Z

Run-time

← Older revision		Revision as of 00:19, 11 February 2021
Line 34:		Line 34:
	== Run-time ==		== 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.		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 ===

Sven the Barbarian: Sven the Barbarian moved page 2021-01-31 Micro Frontends to 2021-01-31 - Micro Frontends without leaving a redirect

2021-02-11T00:18:21Z

Sven the Barbarian moved page 2021-01-31 Micro Frontends to 2021-01-31 - Micro Frontends without leaving a redirect

← Older revision		Revision as of 00:18, 11 February 2021
(No difference)

Sven the Barbarian: 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..."

2021-01-31T09:26:27Z

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..."

New page

= 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 =

* https://www.youtube.com/watch?v=9Xo-rGUq-6E&t=94s
At 15 minute mark explains different composition options clearly

* https://www.youtube.com/watch?v=fT-5RHTtFNg&t=1427s
Describes Lambda Edge features for server-side composition type

[[Category:Working documents| 2021-01-30]]