feat: MFE configuration at runtime

[dcoa]

Description:

This draft PR serves as a discussion holder for the work of making mfes capable of being configured during runtime instead of during build.

This PR creates a new function to allow runtime configuration through an API call to the platform.

How to test

• To allow runtime configuration set a new environment variable MFE_CONFIG_API_URL in the env file and add the api url ( To test this you can use the API from this PR or use an external tool to mock the API response).
• The API should respond with a JSON with the config values:

{
  "SITE_NAME": "Test Site",
  "LOGO_URL": "https://testimage.com/logo.svg",
  "LOGO_TRADEMARK_URL": "https://testimage.com/logo.svg",
  "LOGO_WHITE_URL": "https://testimage.com/logo.svg",
  "FAVICON_URL": "https://testimage.com/favicon.ico",
  "CSRF_TOKEN_API_PATH": "/csrf/api/v1/token",
  "LANGUAGE_PREFERENCE_COOKIE_NAME": "openedx-language-preference",
  "LOGIN_URL": "http://testsite.example.com/login",
  "LOGOUT_URL": "http://testsite.example.com/logout",
   "STUDIO_BASE_URL": "http://studio.example.com",
  "MARKETING_SITE_BASE_URL": "http://testsite.example.com",
  "ORDER_HISTORY_URL": "http://testsite.example.com/orders",
  "REFRESH_ACCESS_TOKEN_ENDPOINT": "http://testsite.example.com/login_refresh",
}

• The initialize process should work normally.
  Note: You can combine buildtime and runtime configuration

Note: Related information FWG Issue

Merge checklist:

• Consider running your code modifications in the included example app within frontend-platform. This can be done by running npm start and opening http://localhost:8080/. To test this you can use the API from this PR or use an external tool to mock the API response.
• Consider testing your code modifications in another local micro-frontend using local aliases configured via the module.config.js file in frontend-build. To test this you can use the API from this PR or use an external tool to mock the API response.
• Gather some consensus on the approach

Post merge:

• After the build finishes for the merged commit, verify the new release has been pushed to NPM.

[openedx-webhooks]

Thanks for the pull request, @dcoa! Please note that it may take us up to several weeks or months to complete a review and merge your PR.

Feel free to add as much of the following information to the ticket as you can:

• supporting documentation
• Open edX discussion forum threads
• timeline information ("this must be merged by XX date", and why that is)
• partner information ("this is a course on edx.org")
• any other information that can help Product understand the context for the PR

All technical communication about the code itself will be done via the GitHub pull request interface. As a reminder, our process documentation is here.

Please let us know once your PR is ready for our review and all tests are green.

[natabene]

@dcoa Thank you for your contribution.

[dcoa]

Hi @natabene this PR is ready for review.

[codecov]

Codecov Report

Merging #335 (b03756d) into master (7c9ace2) will increase coverage by 0.71%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #335      +/-   ##
==========================================
+ Coverage   80.53%   81.24%   +0.71%     
==========================================
  Files          38       38              
  Lines         904      917      +13     
  Branches      169      170       +1     
==========================================
+ Hits          728      745      +17     
+ Misses        164      160       -4     
  Partials       12       12              

Impacted Files	Coverage Δ
src/config.js	54.54% <ø> (+18.18%)	⬆️
src/initialize.js	98.46% <100.00%> (+0.38%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7c9ace2...b03756d. Read the comment docs.

[MaferMazu]

I think this should be on your radar @arbrandes

[dcoa]

@natabene could you help me re-run the test, please?

[dcoa]

Hi, @davidjoy @adamstankiewicz I'm working on changes to make it possible to read the response of the API to configure frontend applications at runtime, I hope you can check this pr and give us feedback 🙏

I have this openedx/frontend-app-account#603 too to make it possible to change the favicon and the site name in the title tag, could you check it?

[davidjoy]

Still looking and don't have a lot of time today, but wanted to give some early feedback! Will be able to look more closely on Monday.

[davidjoy]

I think I'd suggest moving this if statement logic into the default config handler. This logic here would continue to just say await handlers.config(); and we would optionally call the runtimeConfig function if MFE_CONFIG_API_URL exists. That way we enable folks to continue to override all of our default config handling.

Note that currently the config handler is set to noOp, so we'll just need to create a new one similar to auth, analytics, or initError. Let me know if this doesn't make sense!

[dcoa]

I consider this, but many applications have the override handler to marge additional values for that specific MFE (account example), which make even if you have MFE_CONFIG_API_URL don't call the API.

That's why I put it there because you can set that additional values with the API or set by env file.

May be I could move the if into runtimeConfig and call like:

    await handlers.config(); 
    await runtimeConfig(); 

What do you think?

[davidjoy]

Ah, that makes sense. Yeah, how about the version you suggested. That way we preserve any overrides and then layer in the runtime config after. This sounds good:

await handlers.config(); 
await runtimeConfig();

[davidjoy]

I think we should let the MFE keep its build-time configuration rather than using setConfig here. I think it'd be more correct to leave all the build-time config values in there, rather than removing everything but BASE_URL. The way this is now, all the values will start returning undefined instead of whatever's in the build-time config, which will likely be reasonable fallbacks in many cases.

[dcoa]

I agree, I can remove the setConfig and allow the use of default build-time values when the API fails.

[davidjoy]

I think this value needs to be added in a few more places. As a way to discover places it should appear, I tried searching for LOGO_TRADEMARK_URL above and noted that config values in this file are also set in:

• .env.test
• .env.development
• setupTest.js

Basically, it needs to be defaulted in those files for completeness sake.

[dcoa]

I could add the key without value by default because is optional :)