# MFE runtime configuration **URL:** \ **Category:** Build-Test-Release\ **Created:** [October 11, 2022, 8:46pm UTC](https://discuss.openedx.org/t/mfe-runtime-configuration/8495 "2022-10-11T20:46:31Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![dcoa](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.openedx.org/dcoa/32/3246_2.png) [@dcoa](https://discuss.openedx.org/u/dcoa)\ **Post date:** [October 11, 2022, 8:46pm UTC](https://discuss.openedx.org/t/mfe-runtime-configuration/8495/1 "2022-10-11T20:46:31Z")
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: - [Fronted-app-account](https://github.com/openedx/frontend-app-account/pull/603) - merged (and available in olive) - [Frontend-app-profile](https://github.com/openedx/frontend-app-profile/pull/586) - pending review - [Frontend-app-gradebook](https://github.com/openedx/frontend-app-gradebook/pull/253) - pending review - [Frontend-app-learning](https://github.com/openedx/frontend-app-learning/pull/955) - pending review this MFE has a peer dependency error, to solve this is necessary an update of @edx/frontend-lib-special-exams (I create a PR there to upgrade frontend-platform [edx/frontend-lib-special-exams#70](https://github.com/edx/frontend-lib-special-exams/pull/70)) I hope you can help us with the review šŸ™‚. ---
**Author:** ![ghassan](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.openedx.org/ghassan/32/2779_2.png) [@ghassan](https://discuss.openedx.org/u/ghassan)\ **Post date:** [October 12, 2022, 6:47am UTC](https://discuss.openedx.org/t/mfe-runtime-configuration/8495/2 "2022-10-12T06:47:46Z")
@dcoa I have tried the to use/run the learning PR but got an error, so [left a comment](https://github.com/openedx/frontend-app-learning/pull/955#issuecomment-1275669551):. 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](https://github.com/openedx/frontend-app-course-authoring/blob/f54dc17788cd7a721e3c6c117c91e399db6c5d25/package.json#L40) is already using 2.5.1 does that make it work with the config API? ---
**Author:** ![dcoa](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.openedx.org/dcoa/32/3246_2.png) [@dcoa](https://discuss.openedx.org/u/dcoa)\ **Post date:** [October 12, 2022, 3:17pm UTC](https://discuss.openedx.org/t/mfe-runtime-configuration/8495/3 "2022-10-12T15:17:46Z")
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](https://github.com/openedx/frontend-app-course-authoring/blob/f54dc17788cd7a721e3c6c117c91e399db6c5d25/package.json#L40) 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](https://github.com/openedx/frontend-app-course-authoring/blob/master/public/index.html#L4)). ---
**Author:** ![regis](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.openedx.org/regis/32/2640_2.png) [@regis](https://discuss.openedx.org/u/regis)\ **Post date:** [October 13, 2022, 2:43pm UTC](https://discuss.openedx.org/t/mfe-runtime-configuration/8495/4 "2022-10-13T14:43:27Z")
I took the liberty to move this conversation to a separate topic so as not to hijack the [previous conversation](https://discuss.openedx.org/t/tutor-plugins-and-the-upcoming-olive-release/8463/2) 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](https://github.com/openedx/build-test-release-wg/issues/200) 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. ---
**Author:** ![Felipe](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.openedx.org/felipe/32/60_2.png) [@Felipe](https://discuss.openedx.org/u/Felipe)\ **Post date:** [October 13, 2022, 7:58pm UTC](https://discuss.openedx.org/t/mfe-runtime-configuration/8495/5 "2022-10-13T19:58:08Z")
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](https://github.com/openedx/build-test-release-wg/issues/200) > **[MFE- Runtime Config Support](https://docs.google.com/spreadsheets/d/1DDWx6jCBH39K-fUfBrT8UFzqqyGL-Gx0UeFujOkSNwU/edit#gid=0)** > > Sheet1 > > Repo Name,Is in tutor-MFE?,frontend-platform version,Fixed peer dependency,Support for favicon,PR status,PR LINK > openedx/frontend-app-account,yes,2.6.2,yes,yes,merged > openedx/frontend-app-gradebook,yes,2.3.0,pr opened,pr opened,merged on... 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](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](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. ---
**Author:** ![regis](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.openedx.org/regis/32/2640_2.png) [@regis](https://discuss.openedx.org/u/regis)\ **Post date:** [October 14, 2022, 1:29pm UTC](https://discuss.openedx.org/t/mfe-runtime-configuration/8495/6 "2022-10-14T13:29:57Z")
> [@Felipe](#): > > Also we have not been able to convince any of the teams working on those MFEs to add support for this. 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. ---
**Author:** ![arbrandes](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.openedx.org/arbrandes/32/158_2.png) [@arbrandes](https://discuss.openedx.org/u/arbrandes)\ **Post date:** [October 14, 2022, 3:02pm UTC](https://discuss.openedx.org/t/mfe-runtime-configuration/8495/7 "2022-10-14T15:02:33Z")
> [@regis](#): > > a very long list of MFEs in Olive > [@Felipe](#): > > Ohh boy, that is a lot of MFEs. 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](https://github.com/openedx/build-test-release-wg/issues/200). 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](https://github.com/openedx/build-test-release-wg/issues/131#issuecomment-1270548031) 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) ---
**Author:** ![arbrandes](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.openedx.org/arbrandes/32/158_2.png) [@arbrandes](https://discuss.openedx.org/u/arbrandes)\ **Post date:** [October 14, 2022, 3:12pm UTC](https://discuss.openedx.org/t/mfe-runtime-configuration/8495/8 "2022-10-14T15:12:10Z")
PS: The new Discussions MFE is worth taking [a serious look at](https://discuss.openedx.org/t/a-look-at-the-recent-enhancements-to-discussions-in-open-edx/8485). 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. ---
**Author:** ![kmccormick](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.openedx.org/kmccormick/32/8982_2.png) [@kmccormick](https://discuss.openedx.org/u/kmccormick)\ **Post date:** [October 14, 2022, 3:52pm UTC](https://discuss.openedx.org/t/mfe-runtime-configuration/8495/9 "2022-10-14T15:52:30Z")
> [@regis](#): > > > [@Felipe](#): > > > > Also we have not been able to convince any of the teams working on those MFEs to add support for this. > > 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: @Felipe @regis Iā€™m already on it for the three MFEs that are in Tutor but donā€™t have runtime config merged ([profile](https://github.com/openedx/frontend-app-profile/pull/586), [learning](https://github.com/openedx/frontend-app-learning/pull/955), [gradebook](https://github.com/openedx/frontend-app-gradebook/pull/253)). Profile and and gradebook will be merging Monday. Learning has a blocker in [frontend-lib-special-exams](https://github.com/edx/frontend-lib-special-exams/pull/70) that I am trying to get pushed through ASAP. ---
**Author:** ![kmccormick](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.openedx.org/kmccormick/32/8982_2.png) [@kmccormick](https://discuss.openedx.org/u/kmccormick)\ **Post date:** [October 14, 2022, 4:11pm UTC](https://discuss.openedx.org/t/mfe-runtime-configuration/8495/10 "2022-10-14T16:11:55Z")
+1 to everything @arbrandes has said. > [@arbrandes](#): > > _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. Relatedly, we have proposed [OEP-57](https://openedx.atlassian.net/wiki/spaces/COMM/pages/3540713547/Open+edX+Proposal+57+Product+Offering), 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 šŸ˜› > [@arbrandes](#): > > [This comment](https://github.com/openedx/build-test-release-wg/issues/131#issuecomment-1270548031) 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. 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. ---
**Author:** ![Felipe](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.openedx.org/felipe/32/60_2.png) [@Felipe](https://discuss.openedx.org/u/Felipe)\ **Post date:** [October 14, 2022, 4:58pm UTC](https://discuss.openedx.org/t/mfe-runtime-configuration/8495/11 "2022-10-14T16:58:34Z")
> [@arbrandes](#): > > #### Do we need to include every MFE in that list in Tutor/Olive? > > _TLDR: No._ 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. ---
**Author:** ![kmccormick](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.openedx.org/kmccormick/32/8982_2.png) [@kmccormick](https://discuss.openedx.org/u/kmccormick)\ **Post date:** [October 14, 2022, 5:02pm UTC](https://discuss.openedx.org/t/mfe-runtime-configuration/8495/12 "2022-10-14T17:02:49Z")
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. šŸ’æāž”ļøšŸ“€](https://github.com/openedx/frontend-template-application)? ---
**Author:** ![Felipe](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.openedx.org/felipe/32/60_2.png) [@Felipe](https://discuss.openedx.org/u/Felipe)\ **Post date:** [October 14, 2022, 7:06pm UTC](https://discuss.openedx.org/t/mfe-runtime-configuration/8495/13 "2022-10-14T19:06:26Z")
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](https://github.com/openedx/frontend-template-application/pull/486). ---
**Author:** ![ghassan](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.openedx.org/ghassan/32/2779_2.png) [@ghassan](https://discuss.openedx.org/u/ghassan)\ **Post date:** [October 17, 2022, 8:29am UTC](https://discuss.openedx.org/t/mfe-runtime-configuration/8495/14 "2022-10-17T08:29:29Z")
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](https://github.com/overhangio/tutor-mfe/pull/69) In regard of making MFEs compliment with dynamic config, as per @doca statement > [@dcoa](#): > > 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](https://github.com/openedx/frontend-app-course-authoring/blob/master/public/index.html#L4)). For the favicon issue, doesnā€™t setting a proxy/redit rule such that: **\/favicon.ico =\> \/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](https://github.com/openedx/frontend-app-course-authoring/blob/d1d04d55853a2e87273d99dfb5e055a1ea97373d/package.json#L40) would be flagged as ready since its already using frontend-platform 2.5.1. ---
**Author:** ![fghaas](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.openedx.org/fghaas/32/168_2.png) [@fghaas](https://discuss.openedx.org/u/fghaas)\ **Post date:** [October 25, 2022, 8:56am UTC](https://discuss.openedx.org/t/mfe-runtime-configuration/8495/15 "2022-10-25T08:56:21Z")
> [@kmccormick](#): > > 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. 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](https://discuss.openedx.org/t/whats-the-deal-with-tpa-hinted-links-in-nutmeg/8436/12)): 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. ---
**Author:** ![arbrandes](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.openedx.org/arbrandes/32/158_2.png) [@arbrandes](https://discuss.openedx.org/u/arbrandes)\ **Post date:** [October 26, 2022, 5:57pm UTC](https://discuss.openedx.org/t/mfe-runtime-configuration/8495/16 "2022-10-26T17:57:34Z")
Moved the TPA hinted links conversation into its original thread: [Whatā€™s the deal with TPA hinted links in Nutmeg?](https://discuss.openedx.org/t/whats-the-deal-with-tpa-hinted-links-in-nutmeg/8436/14)