Micro frontend architecture using federated Remix apps

[adrienbaron]

Hey there 👋!

I've been exploring how to get federated Remix apps working.

Edit: ⚠️ Disclaimer: Seeing the term "federated", you might instantly think of Module Federation.
This is not what I'm advocating for here. Instead, I'm using federated to mean "Multiple Remix app deployed independently but acting as one", not taking into account whether it uses Module Federation under the hood.
My current POC doesn't use Module Federation at all.

I'm starting this discussion to try and get early feedback and input on changes that might be needed in Remix to get this to work.

What I think we want to achieve

From a high level perspective, I think we'd like to get one deployed Remix host serving multiple independently deployed Remix remotes.

Each remote would contribute some routes to the resulting Remix app. The resulting user experience should be indistinguishable from a single Remix app being deployed to a domain.

This means:

• Actions, Loaders and ErrorBoundaries behave as if all the route are from the same app
• SSR and client side navigation works as expected

In the example below, remote A and remote B are independently deployed from the host and contribute /checkout and /account respectively:

Why do we want this?

For large organisation, there is a big benefit to have independent codebase.

For example at the company I work at (Cazoo), each team own a vertical piece of the domain (Search, Checkout, Consumer Financing...). Each team currently deploy their own independent Next.js app to a shared AWS API Gateway.

✅ This is nice because team can work and deploy independently.
❌ However, this comes at a cost: each time a user cross a domain boundary, they are basically jumping to a complete different app.

This approach would allow companies like ours to keep teams independent, while having a single unified app at runtime 🎉!

General idea (How the POC works)

In my POC the way I went about is as follows:

• host is a deployed Remix app (using express), all server side code runs there
• remotes are bundled Remix apps, they do not need to have runtimes

Getting SSR working

1. At runtime, host will load all remotes build/index.js dynamically.
2. It then gets their ServerBuild export, and merge the routes with its own ServerBuild.

We now have a single ServerBuild and from Remix point of view there is no difference if it had been bundled together: Success 🎉!

ℹ️ For simplicity lets not think now about things like strategies for refreshing those bundle in long-lived servers, or how to load those bundles over the network.

Getting client side working

For client side we need a few things:

1. The manifest.js file needs to be dynamic as it needs to contain the merged routes.
2. Path to client remote bundles in the manifest need to point to the actual files
3. Host needs to provide its version of React and @remix-run/react to the remote client bundles.

1. manifest.js

I've simply added an endpoint to the host express app that returns the merged manifest from the ServerBuild.

2. Client side bundles

I've made the express also serve the public folder from the remote.

3. Providing React version dynamically

That was the hardest bit (so far 😅).
Up to here, I didn't need to do a single change to Remix to get things working. But this required some change to the build system.

I have forked Remix and added this commit.

Let's go through what it does together:

1. Declare a new isRemixMicroFrontend option for the config that can be host or client
2. If you're a host, we inject a shim in the client bundle that will expose the following dependencies on window.__remixDependencies:
   • react
   • react-dom
   • @remix-run/react
3. If you're a client, we use a ESBuild plugin to consume the exposed dependencies from window.__remixDependencies.
   • This works by replacing the module implementation (for example react) by another one that export the same module exports, but coming from the object on window.__remixDependencies["react"]

...Anndd that's it 🎉.

Remote bundle now don't include those three dependencies anymore, and just use the ones exposed by the host.
This means you know have full client side navigation, Remix hooks just work out of the box etc...

ℹ️ There are a few caveat to this approach:

