A mindmap summarising micro-frontends concepts
APACHE-2.0 License
In this repository, you will find mindmaps we created about Micro-Frontend based on public information. As all of the information is already in the public domain, please feel free to use and share these mindmaps however you like.
Micro-frontends are the technical representation of a business subdomain, they allow independent implementation with the same and different technology.
Please find the key factors for micro-frontends below.
The 4 pillars that we need to decide up-front when architecting micro-frontends, as stated by Luca Mezzalira here in his medium article - Micro-frontends decisions framework.
graph TD;
A1[Micro-frontends decisions framework]-->B1[Definition];
A1[Micro-frontends decisions framework]-->B2[Composition];
A1[Micro-frontends decisions framework]-->B3[Route];
A1[Micro-frontends decisions framework]-->B4[Communication];
Identifying micro-frontends becomes quite straightforward. Understanding how users behave is of great use in determining our micro-frontends. You can read Luca Mezzalira's full article here for more details.
Identifying micro-frontends in our applications
graph TD;
A1[Defining Micro-Frontends]-->B1[Horizontal split];
A1[Defining Micro-Frontends]-->B2[Vertical split];
B1--Domain Driven Design-->C1[Core Subdomains]
B1--Domain Driven Design-->C2[Supporting Subdomains]
B1--Domain Driven Design-->C3[Generic Subdomains]
B2--Domain Driven Design-->C1[Core Subdomains]
B2--Domain Driven Design-->C2[Supporting Subdomains]
B2--Domain Driven Design-->C3[Generic Subdomains]
Analyzing how different frameworks can be used with different micro frontends on the same page.
graph TD;
A[Composition of Micro-frontends]-->A1[Client-side composition];
A[Composition of Micro-frontends]-->A2[Edge-side composition];
A[Composition of Micro-frontends]-->A3[Server-side composition];
A[Composition of Micro-frontends]-->A4[Build Time Composition];
Client Side Composition is one of the patterns that combine Fragments on client-side
graph TD;
A1[Client-side composition]-->B1[Fragments]
A1[Client-side composition]-->B2[Libraries]
B2[Libraries]-->C1[single-spa/single-spa]
B2[Libraries]-->C2[frintjs/frint]
B2[Libraries]-->C3[smapiot/piral]
Basically its combination of client side and server side composition to take the advantages of CDN caching. Idea behind edge-side composition – fragments are stitched together, close to the client.
graph TD;
A1[Edge-side composition]-->B1[Lambda Edge]
A1[Edge-side composition]-->B2[Rendering Example]
B1[Lambda Edge]-->C1[AWS Lambda CloudFront]
B2[Rendering Example]-->D1[Next js using Lambda Edge and Serverless Framework]
B2[Rendering Example]-->D2[Cloudflare Workers using a framework called Flareact]
Pattern that assembles Fragments on the server side.
graph TD;
A1[Server-side composition]-->B1[Layout Server]
A1[Server-side composition]-->B2[Fragments Server]
A1[Server-side composition]-->B3[Fragment Gateway]
A1[Server-side composition]-->B4[Libraries]
B4[Libraries]-->C1[Ara Framework]
B4[Libraries]-->C2[OpenComponents]
B4[Libraries]-->C3[Piral]
B4[Libraries]-->C4[Tailor]
Build Time Composition assembles Fragments at build time, not at client or server. Publish each micro frontend as a package, and have the container application include them all as library dependencies.
graph TD;
A1[Build Time Composition]-->B1[Shared libraries]
A1[Build Time Composition]-->B2[Static Site Generators]
A1[Build Time Composition]-->B3[Bit]
There are sometimes UI fragments belonging to different teams that need to interact or communicate. When a user adds an item to the basket by clicking the buy button, other micro frontends such as the mini basket want to be notified to update their content accordingly.
graph TD;
A1[User interface communication]-->B1[Parent to fragment]
A1[User interface communication]-->B2[Fragment to parent]
A1[User interface communication]-->B3[Fragment to fragment]
A1[User interface communication]-->B4[Publish Subscribe with the Broadcast Channel API]
graph TD;
A1[Sharing state]-->B1[Web Workers]
A1[Sharing state]-->B2[Props and callbacks]
A1[Sharing state]-->B3[Custom Events]
A1[Sharing state]-->B4[Pub Sub library]
A1[Sharing state]-->B5[Custom implementation]
graph TD;
A1[Parent to Fragment]-->B1[Element Attributes]
A1[Parent to Fragment]-->B2[Connected Callback]
A1[Parent to Fragment]-->B3[Attribute Change Callback]
graph TD;
A1[Fragment to Parent]-->B1[Custom Events]
A1[Fragment to Parent]-->B2[Event Listeners]
graph TD;
A1[Fragment to Fragment]-->B1[DOM Manipulation]
A1[Fragment to Fragment]-->B2[Attributes and Callbacks]
A1[Fragment to Fragment]-->B3[Event Bus]
A1[Fragment to Fragment]-->B4[Broadcast Channel API]
graph TD;
A1[Global Communication]-->B1[URL Params]
A1[Fragment to Fragment]-->B2[Global Context and State]
A1[Fragment to Fragment]-->B3[State Management Libraries Redux]
A micro-frontend is a technical representation of a business subdomain that has a specific behavior that is controlled by the self.
A Component is a technical solution for any frontend element that has a specific behavior that may be modified by a controlled component or container.
Component | Micro-Frontends |
---|---|
Technical Solution | Technical Representation of business subdomain |
Having a specific behavior that may be modified by a controlled component or container. | Having some Behaviour but driven by self |
There are several ways to implement a microfrontend, and this article(3 Ways to Build Micro-Frontends) will help you understand them.
According to my understanding, the application shell is the most crucial component of a micro-frontend architecture, as it is the component that enables you to render your all micro-frontends inside of a container.
The application shell serves as the parent application to all micro-frontends. All incoming requests arrive there, It selects the micro-frontend that the user wishes to view and renders it in the documents.
Module federation allows a JavaScript application to dynamically run code from another bundle/build, on both client and server.
Each pattern, as we know, has advantages and disadvantages, and in order to use it, we must establish a boundary between these and our requirements.