MFE runtime configuration

Working Groups Build-Test-Release
1

Hi @regis and @ghassan

We work to integrate the runtime configuration feature in the MFE and create the corresponding PRs, this is the current state:

I hope you can help us with the review :slight_smile:.

1 Like
2

@dcoa
I have tried the to use/run the learning PR but got an error, so left a comment:.

Secondaly for other MFEs, does it only require to update frontend-platform to at least 2.5.0 so it can benefit from config API? for example frontend-app-course-authoring ref is already using 2.5.1 does that make it work with the config API?

3

Thanks, I’ll check your comment in the learning app.

Secondaly for other MFEs, does it only require to update frontend-platform to at least 2.5.0 so it can benefit from config API? for example frontend-app-course-authoring ref is already using 2.5.1 does that make it work with the config API?

Yes, updating frontend-platform >= 2.5.0 makes it possible to use the API, just take in mind to set environment variables MFE_CONFIG_API_URL and APP_ID.

In addition, I add Helmet to actualize favicon and site name (displayed in tab browser) with javascript just in case use the API to set these values (these are set in build time in the HTML file and can’t be editable frontend-app-authoring reference).

2 Likes
4

I took the liberty to move this conversation to a separate topic so as not to hijack the previous conversation on Tutor plugins and the Olive release.

It looks like we will have a very long list of MFEs in Olive: Olive: list of new MFEs · Issue #200 · openedx/build-test-release-wg · GitHub
So I’m really anxious that we have runtime configuration for all these MFEs. If not, we will not be able to release Olive.
I don’t know anything about MFEs, so I can’t really help review these PRs. But I really want to communicate to you my feeling of urgency.

1 Like
5

Ohh boy, that is a lot of MFEs.

I’m a little unsettled by the fact that even though the backend API was merged Months ago and that we have the account app working with this since August we have not made progress in merging more support for this. Also we have not been able to convince any of the teams working on those MFEs to add support for this.

However, moving on into the do-ocracy territory we need to do something big. What @dcoa has been doing for the 4 initial MFEs was to:

  1. update frontend-platform (>=2.5.0)
  2. update header and footer where necessary to avoid peer dependency errors
  3. fix any outstanding errors or make sure the CI builds (i18n)
  4. add support for changing the favicon (Head component)

This is a table with an overview of the status of the repos mentioned in the olive issue

I would like to move this needle forward by making “barn raise” activity where anyone can join (very little experience with MFEs required) and take one of this and fix it. Given the urgency, I’m planning this for tomorrow Friday 14th at 12:00 EST.
I’ll be inviting the team at edunext, but anyone is welcomed.

Fix all the things! (MFEs version)
Friday, October 14 · 12:00 – 13:00
Google Meet joining info
Video call link: https://meet.google.com/zay-ccrb-nsr
Or dial: ‪(CO) +57 601 8956250‬ PIN: ‪529 736 754 5804‬#
More phone numbers: https://tel.meet/zay-ccrb-nsr?pin=5297367545804

This alone however will not be enough. The biggest issue with those PRs is the review process, so we still need some second or third pair of eyes on each PR.

2 Likes
6

This is a problem, obviously. It is essential that we get this feature in Olive, otherwise we will not be able to include all these new MFEs. @e0d @nedbat can you help us get this message across? Our problem is the following:

  1. In the current state, building MFEs takes a very long time (~couple minutes/MFE), and all platforms need to incur this cost for every minor configuration change. The reason for that is that building assets for an MFE depends on its user-specific configuration. (As opposed to the Django configuration which is only loaded at runtime)
  2. The solution to this problem is what we call “runtime configuration” but it was merged only to a couple MFEs. (see Google doc above)
  3. Without these changes in the MFE release branches, the platform building time will become prohibitive in Olive, because there will be too many MFEs.
7

Hold on, folks! Just because some MFEs got Olive branches does not mean we have to include them in Tutor!

As tutor-mfe maintainer and tCRIL’s frontend guy, I took the liberty of assigning myself Olive: list of new MFEs · Issue #200 · openedx/wg-build-test-release · GitHub. I’ve been having conversations with people about this, this week, and here’s where we stand:

Do we need to include every MFE in that list in Tutor/Olive?

TLDR: No.

MFE developers (as of now mostly employed at or by 2U) are aware they can’t remove a feature in edx-platform before the MFE that replaces it is officially accepted as being production-ready by the community. This should apply to each MFE in that list, and it means we don’t have to enable any of them for Olive if we don’t want to.

