Luca Mezzalira, VP of Architecture at DAZN, has recently written a book about micro-frontend architecture, being published by O'Reilly early next year. We'd like to set up an arch tea with him to discuss edX's approach to MFEs and to learn from his own experiences.  Prior to that, we'd love to gather any questions the team might have, or things we'd like to discuss.  For a prior session of this type, see: Arch Lunch with Julie, Hubspot Design System lead - 2019-01-09

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

• Pre-watch this excellent 30mn video (Scaling your projects with Micro-frontends - Luca Mezzalira) as preparation for this meeting. 

• Pre-post your questions below to give Luca an idea of the content of our discussion with him.
  
  
  

Goal

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.

Reminders

• Recording reminder

• Asking questions:

  • Put a * in the chat

  • question in chat

  • anonymously in poll: https://pollev.com/nimishaa797

• Assume video was watched

• Mindset

  • Planning to dive into MFEs in general, learned experiences at DAZN, and applicability to edX.

  • No decisions being made today.

  • Only an exchange of ideas and learnings with the intent to seek to understand.
    
    

Questions for Luca

• DAZN

  • 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?

• Boundaries

  • 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?  

• Deployment

  • 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?

• [Omar] When not to have microfrontends?

MFEs at DAZN

These are notes based on Luca's 30mn video.

• Engineers: 350

• Frontend devices: 15

• Principles

  • Each MFE represents 1 sub-domain, matching the business structure.

  • MFEs are tech and framework agnostic.

  • MFEs are independent and autonomous.

  • Components, code, styles, and assets are shared within MFEs.

  • MFEs can have independent build systems.

  • Only 1 MFE can be loaded at a time.

  • Only 1 team per MFE.

• "Bootstrap"

  • The infrastructure that is always present and that orchestrates the MFEs.

  • Responsibilities

    • App Startup

    • I/O Operations

    • Routing

    • Shared Configurations

MFEs at edX

• Engineers:

  • edX: 70

  • Contractors: 50

  • Open edX: 150 ?

• Number of MFEs: 13

  • Largest: 65k LOC: https://github.com/edx/frontend-app-publisher

  • Smallest: 23k LOC: https://github.com/edx/frontend-app-ecommerce

• MFE Tech Stack:

  • React & Redux

  • Webpack

  • ES6 and beyond (thanks Babel)

  • Deployment to S3 via Terraform/GoCD

  • CDN via CloudFlare

• Still to come:

  • Frontend asset caching between MFEs

  • Theming and branding

  • Component overrides

  • Frontend pluggability and extensions

• Problems:

  • Lack of asset caching between MFEs!  (e.g., all app dependencies are loaded as part of a different vendor bundle for each app, even if they're the same dependency)

  • Frontend repository granularity (too many repositories to manage, which can create cascading version updates)

  • Balance of flexibility vs. consistency - should our MFEs all use the same version of react? Of our frontend-platform library? 

  • Knowing when to move code to a reusable code library (frontend-platform, paragon, its own repo, etc.)

MFEs and their LOCs

Meeting Notes (not complete - please update when you can)

• DAZN Updates

  • MFEs are independent and autonomous.

  •  

    • Caveat: 1 shared library is forcing 2 MFEs to be dependent.

•  

  • Engineers: 350 -> 400 (spread across 4 Dev centers)

  • Devices: 15 -> 40

• In your talk, you described 5 different subdomains (Landing Pages, Authentication, Discovery, Support, and Account). You also said there was 1 MFE per subdomain.

  • 5 domain-based MFEs -> 7 domain-based MFEs

  • Multiplied by the # of Device type families

•  Bootstrap vs edX’s FE-platform

  • All assembly happens at compile-time, not at run-time  

  • By having a skeleton, DAZN can avoid full-page refreshes during routing 

•  

  • Bootstrap needs to accommodate many more device types

  • Bootstrap provides a HTML skeleton where nodes are added at build time.

•  Is the bootstrap portion owned by one team?

•  

  • Initially, one dedicated “core” team, but now shared across a few MFE teams. 

• “Abstraction can be a bottleneck”

•  

  • “Feel free to duplicate code”

  • “Frontend devs are sometimes too naive about what components can be shared”

• Developer experience of MFEs is hard

•  

  • “Have a shared vision [of DevX] between micro-frontends”

  • Start with making CI/CD consistent, frictionless

• Plugins

  • Can have multiple plugins/MFEs that can live together in bi-drectional way.

  • A configuration can have multiple remotes or libraries

  • Bi-directional since a component can be a container or a remote

  • When importing “remote”, you can specify which JS/framework version to use

•  

  • Sandboxed via iFrames

  • “Model Federation” with Webpack 5 applied to Roll-up

  • https://github.com/tc39/proposal-realms

•   Web Components & Shadow-DOMs

•  

  • Polyfill - can lazy-load

  • Wasn’t very compatible across browsers

• Production issues

•  

  • Looking into “Testing in Production”

  • Invested a lot in CI/CD - especially CI

•  When not to MFE

•  

  • Size of company. For example, less than 20 engineers.

• MFE Slack space with Luca and other MFE practitioners: https://join.slack.com/t/micro-frontendsgroup/shared_invite/zt-8zpefzp2-2SG2keSqV_R15WhxrMjPWg