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

...

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

...

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