Topics

• Demo of single-spa with Adam Stankiewicz!

• Arch Tea with Luca Mezzalira debrief

  • Notes/questions from that meeting: Arch Tea with Luca Mezzalira (Pre-Work) - 2020-07-09

  • Recording of Arch Tea Time with Luca

  • Takeaways

    • Do these feel like the right take-aways?

    • MFE requirements DAZN doesn't have:

      • Many Domains (primarily a video tool - their whole business is 5 total)

      • Theming

      • Pluggability

      • Approachability

        • ability for new teams/community members to bootstrap/onboard/understand our code and build things that fit into the ecosystem

    • MFE principles at DAZN

      • No cross-MFE component sharing

      • No cross-MFE shared assets (runtime)

      • 1 team, 1 MFE

      • Independent build systems, container-based

      • Spinner displayed on page load to give immediate feedback

  • Questions

    • How might the requirements above change our MFE strategy? From DAZN’s? From our current state?

    • How do DAZN’s principles compare to our needs?

    • Luca mentioned dividing MFEs by “user journey” through a DDD lens… Should we do the same at edX? How can we be better about doing so?

    • What steps can we take to improve our MFEs?

    • Do we need server-side rendering (SSR)? What might it enable?

    • Luca said that DAZN decidedly doesn’t share headers between their MFEs. Should we take that advice? Or should we push forward with frontend-component-header?

      • This is on the top of my mind as development of both frontend-app-library-authoring and frontend-app-course-authoring progresses, both of which need a very similar Studio-like header.

      • If the design system (Paragon) had a defined layout (HTML and classnames) for a header component that may be enough. Each MFE could copy the necessary structure . This appears to have been the DAZN approach, but their header and footer are much simpler than ours.