Module Federation Support

[ScriptedAlchemy]

Feature request

@Timer @rauchg @timneutkens In order to stop my "Twitter Driven Development" (still love that quote) I have updated the description of this issue to hopefully help move this challenge forwards.

Is your feature request related to a problem? Please describe.

Support Module Federation ability to share vendor code, like react

Describe the solution you'd like

• We should not use entrypoint based routing, each entrypoint would require react and react-dom to be async imported, or each entrypoint would need to use the import(./bootstrap) method in order to allow webpack to figure out if react exists already or if it needs to go and download the chunk. Ideally, there should be only one entrypoint, then whatever else needs to happen is done so via code splitting and async imports.
• An alternative nice to have would be to make shared: {import:'react',eager:true} work - this would force react to be loaded upfront - however it seems that react is included multiple times in each entrypoint - causing various multiple copies of react issues. If eager worked, I could at least share react and force the remote to always use the hosts copy of react (I think) - this would / should be okay since next mostly requires us to be on a somewhat consistent version of react. Like next 11 will use v17, since all my apps use the latest nextjs, they will be compliment with a v17 version of react.

The bare minimum to get this working client or server-side would be to have some flag that changes how the client entrypoint gets started. If the client.js looked like this https://github.com/module-federation/module-federation-examples/blob/master/bi-directional/app1/src/index.js then there's a high likelihood we could hold up the application until whatever shared modules with static imports were ready before hydration begins.

Current Status

Vercel does not plan to support Module Federation, this discussion can likely be closed.
For those who need it:
https://app.privjs.com/buy/packageDetail?pkg=@module-federation/nextjs-mf (client side)
https://app.privjs.com/buy/packageDetail?pkg=@module-federation/nextjs-ssr (client and server-side support)

Related issue: #6040

[ScriptedAlchemy]

Update on this.

I've found a way to move the async boundary into the webpack runtime. This circumvents limitations of next.js by changing how webpack startup runtime module works.

Replacing the startup module will effectively prevent next from initializing till webpack container negotiations take place.

I only uncovered this today, so it'll take some time to modify and PR webpack.

Too hard

[ScriptedAlchemy]

@rauchg @timneutkens @Timer @sokra I've updated the git issue, please let me know if there's any more information I can provide

[mlstubblefield]

Awesome! We're super excited about utilizing next+module federation to support microfront ends.

And for what it's worth (seems like everyone has a different definition of micro front ends) here's the short definition of what we're wanting to do.

We want to be to deploy our header/footer (layout) as a next app in vercel as well as 3-4 pages as separate next js apps in vercel.

Ideally they're stitched together and client side routing is well supported (hopefully the nextjs libraries are shared between the apps).

[ScriptedAlchemy]

This is more or less what im looking for as well, seamless page routing & component level ownership ☝️

[ScriptedAlchemy]

I've gotten Module Federation and Next routing to work. https://twitter.com/ScriptedAlchemy/status/1402319022331502592?s=20

This works client-side and probably could work server-side with some tweaks.

You'll need a catchall page and the nextjs-mf plugin.

Sample PR: module-federation/module-federation-examples#859

Likely ill move to a switch statement so I can take advantage of the import() syntax over the low-level API

Also will probably use a suspense implementation and if need be, write some utility which will be added to next-mf if a well-rounded solution looks cumbersome

@mlstubblefield ☝️

[ScriptedAlchemy]

As of today, I was able to use just the Module Federation plugin with next js.

It appears that sharing works now, at least when it's in eager mode.

As of my testing today - nextjs supports federation without any workarounds. 🎉

It's almost too good to be true.

I'll perform some deeper tests tomorrow to confirm.

[Darth-Knoppix]

I’m having mixed results getting a good setup with Next.js 11 due to the issues @ScriptedAlchemy describes. Does anyone have an example project using Next.js 11 bi-directional CSR?

[ScriptedAlchemy]

you have to use the next-mf plugin, which pretty much makes a third webpack build

