DEV Community

Setup a Micro-Frontend architecture in 15min with Vite!

Meidi Airouche on December 10, 2024

In a monolithic frontend architecture, a single codebase handles the entire user interface. While this can simplify initial development, it can bec...

Read full post

Oziel Perez • Dec 11 '24

This is great for SPAs, but if you guys just want a traditional website with different frameworks for functionality, try Astro instead

Meidi Airouche • Dec 14 '24

When choosing between Vite and Astro for microfrontends, it depends on your project’s needs.

Imagine you're building a SaaS dashboard for analytics with microfrontends:

Real-time Data Visualization (React): Graphs, charts, and stats that update live via WebSocket or polling.
User Management (Vue): Complex CRUD operations with modals, forms, and validation.

Where Astro is Limited:

Real-time Interactions: Astro’s static-first model means it struggles with highly dynamic components like live-updating graphs or dashboards that need frequent re-rendering based on API data. You’d have to include several "hydrated islands" (Island Architecture oriented), which increases complexity and runtime costs as Astro initializes these components separately.
Complex State Management: Dynamic state handling (e.g., syncing data between user actions and server updates) is cumbersome in Astro because it isn’t built for full-fledged SPAs or highly interactive systems.

Why Vite Excels:

Dynamic Features: Vite handles WebSocket-based updates and dynamic rendering seamlessly, with frameworks like React or Vue fully supported out of the box. For example, a live-updating dashboard built with Vite remains performant and developer-friendly.
Development Speed: Vite’s Hot Module Replacement (HMR) ensures that developers can see live updates to components like charts or forms without a full reload, even when working across multiple microfrontends.
Interoperability: In the SaaS dashboard, you can mix frameworks (React for visualizations, Vue for forms) easily with Vite’s ecosystem and tools like Module Federation to manage independent builds.

Conclusion

Astro is ideal for static pages, but for the dynamic, interactive SaaS dashboard core, Vite’s performance, flexibility, and robust runtime support can make it a better choice.

Steve McDougall • Dec 14 '24

100% recommend Astro over anything else these days. Unless you need something specific from one of the other *kit frameworks

Meidi Airouche • Dec 14 '24

dev.to/mairouche/comment/2ka02

Florian Rappl • Dec 12 '24

Sorry, but I don't see the "micro frontend architecture". There are some core properties that are unanswered (or maybe I could not see / find it):

The composition should be possible at runtime; but here everything is composed in one build step. In general this is possible (build-time composed MFs), but then
The sources must be able to come from different repositories (here its all in one repository)

Generally, if you look at things such as Module Federation, Native Federation, Piral, ... these solutions give you something that is distributed from the beginning, i.e., where you (by default) have runtime composition.

Having team autonomy (which is the most important aspect of a micro frontends architecture) is only possible with independent deployment processes. So how would I update, e.g., the trending module, without updating the whole application? How could I add another module without having to redeploy the application?

Sorry if my comment comes across negative - it is meant as an encouragement; not as a letdown.

Meidi Airouche • Dec 12 '24

Thank you for your comment! Every feedback is welcome.

You’re absolutely right that runtime composition and independent deployments are very important. My article primarily focuses on the get started, where modules are combined via dist directories for simplicity of the article and quick setup.

However, for production, Vite can indeed support runtime federation by leveraging:

Dynamic imports to load modules hosted on separate DNS addresses.
Shared dependencies using peerDependencies to avoid duplication.
Independent deployments, allowing teams to update or add modules without redeploying the entire application.

I’ll update the article to clarify that the dist approach is meant to onboard, while runtime federation is better suited for production. Thanks again for your valuable feedback, it helps make the article more complete! 😊

Meidi Airouche • Dec 12 '24

I added the bonus section to the article to explain how :) Thank you

Han Yang • Dec 10 '24

very good tutorial, but angular v19 do not have .\app\app.module.ts, in dist folder, vue generated header.umd.cjs file, react do not generate trending.umd.js.

Meidi Airouche • Dec 10 '24

I passed everything in ESM since it's more standard now. Thank you for the feedback <3

Han Yang • Dec 11 '24 • Edited

current status - 2024-12-11 - base concept works fine

Meidi Airouche • Dec 11 '24

I added the repository with the overall code working (except for Angular) at the end of the article : github.com/mairouche/mfe-news-portal

Naveen Ravichandren • Dec 12 '24

Thanks, this is kick-ass.
I have a doubt, how would u share data across these 2 components? Vue to react and vice versa

Meidi Airouche • Dec 12 '24

With Redux for state management for example which is accessible from Vue, React or even Angular.
With RxJS for cross-component events since it's also compatible with each lib/framework.

You can also have shared data in the Shell like following for example :

// shared/service.js
let sharedData = null;

export const getSharedData = () => sharedData;
export const setSharedData = (data) => { sharedData = data; };

// React Microfrontend
import { setSharedData, getSharedData } from './service';

setSharedData('Data from React');
console.log(getSharedData());

// Vue Microfrontend
import { setSharedData, getSharedData } from './service';

setSharedData('Data from Vue');
console.log(getSharedData());

Juan Labrada • Dec 12 '24

Absolutely loved this post!!