How do we decide which ones to include?

TLDR: Don’t know. We need to decide how to decide.

While the ultimate decision on whether an MFE is ready is in fact up to the community, and in particular, the BTR group, there is no official method to arrive at this decision. This is a problem we should fix pronto, precisely so we can answer the question of which ones to include.

This comment in the ticket where we’re tracking this question is a collation of the information I could find. Please refer to it and add your comments, including which MFEs you would like to have included, and why. Once we have a reasonable idea of where the community’s opinion lies, we can start to narrow down the list in a technical fashion: by checking each MFE against the criteria.

(And yes, right off the bat it looks like a sine qua non criterion is whether the MFE supports runtime configuration.)

Product considerations

TLDR: Let’s consult the Product Working Group as well.

There are product considerations to take into account. Ultimately, I think the list will be narrowed down a lot by them. I’m not saying they have ultimate say, but it doesn’t make sense to start maintaining Tutor support for an MFE if it doesn’t make sense to make it part of the Open edX product at a given point in time.

I’ve started discussing this with @jmakowski, yesterday. The short of it is that my job will be to try and put all stakeholders together (mostly asynchronously, such as via this post) so we can decide ASAP which MFEs to work on for Olive.

(Committing additional BTR “taggery” for awareness: @pdpinch, @ghassan, @sambapete, @BbrSofiane, @Dean, @kmccormick)

3 Likes
8

PS: The new Discussions MFE is worth taking a serious look at. The developers are doing their best to have it ready ASAP. They’re saying “early November”, so it should be theoretically possible to include it.

9

@Felipe @regis I’m already on it for the three MFEs that are in Tutor but don’t have runtime config merged (profile, learning, gradebook). Profile and and gradebook will be merging Monday. Learning has a blocker in frontend-lib-special-exams that I am trying to get pushed through ASAP.

2 Likes
10

+1 to everything @arbrandes has said.

Relatedly, we have proposed OEP-57, which would create a system for deciding what needs to be enabled by default in the named releases (the “Core Product Offering”). I encourage all of BTR to review it and I am hopeful that this will make things easier when the Palm release rolls around. I recognize that an unmerged OEP isn’t extremely helpful for deciding what goes in Olive :stuck_out_tongue:

One criteria I’d add is: Has the legacy version of the frontend stopped working on master?. If yes, we’re forced to either get the legacy feature fixed, or to include & enable the MFE. When it’s unexpected, this scenario drives me crazy and represents an absolute failure of our deprecation process. Yet, it’s still something we need to look out for when considering MFEs for release.

3 Likes
11

Absolutely agree.

However we must start offering support for runtime configuration if we ever want to enable those MFEs in the open-release. Given how long it took to merge those PRs in the first 4 repos we tried I think the sense of urgency remains.

12

Any reason we shouldn’t add runtime config to the frontend template? GitHub - openedx/frontend-template-application: A template repository for creating Open edX frontend applications. 💿➡️📀?

13

I was of the same mindset @kmccormick so during the call activity that is the repo I worked on upgrading. I tagged you on the PR.

1 Like
14

I have been doing some testing with configuration and I was able to use an Open edX Olive instance without building the docker image, more details can be found here: https://github.com/overhangio/tutor-mfe/pull/69

In regard of making MFEs compliment with dynamic config, as per @doca statement

For the favicon issue, doesn’t setting a proxy/redit rule such that:
<mfe_host>/favicon.ico => <lms_host>/favicon.ico similar to what we have in the PR above where config url is being proxed to lms.

This would ensure even if we have already built MFE image, favicon.ico would be loaded from lms/favicon.ico

If we agree on the above statement then frontend-app.course-authroing would be flagged as ready since its already using frontend-platform 2.5.1.

15

I’d like to add another possibility to this: (a feature of) the legacy frontend has stopped working on master, and its corresponding functionality has not been confirmed on the replacing MFE.

Right now we might be in this very situation for TPA hinted links in combination with the Learning MFE (see this thread): the feature appears to be broken in the legacy frontend, it might be fixed in the authn MFE, but we haven’t had any way to confirm that on Nutmeg since there’s no way to Tutor-deploy the authn MFE on Nutmeg. So right now, we really have no way of knowing if this will work in Olive.

1 Like
16

Moved the TPA hinted links conversation into its original thread: What’s the deal with TPA hinted links in Nutmeg?