[jonniedarko]

it should be noted next-mf is not freely available - it is a paid plugin !

[ecwyne]

🤔 @jonniedarko
https://www.npmjs.com/package/@module-federation/nextjs-mf

[jonniedarko]

@ecwyne https://github.com/module-federation/nextjs-mf is private repo now and
https://twitter.com/ScriptedAlchemy/status/1418508699891425283
from Zack Jackson @ScriptedAlchemy

Who wants to test the updated nextjs-MF plugin? It’s going to be a paid package but am looking for a few beta testers who will get temporary free access while it’s being tested. DM me

[ScriptedAlchemy]

Yep it's no longer a free plugin sorry fam but time is money 💰 v3 is on a paid registry, v2 is the last open release but doesn't work with newer versions of nextjs

Next keeps breaking our support and keeping the project working for everyone requires non free engineering resources.

All / many MF works moving forward will likely cater to paid packages as the OSS R&D is becoming too expensive.

Times be changing. OSS was good while it lasted but funding is just too low.

Can't invest $50k into a package just for the greater good anymore. Losses have to be recouped

On a side note, funded research has allowed us to crack federated SSR in next.js. For those interested we do have a solid solution, so the model is advancing the ecosystem - despite it being an unpopular opinion.

Either we stop coding all together or we find a way to fund our research 🔬

[alexUXUI]

As an architect at large enterprises, I work with systems at scale which often require distributing code. Module federation perfectly enables the ability to distribute code and I genuinely think Next.js will capture more of the enterprise market with MF support. Let’s make Next.js the react meta framework for enterprise level needs. This could be a massive point of differentiation from solutions like Remix. Thanks a bunch for your consideration.

[lancej1022]

@ScriptedAlchemy did you ever explored if it's possible to use MF with Remix?

Yeah it is. Jacob used to be on my platform team at lulu. Hems at remixx now. He knows MF better than anyone else outside of webpack, together we got MF working on next and in the process he prototyped it on remixx

The trick is you pretty much have a sidecar build (same as next) that's webpack based. So the remote entry and exposed modules go thru webpack. Then you can hook share scope up to ESM modules from esbuild.

Process is near the same for how we make it work in nextjs. Sometime in December we were planning to try and make something out of it.

Spoke with him about it last week actually so this is something we are actively thinking about

@ScriptedAlchemy do you know if there are any plans to add an example of this to the Module Federation examples on GitHub and/or release a plugin to facilitate this?

We already use Module Federation at work but are currently doing client-rendering which has obvious paint points. Ive wanted to move us to Next for some time now, but the ongoing lack of support for Module Federation means we would need to do some drastic reworking of our architecture that just wouldn't be worth it.

If Remix looks winds up with more realistic Module Federation support in the nearer future, then that's ultimately the path for our company to head down.

[ScriptedAlchemy]

Remixx support is possible by using a sidecar build that’s webpack and manually binding the share scope when initializing

[ScriptedAlchemy]

We got remix working on webpack. Probably not much work left to sully support Module Federation on remix now

[balazsorban44]

We appreciate everyone letting us know they’re looking for a solution here. However, we'd like to ask you to reserve comments for additional information to move this discussion forward. If you would like to show your support, please add a 👍 emoji on the initial comment instead. Thank you.

[ScriptedAlchemy]

I've released a closed beta for federated SSR/CSR.

This new plugin pretty much closes the gap between module federation and nextjs.

Some concerns I'll be addressing.