Meidi Airouche • Dec 12 '24

Thank you very much <3

Griffin Rivera • Dec 11 '24

Thanks for sharing.

Mohammad Farseen Manekhan • Dec 11 '24

This is amazing.
This is exactly what's happening in Astro behind the hood.
Correct me if I'm wrong.

Meidi Airouche • Dec 11 '24

To be Honest I discovered Astro with a previous comment and I'll deep dive into it. It looks like the same with Astro being maybe a bit more opinionated and closer to a framework than a library. But I'll look for it to see if I well understood

Meidi Airouche • Dec 14 '24

After deep diving into astro and trying it (only for 2 days so not that much background at this stage), this is what I conclude :
dev.to/mairouche/comment/2ka02

Kevin Luo • Dec 12 '24

How does the router work in this case?

Meidi Airouche • Dec 12 '24

This is a good question. I was affraid that the article would be too long if I deep dived into routing, state, refs etc...

I'll answer here then.

In the Shell, you can use a vue or react router (what you prefer) to route to any kind of component. For example :

import { createRouter, createWebHistory } from 'vue-router';

const routes = [
  { path: '/', component: HomePage },
  { path: '/vue-mf', component: () => import('vueMicrofrontend/App') },
  { path: '/react-mf', component: () => import('reactMicrofrontend/App') },
];

const router = createRouter({
  history: createWebHistory(),
  routes,
});

export default router;

Once the microfrontend is loaded throught the global Shell router, it uses its own internal router if it has one.

So a good practice would be to keep the Global Shell router just load the micr-frontends and then, each micro-frontends having its own dedicated standalone router.

Mahmoud Alaskalany • Dec 10 '24

Thanks for this post i will try this with angular

Ciphernutz • Dec 11 '24

Absolutely agree with your points. This is a game-changer!

Kevin.CK • Dec 11 '24

Thanks

liwenzhi • Dec 11 '24

Couldnt integrate angular app, got error:

Uncaught SyntaxError: The requested module '/apps/highlights/dist/main.js' does not provide an export named 'mount' (at main.js:3:10)

has anyone make it run successful?

Meidi Airouche • Dec 11 '24

Depends on the version. Try with this in src/main.js:

import { platformBrowserDynamic } from '@angular/platform-browser-dynamic';
import { AppModule } from './app/app.module';

function mount(el: HTMLElement) {
  const bootstrap = async () => {
    const appElement = document.createElement('app-highlights');
    el.appendChild(appElement);
    await platformBrowserDynamic().bootstrapModule(AppModule);
  };

  bootstrap().catch(err => console.error(err));
}

export { mount };

liwenzhi • Dec 11 '24

got an abnormal main.js file under dist folder:

"use strict";(self.webpackChunkhighlights=self.webpackChunkhighlights||[]).push([[792],{429:(e,o,_)=>{}},e=>{e(e.s=429)}]);

Do you mind sharing your full project code? this is really interesting...i have never seen a solution like this...

Meidi Airouche • Dec 11 '24

I update to last versions and share it tomorrow. I ping you in comment when it's done

Meidi Airouche • Dec 11 '24 • Edited

@lwz7512 Indeed, I was using module federation with old Angular versions. I will find out what's the best approach between, widgets, module federation or web component and propose it in an edit of the article.

Connections Hint • Dec 13 '24

Like it!

Mayur Athavale • Dec 12 '24

Gr8 explaination and systematic approach. Got to learn a lot.🙌

GP • Dec 11 '24

Integrating multiple technologies within a micro frontend architecture is generally regarded as a suboptimal design choice. This approach can lead to significant performance issues, as it necessitates loading numerous technology libraries alongside each component, resulting in a bloated and resource-intensive application. Moreover, the complexity introduced by this multi-technology setup can make maintenance and management exceptionally challenging.

A more streamlined and efficient approach is to standardize on a single library or framework across the micro frontend ecosystem. This strategy offers several advantages:

Improved performance due to reduced overhead from multiple libraries
Simplified codebase that's easier to maintain and update
Enhanced consistency in development practices and user experience
Better team collaboration and knowledge sharing
Reduced learning curve for new developers joining the project
More straightforward integration and communication between micro frontends

By focusing on a unified technology stack, development teams can create more cohesive, performant, and maintainable micro frontend applications that align better with the core principles of this architectural pattern.

Meidi Airouche • Dec 11 '24 • Edited

Agree. This is why I explained in the article that it can be a solution (temporary one) to shift from a framework to another smoothly here :

In a real life software growing through years, being able to handle multiple frameworks can be a smooth way to migrate from an old one to a new one whenever it's needed.

For example, in my experience, we transitionned form Angular to Vue step by step thanks to this approach. I'm not saying it's a desirable design but it's an existing one. Used in the appropriate context, it can bring value.

Serhii Viazkov • Dec 11 '24

did you have any luck with precious angular versions , eg 18?

Meidi Airouche • Dec 11 '24

I succeed with module federation from Angular 16- but it's not that simple. I'm still testinfg things but Vue and React are Libraries whereas Angular, as a Framework, has it's own event, state, data management etc... So it's not that easy.

peng • Dec 18 '24

i wonder how to manage route?