While our platform architecture is a year-and-a-half into applying MFEs to our monolith strategy, we still have a way to go as we mature our frontend platform. Don’t miss out on this opportunity to come and hear how we may apply Luca’s learnings and experiences on developing and scaling MFEs.
Pre-post your questions below to give Luca an idea of the content of our discussion with him.
Luca's Definition of MFEs
Micro-frontends are the technical representation of a business subdomain, allowing independent implementations with same or different technology choices. An MFE avoids sharing logic with other subdomains and is owned by a single team.
Our goal is to have a Q&A discussion with a Micro-frontend expert who can provide an external perspective to edX’s MFE development and future MFE growth and scaling needs.
In your talk, you described your MFE principles and your "Bootstrap" architecture. Can you review what we have listed below? Is that still accurate?
In your talk, you described 5 different subdomains (Landing Pages, Authentication, Discovery, Support, and Account). You also said there was 1 MFE per subdomain.
So did you have only 5 MFEs at that time?
How many micro-frontends do you have today?
How many are planned?
Your "Bootstrap" technology sounds similar to edX's "Frontend Platform" technology, but each currently has different responsibilities. Would you be interested in comparing the two technologies with us?
In your talk, the Onboarding FE+BE team was mentioned. Could you touch on the experience that team works to provide and the value it provides to your business?
In your talk, you described how MFEs should represent a single sub-domain. You also mentioned how MFEs can be split apart as the organization scales. Do you have any updated perspectives on this?
How do you decide the boundary of a micro-frontend? That is, how small/large should an MFE be?
In your talk, you mentioned "components, code, styles, and assets" are shared only within an MFE. Does this mean you did not share them across MFEs?
How are shared components and libraries managed?
What have you chosen to share as common libraries across all your MFEs versus chosen to keep as independent business logic within each MFE?
How do you handle headers and footers and other common UI elements that need to be consistent throughout multiple MFEs and need to be updated in-synch?
In your talk, you mentioned that Bootstrap handles 'shared configuration' - is this things like commonly used constants, feature flags, etc., or something else?
Are your micro-frontends served as static assets, or are you doing any Server-side Rendering?
What would you recommend as an MFE deployment strategy for our open source community, which entails varying levels of scale, technical abilities, and technology choices?
Do you recommend any strategies or tools for deploying MFEs?
What are the benefits/tradeoffs of using something like single-spa as a container/shell for MFEs vs. completely separate applications?
At the end of your talk, you noted 2 years without S1 (CAT-1 for us), which is intriguing. Was this for frontend changes only? Are backend changes also rolled out using MFE canaries making different calls, or a different technique? Anything else to share around this?
UX & UI
What strategies/opportunities/challenges exist for getting MFEs to adopt a common design system / component library?
How do you avoid drift across MFEs in terms of UI/UX?
What's your impression of the performance of MFEs vs. more monolithic SPAs?
Have you had any false starts with MFE architecture?
Do you recommend any strategies or tools for the local development of MFEs?