Feasibility of conditional module federation at development time?

[sschottler]

One challenge with module federation in the docs says:

"It complicates deployment - each micro-frontend/container has to be deployed and available to the clients (usually via Internet)"

https://re-pack.netlify.app/docs/module-federation#challenges

I wonder if it would be possible to avoid this deployment requirement by only doing module federation at development time? So you get the benefits of running a local dev server for the module in development, but in production, the bundled federated modules that would normally be hosted on a CDN would be included with the app (ie not require a network request to load).

I see two possible approaches to accomplishing this:

1. Structure federated modules to also be packages and align the exposes/exports and shared/peerDependencies. Then have a conditional environment babel compilation step that either imports the package export as the entrypoint or a React.lazy(() => Federated.importModule(...)). Where I see that getting complicated is federated modules that reference other federated modules...

2. Another way could be to take the bundled JS files for a federated module intended to be stored on a CDN and store them in the ipa/apk similar to local chunks and have some custom script resolver logic that loads from file system in production instead of a devserverurl. I have not tried that yet and not sure if it would work

Is this an idea worth investigating more if my team pushes back against having to manage CDN servers and additional deployment steps? Or are there some pitfalls that you foresee that I haven't anticipated yet?

[rplotkin]

Bumping this question. I've been digging into this issue, looking both at callstack's OutputPlugin and working to get getFileSystemURL working. The latter gets tripped up and seems unable to resolve local files that aren't included at build time, and extraFiles seems to primarily be targeting js prior to babel. Assets don't appear to get read by getFileSystemURL, so I can't seem to take files from the "local" output of a federated module and place them into the build process of the host.

[RafikiTiki]

One of the main benefits of using Repack and Module Federation is the ability to load Modules dynamically. You'll lose that if you choose to embed Federated Modules into the Host/Super App. Using Module Federation in development ONLY doesn't bring much value, at least to me, and is not something I would recommend. It is, however, possible.

I implemented a similar approach to the second point from the original question. It was only used as a temporary workaround while the CDN/Catalog Server was being developed in parallel and it was stopped being used after the CDN implementation was finished. The approach was a little bit more tricky than what you've described but it was mainly because of the complex brownfield nature of the project.

Off the top of my head that's what we did:

• compile bundles of the desired features/mini apps
• embed them in the Host App following platform specifc way, just like any other native asset (font etc). For iOS you have to copy them and add to specific targets for example.
• configure ScriptManager resolver so that it will use devserver for development and local files in Prod. You'll have to get the filesystem URL of the scripts and pass them instead of CDN urls to the ScriptManager resolver. You can try using getFileSystemURL, but depending on your setup it might not work. In my case I had to implement a custom Native Module responsible for finding the proper files URLs of the bundles, but also set the absolute flag to true in the resolver configuration.

Given all these steps you'll still have to have some kind of "release" process and, when a Federated Module gets updated – compile and copy the bundles (similar process to uploading the bundles do CDN) and then go through normal App Store review (that would not be necessary in normal, remote Module Federaton approach because Over-The-Air updates are possible).

[thymikee]

Wouldn't using experimental lazy bundling from Metro answer your case then? It's available in this release: https://github.com/facebook/metro/releases/tag/v0.76.3 which is included with the latest v0.72 RC of React Native

[jbroma]

Hi @sschottler, @rplotkin

I've recently created a quick POC of bundled federated modules from our super-app-showcase which you can explore on this branch:

local-module-federation-poc

This POC includes building production bundles of the federated modules in the monorepo and then bundling them just as local chunks into the app contents. To get it to work, before running the host app you need to prebuild the mini-apps using yarn bundle:ios in the root of the repository, and then build the app for iOS as usual. There is a Xcode script attached to help with moving the assets from their respective build directories into the app contents.

Note that instead of using Script.getFilesystemURL we are using custom one to handle the scenario of container bundles. Also, as some mini-apps are exposing the same component and end up producing bundles that have the exact same names, I needed to modify chunkFilename in every federated module webpack.config to include the name of that module to differentiate them from each other.

[github-actions[bot]]

This issue has been marked as stale because it has been inactive for 30 days. Please update this issue or it will be automatically closed in 14 days.

[zackarychapple]

FYI when it comes to module federation during development time and dynamic switching. This is something that Zephyr Cloud will enable.

[github-actions[bot]]

This issue has been marked as stale because it has been inactive for 30 days. Please update this issue or it will be automatically closed in 14 days.

[github-actions[bot]]

This issue has been automatically closed because it has been inactive for more than 14 days. Please reopen if you want to add more context.

[mlakmal]

Hi @sschottler, @rplotkin

I've recently created a quick POC of bundled federated modules from our super-app-showcase which you can explore on this branch:

local-module-federation-poc

This POC includes building production bundles of the federated modules in the monorepo and then bundling them just as local chunks into the app contents. To get it to work, before running the host app you need to prebuild the mini-apps using yarn bundle:ios in the root of the repository, and then build the app for iOS as usual. There is a Xcode script attached to help with moving the assets from their respective build directories into the app contents.

Note that instead of using Script.getFilesystemURL we are using custom one to handle the scenario of container bundles. Also, as some mini-apps are exposing the same component and end up producing bundles that have the exact same names, I needed to modify chunkFilename in every federated module webpack.config to include the name of that module to differentiate them from each other.

@jbroma is it possible to use this approach combined with remote bundles?

ex: we include remote bundles with the application when we release it to app store (this will avoid initial network hit or allow us to serve application packaged bundle when network latency is identified), then we allow pushing updates to those bundles. (similar to how codepush works for main bundle)