Enteprise MFE Config meeting - 8-19-19

Owned by David Joy (Deactivated)
Last updated: Aug 20, 2019

Enterprise is creating a Learner Portal. This is effectively a closed platform ("walled garden") - a set of pages focused on the learning and course discovery experience for Enterprise-based learners. This necessarily means branding, but it also means focusing the courses the user sees down to those the Enterprise wants them to see. The users can still go to edx.org - and do for some pages - but the high value experiences should exist in this platform.

The Enterprise and Arch teams are finding that their interests are heavily aligned across a few different axes:

  • The Arch team is due to start work on the courseware and course outline pages, which are of high value to the Enterprise team. We believe (hope) that some features of those pages will be more important than others, which will allow the Arch team to try to prioritize work that helps Enterprise have a usable product, sooner.
  • The Arch team is also due to start work on the configuration and code deduplication of the existing micro-frontends, with the specific goal of enabling the sort of client-specific configuration that Enterprise needs to do, and of firming up the boundaries and interfaces between the micro-frontend application code with the submodules/pages they depend on, allowing them to be more readily consumed for use cases like Learner Portal.

After talking about Learner Portal and the shape of the Profile Page MFE, we determined a few things.  Learner Portal can be thought of as having two broad parts:

  • A Gatsby-based build process capable of deploying multiple configurations of multiple independent micro-frontends
  • A home for the Enterprise and Masters versions of the closed platform.

There are a few high value sets of pages that are of particular interest to Enterprise:

  • Course discovery
  • Checkout
  • Course experience

Everything else is a nice to have.

Ideal timeline:

  • Want prototype at global forum
  • Launch in the new year (Editorial note: I heard this as meaning calendar year 2020)

Regarding configuration of micro-frontends, there are three types of configuration for Enterprise today:

  • Production configuration across all enterprises
  • Configuration across environment (i.e., per enterprise)
  • In the configuration repository
  • Build-specific configuration
  • Happens in designer, props that get passed in
  • Gatsby plugin queries designer for a hostname to grab build configuration

It's the build-specific configuration that the Arch team is going to start looking at.

Types of theming that Enterprise needs to do at build time:

  • Branding
  • Hero component
  • Background images
  • Colors / Borders
  • Logos

Editorial note: so pretty standard stuff! That's good!

Question: Is it desirable for the MFE to stay an MFE?

Yes, and despite being pulled into Learner Portal, the Arch MFEs would effectively remain as such. We can work together to normalize/reuse the logic that embeds the MFE's main content components so that, hopefully, the edx.org versions of the MFEs and the Learner Portal versions will be very similar regardless of what we decide to do with the header and footer. Specifically, the Arch team has some work coming up around defining application bootstrapping code. If this is made flexible enough to have different headers/footers provided, it will enable both options.

Question: Is it desirable for us to truly share a header and footer? The same component? Or should enterprise have their own?

Unanswered. Is the Enterprise header/footer sufficiently different enough that it should just be a separate component?

It seems as if there's a need for the header and footer components to be significantly different than those on the existing MFEs today. There are two approaches to fix this:

- Pull out the main content component of the MFE and embed it in a new HTML/React wrapper that includes the proper header/footer. Hook up the main content component to its new home.
- Make the header and footer components (frontend-component-site-header and frontend-component-footer) configurable enough that Enterprise can include them in their build-time configuration.

Enterprise is currently pursuing the former; Arch was aiming to pursue the latter. It's unclear exactly which should be the right approach, but it does feel as if we only need one of the two.

Next Steps

  • Arch team to provide some proposed timelines for their courseware, course outline, and configuration work to help Enterprise plan.
  • Meeting to discuss in more technical depth the ways that Enterprise would like to extract the page components from Arch MFEs, with the goal of establishing a pattern in line with some of the MFE application initialization/de-duplification work that Arch is planning on doing soon.  This will help us align more in the future.
    • Coming out of this meeting, we'd like to have some tasks on our respective backlogs to help enable Enterprise to pull other MFEs into Learner Portal.

Reading the Tea Leaves

From the arch team's perspective, we can see that the work that's being done in Learner Portal w/r/t aggregating, building, and deploying multiple MFEs with a common set of configuration and branding is highly valuable and probably should be the way we deploy the edx.org MFEs in the future. We'd like to be able to work with Enterprise to make their work on Learner Portal reusable.

I didn't run this by anyone, but one pie-in-the-sky way I could see this going in the future (tons of hand waving here):

  • There's a frontend-build repository with the multi-MFE build process code in it which can be leveraged for a variety of purposes (Enterprise, edx.org, maybe Open edX, etc.)
  • The enterprise and masters subdirectories in src in frontend-app-learner-portal become their own repositories, separate from the build process, but leveraged by it for Enterprise's needs.
  • Enterprise's configuration of the build process would also be able to pull in any other MFEs they need for Learner Portal, configure them, and deploy them, unifying the process for their existing frontends with those being created elsewhere in the organization.