Notes-03-15-Micro-frontend

PreviousNotes-03-15-Concurrent-with-requestIdleCallback NextWk-notes-03-09-micro-frontend-bootstrapper

Last updated 5 years ago

Was this helpful?

Notes-03-15-Micro-frontend

Micro-frontend Why and How

There is no silver bullet. Architectures, languages, patterns, and abstraction, they all serve to particular problem. For this note, let micro-frontend gets sorted out.

I dont' understand micro-frontend

Ref:

Context

Use the right tool for the right job, that should be our goal. Remember that developing software is empirical, not scientific.

Micro-frontend benefits team-wise, collab makes easy in certain(many) org structure. For separated dev, deploy and mgmt. It can also utilise ESI/CSI.

Multiple tech stacks

For concerns about multiple tech stacks, it is a problems for all micro-services architecture. There should be constraints to this anyway.

Bundle size

Shared dependencies on runtime, sofe, System.js.

Orchestrating

bootstrap

Routing micro-frontend
initial App
exposing API for frontends communications

E.G. Single-SPA.js

Main apis: bootstrap() mount() unmout()

SSR

For solutions like iframe or custom web component, SSR is almost impossible. For html + js approach, a successful SSR can lead to easy client side 'stitching'(orchestrating)

Integration approaches

Server-side template composition (ESI/SSI)
Build-time integration, import projects from package.json in a provider app, not too dynamic, introduce a lot over-head when developing, testing, and deploying
Run-time integration via iframes
Run-time integration via JavaScript, with a bootstrapper/register
Run-time integration via Web Components, similar to via javascript while it create a web-component

Shared component libraries

It is tempting to create a Foundation Framework, with all of the common visuals that will be needed across all applications. However, experience tells us that it's difficult, if not impossible, to guess what the components' APIs should be before you have real-world usage of them, which results in a lot of churn in the early life of a component.
Allow the patterns to emerge naturally, and once the component's API has become obvious, you can harvest the duplicate code into a shared library and be confident that you have something proven.

Cross-application communication

Whatever approach we choose, we want our micro frontends to communicate by sending messages or events to each other, and avoid having any shared state. Just like sharing a database across microservices, as soon as we share our data structures and domain models, we create massive amounts of coupling, and it becomes extremely difficult to make changes.

PreviousNotes-03-15-Concurrent-with-requestIdleCallback NextWk-notes-03-09-micro-frontend-bootstrapper

Last updated 5 years ago

Was this helpful?

Micro-frontend Why and How

There is no silver bullet. Architectures, languages, patterns, and abstraction, they all serve to particular problem. For this note, let micro-frontend gets sorted out.

I dont' understand micro-frontend

Ref:

Context

Use the right tool for the right job, that should be our goal. Remember that developing software is empirical, not scientific.

Micro-frontend benefits team-wise, collab makes easy in certain(many) org structure. For separated dev, deploy and mgmt. It can also utilise ESI/CSI.

Multiple tech stacks

For concerns about multiple tech stacks, it is a problems for all micro-services architecture. There should be constraints to this anyway.

Bundle size

Shared dependencies on runtime, sofe, System.js.

Orchestrating

bootstrap

Routing micro-frontend
initial App
exposing API for frontends communications

E.G. Single-SPA.js

Main apis: bootstrap() mount() unmout()

SSR

For solutions like iframe or custom web component, SSR is almost impossible. For html + js approach, a successful SSR can lead to easy client side 'stitching'(orchestrating)

Integration approaches

Ref:

Server-side template composition (ESI/SSI)
Build-time integration, import projects from package.json in a provider app, not too dynamic, introduce a lot over-head when developing, testing, and deploying
Run-time integration via iframes
Run-time integration via JavaScript, with a bootstrapper/register
Run-time integration via Web Components, similar to via javascript while it create a web-component

Shared component libraries

It is tempting to create a Foundation Framework, with all of the common visuals that will be needed across all applications. However, experience tells us that it's difficult, if not impossible, to guess what the components' APIs should be before you have real-world usage of them, which results in a lot of churn in the early life of a component.
Allow the patterns to emerge naturally, and once the component's API has become obvious, you can harvest the duplicate code into a shared library and be confident that you have something proven.

Cross-application communication

Whatever approach we choose, we want our micro frontends to communicate by sending messages or events to each other, and avoid having any shared state. Just like sharing a database across microservices, as soon as we share our data structures and domain models, we create massive amounts of coupling, and it becomes extremely difficult to make changes.