🤔 Exposed modules in the host cannot be tree-shaken (we don't know what remotes will need at runtime).
➡️ This might be ok for large applications though, which are our target anyway 😅.

🤔 React and Remix in the host must be runtime compatible with remotes
➡️ As long as host and remotes are in the same major version this should be OK ✅.

Where I want to go next

Finding the right place for fetching and merging ServerBuild

My POC is well and good, but it requires a lot of faff outside of Remix to fetch and merge ServerBuild.
This is a problem because even though the Express Remix adapter exposes this require("./build") call, that's not the case for all adapters.
So I want to find the correct place to handle that logic.
Looking at Remix source, I can see that it's adapters usually work this way:

• They do some kind of logic to require("./build") and some platform specific faff.
• They then call createRequestHandler to get a "pure" Remix request handler.

I think it would probably be quite bad if every adapter needs to have some logic to handle this.

So here what I'm currently thinking:

What if createRequestHandler does the work?

This would mean it would work automatically no matter the adapter, and for future adapters too 👌.

So what would it entail?

It would fetch and merge remotes ServerBuild

First, we would add a new type of ServerBuild with exposes an array of RemoteBuildFetcher.
Those remoteBuildsFetchers could be provided in a .server file from the host. They abstract away the "how" we get those ServerBuild over the network.

// This is an example, we'd probably have some kind of type union instead
export interface ServerBuildMicroFrontendHost extends ServerBuild {
  isRemixMicroFrontend: "host";
  remoteBuildsFetchers: RemoteBuildFetcher[];
}

type RemoteBuildFetcher = () => Promise<ServerBuild>;

When createRequestHandler get this type of build, it calls each fetcher, merge the ServerBuild and use those to serve the app.
To overcome the fact that createRequestHandler is not async, my thinking was that if the handler gets a request while remote ServerBuild are still loading it would just stall it until everything is loaded.

It would serve /manifest.js

As the request handler is in control of the whole routing, it could serve the /manifest.js route dynamically based on the merged manifest it will have.

🙇‍♂️ What do I need from you?

Feedback mostly!

• What do you think about this?
• What do you think is missing, should change?
• Are you OK to start seeing PR from me implementing that pattern?

🎉🎉 Thank you for reading me till the end! 🎉🎉

I know this is quite a massive explanation, but I feel like the actual changes needed in Remix are quite minimal for all the cool application it could unlock.

Side note: I'd like to thank everyone that has worked on writing this codebase. This was super easy to pickup and work on ❤️!

[mjackson]

Hi @adrienbaron, thank you for your thoughtful and detailed comments here!

Your explanation mostly makes sense to me, but I will defer to @jacob-ebey from our team who has worked extensively with module federation in webpack. He mentioned recently that he has some ideas on how we can address some of the same concerns that MF does but perhaps slightly differently.

[adrienbaron]

Thank you for the prompt reply @mjackson 🤩 !

For now I hadn't thought of using Module Federation for this ☺️ and just share the "base" app dependencies that every Remix app has (by simply exposing them from the host for the remotes to consume).
This is the approach we've taken for MFE dependencies at Cazoo (If you're curious, I've documented it here).

If users need more, I thought of maybe exposing some option in remix.config to let them decide on other libraries the host should expose (for example styled-component if it's used throughout the company).

While I don't think Module Federation is a bad idea, I don't think it's worth it in most apps.
Teams don't necessarily use the same 3rd party library (or compatible versions) and it adds a great amount of complexity (IMO) compared to the potential gains.
The fact that Remix comes with "battery included" too, means most teams will probably use a minimum amount of 3rd party (no Redux, SWR etc...), so there is even less incentive for dynamically sharing every dependency.

I'm far from an expert on it though, and I'm happy to get my mind changed 👍 !

[mjackson]

Ah, thanks for the clarification @adrienbaron. I'm only vaguely familiar with the goals of module federation, but what you were describing sounded kind of similar.

Wouldn't micro frontends be more like using completely different libraries on different pages? e.g. React on one page, and jQuery on another?

[adrienbaron]

No worries I should probably avoid the term "federated" as it's rather loaded these days 😅.

Micro frontend is a very large topic and there is a lot of ways to build them.
My definition of it is: "independently deployed front end apps that form a single cohesive experience at runtime."
In essence, even iframe can be considered micro frontends 😅.

The key here is that being independently deployed is the real value of MFE IMO. It works really well in concert with a micro service backend architecture as it lets teams own and deploy the whole vertical independently (like at Cazoo 😉).

There are some definition that state that being tech stack agnostic is a requirement for MFE but other people (like Ruben Casas and myself) think it's an anti pattern:

• it's bad for performance
• it's risky (libraries might steps on each other toes)
• it splits your engineering teams in jQuery VS React dev for example

So in the case of what I'm proposing, it's still a MFE architecture (IMO), but with a unified stack (Remix), and just the common dependencies shared.

I like to see it as quite a pragmatic approach:
Give less freedom to teams (everyone uses Remix), and share less dependencies at runtime (might get more duplication over the network), in exchange for being more straightforward to implement and easier to manage 👍.
Most importantly it still retains the main value for the organisation which is team independence and ownership 😊👍.

[aplassen]

The key here is that being independently deployed is the real value of MFE IMO.

This is so true in a multi-team organisation. Having to build a larger app for every change across multiple teams is a daring endeavour (even if the builds are fast) 👍

[ScriptedAlchemy]

Id suggest a slightly altered approach here, if its possible.

Instead of a manifest.js -> id look at Jacobs work on ESbuild and module federation interop.

If we are going to bring module federation to more frameworks and build chains, we should conform to a single API to allow for interoperability between toolchains.

The get and init API from webpack has been pretty solid across vite and rollup already.

{
get:(request)=>import(request),
init:(scope)=> {assignExternalDepsToInternalGraph}
}

init is used to share dependencies between host and remote. Init runs once per remote and is the first thing called.

After init. Any imports() are called via get()

window.remote.get('./page').then(factory=>factory()).then((module)=>{
module.default() // or whatever.
})
is the same as import(remote/page)

[ScriptedAlchemy]

I'll check on Monday. Repo should be up soon.
We need to pull it out of angular as it was originally built for angulars new esbuild experiment. But we plan to make MF agnostic so probably within this year MF will with with all build tools

[cliffordfajardo]

@ScriptedAlchemy
@pcattori from the Remix team - has a draft PR on a potentially new Remix feature "Compiler Interfaces" which may allow webpack to be used with Remix in the future
Thought i'd share since you might have thoughts especially since you're deep in the frontend compiler space

in the more immediate future, this will allow people to build esbuild plugins without extending remix core
refactor(@remix-run/dev): compiler interfaces #4291

[jrestall]

@cliffordfajardo https://github.com/pcattori/remix-byoc-example/tree/implement_module_federation 👀

Excited to see this coming together!

[ScriptedAlchemy]

Yeah I helped get byoc working with module federation:)

It's compatible we already tested it.

[AndrewOttavianoAbb]

Would love to see MFEs as a native feature of remix!

[alxc]

adrienbaron Take a looke at https://github.com/namecheap/ilc

[ScriptedAlchemy]

This works, but depends on infrastructure overhead - nothing wrong with it but i prefer not to have to go down the traditionally complex route of infrastructure

[sirugh]

I'm quite new here, but I was wondering whether you solved for nested routing within your POC, or if your POC is purely focused on a route based MFE approach.

I've yet to watch your recent talk @adrienbaron but I plan to, so you may have addressed it there.

[adrienbaron]

Hi @sirugh !

Basically with this approach the "host" loads the remote bundles and then merge the route definitions to its own (see here: https://github.com/adrienbaron/remix-federation-playground/blob/main/remix-host/server/index.js)

This does actually work for nested routes, but currently all parent routes need to exist in the remote too (even if empty).
Basically what's missing is a clean "merge" algorithm but it shouldn't be too hard to implement and then this approach would just work no matter the route layout 😊.

[chris-kruining]

I would love to see this become a first-party feature. I've recently learned a bit about module federation in angular (yep, we are stuck in angular at my job). and it basically sounded like iframes without the downsides of iframes. so this would be super cool to have in Remix!

[cliffordfajardo]

@adrienbaron gave video talk on Microfrontends with Remix
Video: Scaling Up with Remix and Micro Frontends

@ScriptedAlchemy (creator of module federation)- also gave a talk on the powers of module federation, which is tangentially related to microfrontend:
https://www.infoq.com/presentations/module-federation/

@ScriptedAlchemy getting us pumped with this tweet:

If I can conjure up the bandwidth to create a federated remix app runnin on edge networks, would that be of interest? - Tweet thread

[Tom-Avent]

Hi, I'm looking to write a web application which module federation would be a good fit for. Ideally I'd like to use Remix and was wondering if there had been any further progress or discussions on Remix supporting MF? This thread seemed like the best place to ask given all the relevant comments, but can shift this to somewhere more appropriate if needed!

[ScriptedAlchemy]

If you like remix but need a integrated MFE solution. Then modernjs is about to drop a big integration enhancement. Looking at its source and chatting with Jacob, modernjs is definitely heavy inspired by remix. Looks very familiar. That said. Remix should practically work if you swap in webpack or rspack. I see Jacob regularly and we speak of federation. I'm pretty sure he has a repo demonstrating it somewhere. Jacob was a major proponent in federation enhancements in next.js - I'm almost certain he'd have a POC somewhere haha

[chrispcode]

Yes, but here is the kicker - Why would I use something that looks like remix, in a world where remix exists. Why isn't ModernJS just a Vite plugin that allows use of Module Federation? Or vice versa, why isn't Remix compatible with rspack and/or webpack?

[chrispcode]

Also, why do you have first class support for nextjs, when you are part of a team, which has a meta framework based on react-router and looks identical to remix?

[jrestall]

I did some experimentation using @softarc/native-federation-core and the new vite compiler at jrestall/remix-federation.

It successfully combines multiple independently deployed remix sites together at runtime by dynamically fetching remix's route manifest.json files as needed. It allows remix sites to expose react components and code for use in others at runtime. It could also be used to load any shared JavaScript code.

The core mechanism is that when the user navigates to a splat route like /blog/* it will federate with the remote blog app to fetch all its routes and then router.revalidate() to reload and rerender the page client-side using the new routes that then override the splat route. Any shared deps are handled using import maps so the same router state is maintained. There is a short loading time, but this can be mostly eliminated if remix implements prefetching for clientLoader in the future.

There's a few caveats and areas for future investigation,

• No SSR for the federated routes as haven't investigated a way server-side to fetch html from each of the nested remotes in the document request.
• There's a bug refreshing federated routes due to @softarc/native-federation using relative paths in its import maps.
• Requires use of internal Remix apis such as router._internalSetRoutes.
• Requires a patch to @remix-run/react to enable es-module-shim to load the document script tags.
• Requires patching global.fetch to redirect loader/action requests to the host app where they are then proxied to remotes.

Seems to work pretty well otherwise. Feel free to check it out, critique the approach and/or suggest improvements.

[brendonco]

If I have existing Module Federation(MF) build using webpack. And I want to re-use some of the MicroFrontend in my MF, is it possible to build a Remix and used existing MF build from webpack?