Consider preloading Config API request in all MFEs

Context

• We added runtime configuration to frontend-platform, backed by a new LMS API.
• We made tutor-mfe use runtime configuration by default, allowing us to host a pre-built tutor-mfe image (since config values no longer needed to be build into the image).
• I was worried that the extra init-blocking API request (to the Config API) would noticeably slow down page load, so I proposed pre-loading the Config API request in index.html.
  • I decided not to merge that, because I realized that that the Config API response is cached in local storage by frontend-platform with a five-minute timeout. So, the Config API will still block the MFE rendering the first time it is loaded, but subsequent loads within a five-minute window would not hit the Config API. Given this, the extra complexity of pre-loading may not be necessary; in fact, it could result in additional requests, since the pre-loading would occur whether or not the Config API response is cached in local storage.

Acceptance

Once the runtime MFE Config API is used by a provider in production, ask that provider whether there is a noticeable slow-down on MFE page loads due to the API.

• If there is, then re-open and merge the pre-loading proposal for the account MFE.
  • and open & merge identical pull requests for all other MFEs.
  • Also, add this change to the frontend template app.

Start by reviewing the Config API caching references in frontend-platform's src/initialize.js and src/auth/LocalForageCache.js, then inspect the preloading proposal in frontend-app-account PR 632. First confirm with a provider whether runtime configuration noticeably slows MFE loads; if it does, the account proposal, equivalent changes in other MFEs, and frontend-template-application updates are the expected scope.