• solved support for require, import from, and import() so now you can load hooks and other things that cannot be async (done)
• Ability to SSR imported chunks like next/dynamic does. (Done)
• bulletproof security when loading federated modules on the server side. I'll be using encryption with salted keys so code has to be decrypted with public keys in order to execute. This will mitigate any domain hijacking or tampering with files that are not from the actual deployed app. (Supported, not documented)
• Looking at adding a preload remote chunks asynchronously when server boots, not blocking the thread but still front loading all possible modules ahead of time. This would prevent any edge cases where a remote updates before a hot reload happens and avoid missing chunk load issues (done)
• Loading streamed code into a isolate using v8 or using wasm. This will prevent prototyping poisoning and global scope access. (Done but not part of the offering)
• Working on a way to hot reload production using a stale while revalidate style so the event loop is not messed with mid execution. (Done)
• Already added publicPath: auto support for the server side
• will be extending module federation interfaces to add some extra capabilities on the server (done)
• Investigating a way to stop exposing remotes on the window, but instead load it into memory in the webpack runtime. This would prevent tampering with the get init api. (Deemed not necessary)
• Will likely stop shipping JS between servers in favor of BinaryAST or other tech. This would mean no parser overhead for a script. (Tech isnt there yet)
• adding support for localRemotes so things like turbo repo can be used without slowing down webpack
• ~~Adding support for partial imports like import(home/${someVar}) ~~
• Investigating the need for a sidecar build on client side, there's a way to share modules from next build and also make next generate a remoteEntry directly, without eager consumption errors. (Proven possible but sticking with reliable sidecars for now)
• added access to federation loading interfaces directly. So dynamic remotes or "module queries" can use the same code that webpack uses when using a static import. (Done)
• Exploring the ability to use a slug route to load pages from other build and SSR them. (Done)
• Solved get server props, ISR, SSG as well
• Performance is substantially faster compared to previous releases. Builds are 3x faster in dev mode.
• Added webpack watch mode so federated modules will rebuild as needed without next triggering a rebuild/HMR

I believe if I solve the security concerns of software streams, there should be no reason vercel cannot implement a total solution for federation.

Stretch goal will be to run next from a Cloudflare worker only. Without SSG or ISR (proven possible, but on hold for now)

This new plugin should effectively bring "first class" support to nextjs as I've already solved all quirks of using federation on next.

If vercel has any concerns about federation beyond what I'm working on - I'd like to hear them. What concerns currently prevent you from supporting CSR? I understand SSR is more tricky but I am addressing those in a performant manner. Blast radius will not be a problem with encryption + true isolates.

Performing load tests, it seems that federated next apps start and respond faster than non federated apps. Not sure how that's possible since streaming software should be slower than on disk reads. Update: its because less needs to be loaded into V8 compile cache during bootup

In the future I'll be exploring "push not pull" for remote modules. That would stop and performance bottlenecks since software updates would be pushed into memory. That would also stop any stability concerns related to network failure since the broadcast would contain a buffer of all updates in its payload. (Possible but found other ways to improve perf)
This would change "software streaming" into a in-memory push. With webswitch technology we created that do the same thing for federated backend platforms.

As always, I'd be happy to collaborate with vercel to solve this feature request once and for all. But I'd need a deeper collaboration effort with vercel to make meaningful progress.

My nextjs solutions are commercial. Which locks out many users from being able to access federation. While I'm happy to collect a lot of money. I'd forgo the financial gains for native support - for the greater good of the community.

[MetinArslanturk]

Hi to you all. Firstly thanks to @ScriptedAlchemy to his effort for Module Federation community.

I also faced with problems when using NextJS app as a container app. You know, I had to give eager option (because sync load of app) then when I call a remote micro app (i.e react), shared modules are loading again.

I followed a different way from your paid library. I used dynamic load technique for my remote library and it seems shared modules are not being fetched again and again now. They are being loaded only once. Also, I implemented full system as framework agnostic so you can use any framework as a remote app (angular, vue, react, svelte...). Also, I moved SSR logic to remote app part so now it can fully support SSR for any framework, too. It seems worked and I wanted to share my solution in here to help community. I wrote a medium blog post with example Github repo link. I told my approach with details.

You can find detailed post in here: https://medium.com/@metinarslanturkk/how-i-implemented-dynamic-loaded-framework-agnostic-microfrontend-app-with-nextjs-and-react-which-620ff3df4298

