Versions Compared

Old Version 4

changes.mady.by.user David Joy

Saved on

compared with

New Version 5

changes.mady.by.user Kyle McCormick

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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