Consider preloading Config API request in all MFEs

[kdmccormick]

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.

[kdmccormick]

FYI @arbrandes -- Here's one for the backlog. It's blocked until someone is using the runtime MFE Config API in production and is willing to help up gauge the performance impact.