2024-11-21 Frontend Working Group Meeting Notes: Modules as Plugins, Lazy Loading

Date, time, location

One, maybe two topics to be presented or discussed in depth in the upcoming meeting.

The group discussed the proposal to make existing frontend modules behave as plugins.
Implications of this decision:
- If modules are treated as plugins, it simplifies how they are loaded and configured.
- If they remain separate, an alternate system will be needed, adding complexity.

Clarifications on Lazy Loading:
- Developers should still use React Lazy and import dynamically as needed.
- Module Federation handles loading separate deployments dynamically but does not replace lazy loading in React.
- Each module has a remoteEntry.js file, which acts as a manifest for the module.
- Without additional hints, every module would have to be loaded at startup, leading to unnecessary requests.
Key Challenge:
- Potential increase in network requests (e.g., 12 modules would require 24+ requests).
- Solution: Implementing hints in the site configuration to defer loading modules only when needed.

Tutor Use Case:
- The goal is to allow Tutor deployments to serve modules efficiently, possibly using local file storage or external hosting.
- Reducing rebuild times is a priority, as Tutor users currently rebuild entire images for frontend updates.
- Docker is currently used as a distribution mechanism but may not be the ideal long-term solution.
Potential Deployment Strategies:
- Allow Tutor to prepackage modules instead of deploying them individually.
- Use a CDN to serve modules, reducing the need for Docker-based distribution.
- Ensure flexibility so that users can choose whether to federate modules or bundle them at build time.

Caching & Invalidation:
- How often should federated modules be reloaded?
- Can React Query-style caching help manage module updates efficiently?
Defining Plugin Hints:
- Can operators manually define "hints" to load modules only when needed?
- Should there be a default configuration that optimizes module loading automatically?
Ensuring Flexibility:
- The system must support both modular federated deployments and single-bundle approaches for different use cases.
- The goal is to maintain performance without sacrificing ease of deployment.

The discussion will continue in a follow-up meeting later the same day.
No immediate concerns about performance, but further work is needed on cache invalidation & module self-loading.
The group will refine how hints, caching, and self-configuring MFs should work.