Render multiple Remix apps simultaneously

[estevaolucas]

Hello Remix team,

In our journey towards adopting a micro-frontend architecture through single-spa and React, we've made significant strides and successes using React Router. With the recent introduction of Spa Mode, our interest peaked in leveraging Remix's capabilities to enhance our apps further.

One of our latest explorations involves integrating Remix into our micro-frontend ecosystem. I've successfully created an MFE using Remix, bypassing the need for single-spa + SystemJS format, which is :chefkiss:. Our implementation allows assets to be served correctly from the MFE's domain by prefixing a base URL in the HTML generated by entry.server. Workaround, thus it'd be great if we could prefix assets via Vite's base and also be able to support SSR's loader (loader's request will be made from callee/host's domain and not MFE's one. But these are considerations for another discussion.

Our current challenge lies in the limitation of not being able to render multiple Remix applications simultaneously within the same DOM/window. For instance, consider a scenario in our non-React application that mounts a Remix MFE from Team A, and upon user interaction, a modal hosted in another Remix MFE by Team B is supposed to show up. The utilization of global/window variables by Remix, such as __remixContext, __remixManifest, and the __hmr variable in development mode, hinders the simultaneous rendering of multiple Remix apps due to global variable collisions.

This brings us to a couple of questions for the Remix team:

1. What modifications or architectural changes would be necessary to support the rendering of multiple Remix apps within the same DOM/window environment? Would namespacing the global variables (e.g., prefixing them with an app name defined in Vite's config, like window.myAppNameFromViteConfig.__remixContext) be a viable solution?
2. Is there an interest within the Remix team in exploring and supporting such functionality?

The ability to seamlessly integrate multiple Remix-based micro-frontends would significantly bolster our architecture and development workflow. If Remix is open to this idea, I am eager to contribute towards making it a reality, especially with some initial guidance on the expected implementation approach.

Please let me know if you guys need more info.

Looking forward to your insights and suggestions.

[tomerzcod7]

Hey @estevaolucas. We are facing the same challenge (thinking about working with Remix SPA mode in a single-spa MFE architecture). Have you had any luck with your issues?

[estevaolucas]

Hey @tomerzcod7 I haven't found the solution for that! But I believe, for RR v7 + Fog of War we can probably have a remix federated app without having to rely on Single Spa #1989

[veej]

We're endeavoring to accomplish the same using a Microfrontend architecture based on NGINX SSI to assemble the final HTML page. It would be great if we could utilize multiple Remix-based apps to develop the individual pieces that NGINX will stitch together. However, we faced the same issues with globals/window, so we're currently developing the single pieces implementing the SSR/data fetching manually, without leveraging on Remix.

My understanding is that FoW will still rely on a global window.__remixManifest.routes to work, so I'm afraid it won't solve the issue completely.

[brettburley]

We further a proof of concept using Remix with both rendering more than one Remix app on a single page via a proxy server that merged the SSR output, and a proof of concept of Remix as a single-spa application, and had to make a handful of changes to make these compatible.

In both of these, the root.tsx was modified so that only a top-level div was being rendered (rather than the entire html subtree), and entry.client.tsx was modified accordingly to hydrate at that root div.

Multiple Remix apps on a single page
In this architecture, we assumed that apps would be mounted initially, and remain mounted for the lifecycle of the page. The primary issue we found here was with the global variables conflicting, as suggested in this thread. There's also an issue of window history coordination, since each router instance is independent. Natively, the individual apps don't know when the page has transitioned if another app initiated the transition since the router doesn't listen to pushState events (since it assumes its own instance originates all pushState/replaceState page transitions). Single-spa has a solution for this, which I assume would also work in this architecture to keep the routers coordinated: https://single-spa.js.org/docs/api/#popstateevent

The window global variables needed to be scoped, as suggested in this thread. Specifically, Remix in local dev relies on: __remixRouteModules, __remixManifest, __remixRevalidation. There are also __hmr__ and __vite_plugin_react_preamble_installed__ which we prefixed, but we didn't test to see whether these conflict or not at runtime. The proof of concept ran separate builds of Remix so that we could hardcode different names for these window variables, as it isn't trivial to add the app name or other prefixing to these since they're used throughout the Remix source, and some of the usages are in static files that don't necessarily have the app/vite plugin config easily accessible.

Remix app as a single-spa application
This architecture is subtly different than the former in that I think there is an alternative for the window globals if you assume that only one Remix application is mounted at a time, and it requires applications to be mounted and unmounted as they become active and inactive.

The global variables in this architecture can be removed off the window scope on unmount and restored on application mount so that multiple Remix applications can work independently as long as only one Remix application is mounted at a time.

However, we found the challenge here to be in mounting applications a second time. The issue here was primarily caused by module-level variables retaining state across multiple application mounts. In particular, we had to reset this isHydrated variable in

remix/packages/remix-react/components.tsx

Line 693 in ede2012

let isHydrated = false;

across mounts, as well as re-create the router instance that is retained in https://github.com/remix-run/remix/blob/main/packages/remix-react/browser.tsx#L62. Since javascript code can't be unloaded, we had to patch methods to reset these fields.

Our findings so far suggest that for Remix to work well in a multi-Remix app environment, both the global window variables as well as the re-mountability (i.e. the ability to destroy an app and re-mount it) of Remix would need to be improved.