And this is the example repo link: https://github.com/MetinArslanturk/microfrontend-nextjs-ssr

Maybe, NextJS maintainers can follow a this like dynamic way for a workaround solution least in a minor version update. Everyone will be more happy with a built-in solution of course.

Thanks, Metin

[ScriptedAlchemy]

Next operating in host mode is not the problem. It's that you cannot generate a remote. Next also doesn't not correctly initialize share scope all the time. Using dynamic remotes is the easiest solution since you are circumventing all the boot stuff and do it by hand. This I implementation looks similar to my previous POST based fetch() system, it's reliable but has limitations since we are working with serializeable content only. However dynamic remotes have some other quirks like time of instantiation can cause issues with nested remotes and so on.

For example I can't pass props that contains a function or component.

Network based renders are a good way to stick to ol reliable ESI style patterns but this can create waterfalls if you have cold servers or uncached data.

React 18 does make this easier with its async fetch capabilities and streaming responses.

This also reminded me of different react versions adapter modules which let you independently mount various parts of other apps onto a single app. Giving you a far more agnostic setup since you you have more mount points. So it's a helpful pattern but if you're trying to keep html there while waiting on the frontend to mount, you can get DOM thrashing flicker ( this has been my initial experience ) so getting hydration to work smoothly without tearing took me a few iterations

[MetinArslanturk]

Without a dynamic remote loading, it has problems with shared modules even nextjs is only a host in our tests. It seems, this method worked. NextJS as a remote app was not in our focus area (it does not seem logic in our arch) so this solution ignores it. As i said, NextJS as a host app, still had problems and I solved it with this method completely. Just wanted to share to help same situation people.

--

You are absolutely missing a certain point. This approach's main purpose is being "framework agnostic". Your all worries are seems missing this point. If you are thinking passing a React component to a remote app for i.e. then you already breaking framework agnostic logic. If you are building your system as a real framework agnostic architecture, then this more reliable-robust-isolated solution will be an advantage for you, Because, it already push you to a framework agnostic design in your child components. React 18 stream renders etc completely awesome features. But the point is, this solution is an abstract of frameworks and targets framework agnostic architecture with current technology support situations of NextJS and other frameworks.

There are some preventions to blocking flickering in my detailed article and more will be added. Also, if a micro app has a different react version and it is a strict for that app then it is a generic problem for all micro frontend architectures. This solution not blocks this situation, opens way to handle it.

[ScriptedAlchemy]

Would be nice to see this packed into a set of abstractions that come with hook - integration points for all languages. Do you know a example of a next, react, vue, angular app built in this manner ?

[MetinArslanturk]

single-spa is a little converges this kind a packed solution. But they have a full custom implementation and some points they even don't use Webpack Module Federation.

