Microfrontend Architecture with Module Federation — is it supported or feasible with Refine?

[giorgiPapava]

Microfrontend Architecture with Module Federation — is it supported or feasible with Refine?

Context

Hey Refine team and community 👋

I'm currently running a centralized admin panel built with Refine that acts as a single application serving multiple gateways/domains (think multi-tenant or multi-product setup). As our team and product surface area grows, the monolithic frontend is becoming harder to scale — both in terms of development velocity and deployment independence.

I'm exploring moving toward a microfrontend architecture, and I'd love to understand how feasible this is within the Refine ecosystem.

---

What I'm Trying to Achieve

Essentially, a microservices-like model on the frontend:

• Each "gateway" or product area lives in its own independently deployable app
• A shell/host application composes them together at runtime
• Teams can work, deploy, and scale their frontend slice independently
• Shared UI, auth context, data providers, and Refine core are consumed from a shared remote

---

Approaches I'm Considering

1. Webpack Module Federation (most mature)

• Host app exposes <Refine> wrapper, auth provider, and data providers as remotes
• Each micro-app registers its own routes/resources and is lazy-loaded into the shell
• Challenge: Refine's <Refine> context — can it be shared cleanly across remotes without duplication or context mismatch?

2. Vite + vite-plugin-federation

• Similar concept but Vite-native
• Wondering about HMR stability and SSR compatibility if we ever move to Next.js

3. Native Module Federation (Webpack 5 / Rspack)

• Rspack's Module Federation 2.0 has improved dynamic remotes — worth exploring?

---

Specific Questions

1. Is there anything in Refine's architecture (context providers, router integration, resource registry) that would break or cause issues when split across module federation remotes?

2. Can the <Refine> provider be hosted in the shell and consumed by micro-apps, or does each remote need its own instance?

3. Has anyone in the community successfully implemented this pattern with Refine? Any gotchas around:

   • Auth context sharing across remotes
   • Shared notificationProvider / i18nProvider
   • Avoiding duplicate React instances (the classic MFE pitfall)

4. Would Refine consider official guidance or a recipe for microfrontend setups? This feels like an increasingly common architecture request as Refine gets adopted at scale.

---

Current Setup

Framework	Refine core + Ant Design
Bundler	React + Vite
Data layer	REST & GraphQL data providers
Current structure	Single deployed app serving 3+ gateways via route-based separation

---

Any input from the core team or community members who've gone down this road would be hugely appreciated.
Happy to share more details or contribute back if we get something working! 🙌

---

Labels: question · discussion · architecture · enhancement

[sueun-dev]

Hey, not from the Refine team but I've explored this pattern and can share what actually works (and what doesn't).

Short answer

Yes, this is feasible — the key is that <Refine> must live only in the shell, and all @refinedev/* packages (plus React) must be declared as singletons in your module federation shared config. Remotes just consume hooks — they never instantiate their own <Refine>.

---

1. Refine's architecture with module federation

Under the hood, <Refine> is a composite of React Contexts stacked together — DataContext, AuthContext, RouterContext, NotificationContext, LiveContext, etc. This is actually good news for MFE: React Contexts work across module federation boundaries as long as there's only one React instance.

The critical webpack config in your shell and every remote:

// webpack.config.js (both shell and remotes)
new ModuleFederationPlugin({
  shared: {
    react: { singleton: true, requiredVersion: deps.react },
    'react-dom': { singleton: true, requiredVersion: deps['react-dom'] },
    '@refinedev/core': { singleton: true, requiredVersion: deps['@refinedev/core'] },
    '@refinedev/antd': { singleton: true, requiredVersion: deps['@refinedev/antd'] },
    // add any other @refinedev/* packages you use
  },
})

Without singleton: true on React, you'll get two React trees and context won't cross the boundary. This is the #1 gotcha.

2. Hosting <Refine> in the shell

Yes, put <Refine> in the shell. Remotes then just use hooks directly:

// Shell (host) — index.tsx
import { Refine } from '@refinedev/core';

export default function App() {
  return (
    <Refine
      dataProvider={dataProvider}
      authProvider={authProvider}
      routerProvider={routerProvider}
      notificationProvider={notificationProvider}
      resources={[
        // option A: centralize all resources here
        { name: 'orders', list: '/orders' },
        { name: 'products', list: '/products' },
      ]}
    >
      <RemoteApp1 />
      <RemoteApp2 />
    </Refine>
  );
}

// Remote app — can use all Refine hooks normally
import { useList, useGetIdentity } from '@refinedev/core';

export function OrdersList() {
  const { data } = useList({ resource: 'orders' });
  const { data: identity } = useGetIdentity();
  // auth context, data provider, notifications — all just work
  return ...;
}

3. The resource registration problem

This is where it gets tricky. Resources are passed as a prop to <Refine> at init time, so remotes can't self-register. The patterns I've seen work:

Option A: Centralize resources in shell (simplest)
All resource definitions live in the shell. Remotes just render the CRUD pages. Fine if you can tolerate that coupling.

Option B: Remote manifest + shell aggregation
Each remote exports a resource manifest, and the shell imports and combines them at startup:

// remote-orders/manifest.ts (exported via module federation)
export const resources = [
  { name: 'orders', list: '/orders', create: '/orders/create' },
];

// shell — dynamically import before mounting
import { resources as orderResources } from 'remote_orders/manifest';
import { resources as productResources } from 'remote_products/manifest';

<Refine resources={[...orderResources, ...productResources]} />

This keeps resource definitions co-located with the remote team that owns them, while the shell just aggregates.

4. Auth, notifications, i18n

Since these providers are all in the shell's <Refine> instance, they're automatically shared — any remote using useGetIdentity(), useNotification(), or useTranslation() gets the same instance. No extra work needed once the singleton config is correct.

Logout is the one thing to test carefully: useLogout() in a remote should clear auth state in the shell's auth provider and redirect correctly.

5. Vite vs Webpack vs Rspack

• Webpack 5 MF: Most mature, best documented. Start here.
• vite-plugin-federation: Works for pure CSR, but HMR can be flaky across remotes and SSR support is limited. I'd avoid it if you're planning a Next.js migration.
• Rspack MF 2.0: Worth considering if you're starting fresh — better dynamic remotes and improved singleton enforcement, plus much faster builds. The API is nearly identical to Webpack 5 MF.

---

One known gap: not all of Refine's internal contexts are publicly exported (GitHub issue #6675), which matters if you're building tooling that needs to access them directly. For regular app code you won't hit this — the public hooks cover everything.

If you get something working, a community example would be really valuable — there's no official Refine MFE guide yet.