Micro frontend- and module federiation like architecture

[RickStanley]

Hi, I'm trying to set up an architecture similar (or perhaps equal) to that of the title. I was going to classify this discussion as "Help", but this isn't the scope of Vike it seems, and besides, I'm hacking around to see what works and what doesn't.

So I would like to share my attempt(s) and the ideas that I have to achieve what I want, and see if the community have any suggestions.

What I want to achieve

Similar to Module Federation:

Multiple separate builds should form a single application. These separate builds act like containers and can expose and consume code between builds, creating a single, unified application.

But unlike many of the examples that are around (specifically: module-federation-examples), our repository is not unified (aka monorepo) so it gets a bit trickier to set up a configuration that reuses/shares some dependencies.

With that in mind, I'm trying to come up with one in a mixture of: Vite + Preact + Vike, as I didn't want to create my own library that compiles to static assets (HTML) and maintain it. If it is just a plugin that I could use in conjunction with another to complement and achieve my needs, it's enough. Here's what I'm working on: https://github.com/RickStanley/poc-ssg-preact

What I want is:

• share libraries through import map (like: native-federation);
• have separate repositories but somehow manage shared libraries between them (I'm thinking of using rollupOptions.exclude to not bundle libraries, like Preact, together and let the plugin handle theses dependencies. by injecting a import map);
• use SSG for the page alone, but create some kind of index.tsx (later dist/client/assets/index.js) wherein would have the imports and exports of exposable components and routes of that app (much like how it's done with WebPacks plugin Module Federation Plugin, in exposes properties, but being a file instead;
• the idea is that every app/page of the app can have its own PageShell.tsx, but the pages themselves could be imported into another app through URL and get each page's route and let the shell decide how to route them (for instance, we can't have two roots in the same application, it would be better to handle that route from the shell, perhaps Vike's router is not suitable for this, I have not tested yet);

What I got so far

I started by creating a simple plugin: https://github.com/RickStanley/poc-ssg-preact/blob/master/micro.ts.

The problem with shared libraries seems to be easily solvable: copy the library from node_modules, put it in a shared folder and inject importmaps into the static HTML, so it's the shell responsibility to provide the excluded library(ies). It works pretty well, for simple libraries' paths.

I'm having a hard time trying to figure out if 'vike/server' should be included as shared library, for now, I have this list:

  	external: ['preact', 'vike/server', 'preact-render-to-string', 'preact/hooks'],

And I have to check if Vike's router works out.

Next steps

As I've said, I'll have to check if Vike's router works the way I want, that is: not bundle itself in the page's JS file and if it's configurable through the client (dist/client/), so that I can manipulate at will in the PageShell.

See if it's possible to have some kind of "index.tsx" exist inside pages/ and import and export each pages path to the Blob storage in which it'll reside (this is our specific use case, in this research), so that I can export "myPage.js" and "myPageRemote.js", the later just being a wrapper for dynamic import of the future page's path, injected through environment variable at compile time (Azure Pipelines).

These things seem feasible. Am I missing something, perhaps?

Anyway, I just wanted to share what my goals are and what I'm trying to so far. Any suggestions are welcome!

[brillout]

Thanks for sharing your attempts and thoughs.

FYI module federation is on Vite's radar (see Evan You's ViteConf talk).

From Vike's side, micro frontend use cases aren't high priority right now, but we're happy to revisit prioritization if we're provided with a strong rationale.