Stephen Grider has a nice udemy course ( https://www.udemy.com/course/microfrontend-course ) about telling mount function based microfrontend architecture, it can be a good starting point to who wants to follow this pattern.

So, I don't know a ready-to-use packed solution with this pattern, yet.
Maybe it can be a good side project for me in near future 🙂

[Marcelx8]

Chakra-UI Component issues (could relate to other shared dependencies also):

Setup:

• TypeScript
• Module Federation: Next-SSR beta plugin
• Shell app (container) with required Chakra-UI imports, also wrap <Component ... /> with <ChakraProvider >
• UI app - housing the components which get exposed for usage like import('ui/SomeComponent'). This app has all the dependencies shared in its next.config.js
• HomePage app - populated with UI components and whatever else

Issue:
If the HomePage app has Chakra-UI dependencies shared in next.config.js, and you wish to consume a Chakra-UI embedded component from the UI app, it seems to ignore the styling. The component renders, but without any styles applied.

The shared dependencies in the HomePage app IS unnecessary but just adding it as a note to someone who crosses the same bridge.

Maybe I'm doing something wrong?

Also, Components (React.FunctionalComponents) seem to work perfectly with normal import Component from "remote/Component", as well as const Component = dynamic(() => import("remote/Component")) , BUT with a non-React.FunctionComponent, or rather, just some JS function, then only the import doSomething from "remote/something" seems to work. I believe that is possibly a typing issue on my side and to understand the dynamic module import types a bit better. Still working on it.

[ScriptedAlchemy]

Please note this is vercels discussion about adding federation support to next. Not for reporting bugs or federation issues for those implementing my software on next. Please use discussions on module federation examples for implementation details.

[Marcelx8]

Thanks. This can be deleted

[12dkaskar]

Nextjs 12.X.X version support the module federation plugin?

[ScriptedAlchemy]

Update: There will never be official support for Module Federation from Vercel. They believe everything should be available at build time. It will never be supported by Next.js

[BlessYAHU]

Did they really say everything should be available at build time? That's a shame, because we had a few projects that we built with Next.js. The next phase of the project use Module Federation (moving away from the micro-site/portal architecture), and will move away from using Next.js partially due to its lack of Module Federation support(it was just one of a few reasons). I hope this is reconsidered at a later time, and the commercial module sticks around to fill the gap until then.

[ScriptedAlchemy]

Yep

[ScriptedAlchemy]

Commercial module will ALWAYS stick around. There's too many companies, including mine who are heavily dependent on it.

I've also taken steps to have contingencies in place so if I get hit by a bus, doesn't really matter anymore - I partnered with an engineering house who has full access to all my commercial software and helps me maintain it.

Also one of the perks of commercial software. You're paying to ensure it stays supported. Unlike OSS, commercial software can't just be abandoned when the dev moves on to the next shiny thing 😊

There's also the moral obligation, you've paid me and many others have as well. At some point when a project gets large enough - there's a social contract.

This is usually why I'm careful about what I release to the general public, I can only release software I plan to support and maintain for years. Otherwise that damages my reputation and brand. Since it's commercial, that amplifies the obligation to ensure it is looked after.

It'll be supported indefinitely. If there's ever a scenario where my group is unable to maintain it (will never happen) - it'll be automatically open-sourced.

If I develop or release new proprietary tech that makes the existing software seem like a "lite" version - it'll be open sourced or become free.

As it stands today, we do not forsee any changes to any of my software. I've maintained it for nearly 2 years without interruption.

Since its popularity has grown significantly, I've upped the investments into these tools. So it's becoming more supported, not less

[brianespinosa]

Update: There will never be official support for Module Federation from Vercel. They believe everything should be available at build time. It will never be supported by Next.js

@ScriptedAlchemy is there anywhere you can link to or reference where this statement was made by someone at Vercel/Next? I'd love to be able to reference these statements coming from them directly to my teams.

[ScriptedAlchemy]

Okay I've finally managed to enable full support for module federation on Next.js

Without hacky workarounds.

The latest release of nextjs-mf (v4.1.X) includes a /beta directory with new rewritten "NextFederationPlugin"

Still undergoing tests - but everything I've tested so far works. Works just like module federation would on a normal application.

No longer adds multiple build instances, uses a single compiler graph.
So no more build overhead anymore.

Best news is the whole dependency sharing system now works perfectly, so "shared" doesn't cause strange issues or eager issues in next hosts.

Anyways; Federation is now fully supported via nextjs-MF

[corradin]

Hi @ScriptedAlchemy. In the meantime, these kind of posts pop up, which is confusing to me. It doesn't mention any use of the nextjs-mf package, which I interpret as: "it just works out of the box" and makes me skeptical considering all the hard work you have done to make this work with NextJS. Am I missing some context? https://blog.logrocket.com/micro-frontend-react-next-js/

[jasontll]

lol... @corradin, the dude's example doesn't work. If you follow his instruction you'll probably pull your hair out...

[ScriptedAlchemy]

lol... @corradin, the dude's example doesn't work. If you follow his instruction you'll probably pull your hair out...

Module federation examples repo/nextjs if you've purchased the package they all work. If you're installing it from npm, that won't work. It's commercial and on app.privjs.com
Definitely works, last I checked my production site was working. (If you're referring to my packages)

[ScriptedAlchemy]

Hi @ScriptedAlchemy. In the meantime, these kind of posts pop up, which is confusing to me. It doesn't mention any use of the nextjs-mf package, which I interpret as: "it just works out of the box" and makes me skeptical considering all the hard work you have done to make this work with NextJS. Am I missing some context? https://blog.logrocket.com/micro-frontend-react-next-js/

Be aware - the only working solutions are the packages I've authored. There is no alternative.
All next packages are on app.privjs.com
Next-MF@v5 or next-SSR@RC2

If it's not these packages from my registry, module Federation will absolutely not work.

I'm the only supplier of MFP support on Next.js - for better or worse, that's the state of things.

It's been 3 years, my packages still remain to only solution.

Vercel seems to have philosophical differences. They are set on all code should be available at build time.

This will likely not change - as far as I'm aware, next has no intention of supporting any at-runtime dependency sharing system (like MFP)

Don't expect official support, not ever.

[ScriptedAlchemy]

In a shocking turn of events. I’ve released all my proprietary software as open source.

https://twitter.com/scriptedalchemy/status/1567253027312246784?s=46&t=Sa4bhIDZI1i-q2GgYNGQuA

My commercial next.js plugins are back on npm and SSR is supported out the box

[ScriptedAlchemy]

Userbase is about to explode significantly. Hopefully that'll add enough pressure

[wjkawecki]

👏 thanks, that's awesome news

[dragidavid]

Just when I needed it! Thank!

[jakubriedl]

Thank you very much, this makes things so much easier for us to experiment with module federation. Much appreciated.

[ScriptedAlchemy]

If you can afford to, please consider sponsoring me on GitHub. We are now completely dependent on sponsor funding
Ultimately I believe this was the right move for bettering lives of everyone.
✌️💕

[PraveenPeri]

This question is for Vercel team. Does Turbopack fill this gap on module federation?

[ScriptedAlchemy]

No. Monolithic builds only. You can do a monorepo with something like incremental builds, but next will still have to bundle anything it consumes and must redeploy per change.

[ScriptedAlchemy]

Update. We may get federation support in turbo. Still early talks but most encouraging movement I've seen in years.

[VityaSchel]

Still waiting for getServerSideProps support, is there any news?

[raolak]

Whats the difference between nextjs zones vs nextjs module federation.

I have main app and subapps which are hosted seperatly. But main app would use the subapps. Is this usecase possible with nextjs module federation?

[ekatioz]

I just read that the module federation team will likely not support nextjs in the future.
module-federation/core#1183 (comment)
What does that mean for this discussion?

[VityaSchel]

I just read that the module federation team will likely not support nextjs in the future. module-federation/core#1183 (comment) What does that mean for this discussion?

Move to svelte

[ScriptedAlchemy]

We will not support it on a framework that does not want it. Vercel has been showing some increase in movement since I announced that I am killing support. If Vercel decides to support Federation as first-class, I will still kill my integration but will double the resources allocated to supporting Vercel.

The main thing is I can’t do it alone without internal support. I can change my ecosystem for Vercel, but I need the other side to want it to succeed too. Otherwise, I’m fighting a losing battle, and end users get a poor developer experience. Things need to be changed within Next itself—there’s only so much that can be done by rewriting Webpack to work around the issues. At one point, I’d replaced the entire module format and chunk format system. Version 7 was literally like forking Webpack to work around limits imposed by Next. Version 8 was just rewriting federation entirely. It works but fails to meet my expectations of what the user should experience.

I would rather terminate support entirely than knowingly have users experience such degraded integration. If we can come to an agreement, Vercel will receive substantial support and collaboration from my teams. But it requires both my teams and Vercel to align. We hold no anger toward Vercel; we simply cannot expend resources on something that doesn't want the technology.