Event Bus for Cross-App Communication
Learn to implement an event bus for decoupled communication between different Micro Frontends.
Event Bus for Cross-App Communication is a free Micro Frontends Architecture with Module Federation lesson on CoddyKit — lesson 1 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Micro Frontends Architecture with Module Federation learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
MFE Communication Challenges
In a Micro Frontend (MFE) architecture, different applications run independently. But what happens when one MFE needs to tell another MFE something?
Direct communication can create tight dependencies, making your system harder to maintain and scale. We need a way for MFEs to talk without knowing too much about each other.
Meet the Event Bus
An Event Bus is a design pattern that provides a central hub for communication between different parts of an application, or in our case, different Micro Frontends.
Think of it like a community bulletin board where anyone can post a message, and anyone interested can read it.
How it Works: Publish/Subscribe
The Event Bus operates on a Publish/Subscribe (or Pub/Sub) model:
- Publishers (MFEs)
emitevents to the bus, often with some data. They don't care who listens. - Subscribers (other MFEs)
listen(oron) for specific events. They react when an event they're interested in is published.
This keeps communication decoupled.
Designing Our Event Bus
A simple Event Bus needs a few core methods:
on(eventName, callback): To subscribe to an event.emit(eventName, data): To publish an event with optional data.off(eventName, callback): To unsubscribe from an event (important for cleanup).
Let's build a basic JavaScript version.
Building the Bus Core
Here's a basic JavaScript class for an EventBus. It uses an internal object, listeners, to store all registered callbacks for each event name.
Try running this example:
class EventBus {
constructor() {
this.listeners = {};
}
on(eventName, callback) {
if (!this.listeners[eventName]) {
this.listeners[eventName] = [];
}
this.listeners[eventName].push(callback);
}
emit(eventName, data) {
if (this.listeners[eventName]) {
this.listeners[eventName].forEach(callback => {
callback(data);
});
}
}
off(eventName, callback) {
if (!this.listeners[eventName]) return;
this.listeners[eventName] = this.listeners[eventName].filter(
listener => listener !== callback
);
}
}
const bus = new EventBus();
console.log("EventBus initialized!");Sending Messages (Publish)
To send a message, one Micro Frontend will call the emit method on the shared Event Bus instance. It provides the event name and any relevant data.
The Event Bus then broadcasts this event to all registered listeners.
Publishing in Action
Here, we simulate an MFE publishing a 'user:loggedIn' event. Notice how the mfeAPublisher function uses bus.emit().
Run the code and see the output:
class EventBus {
constructor() {
this.listeners = {};
}
on(eventName, callback) {
if (!this.listeners[eventName]) this.listeners[eventName] = [];
this.listeners[eventName].push(callback);
}
emit(eventName, data) {
if (this.listeners[eventName]) {
this.listeners[eventName].forEach(callback => callback(data));
}
}
off(eventName, callback) {
if (!this.listeners[eventName]) return;
this.listeners[eventName] = this.listeners[eventName].filter(
listener => listener !== callback
);
}
}
const bus = new EventBus();
// MFE A publishes an event
function mfeAPublisher() {
const data = { user: "Alice", action: "loggedIn" };
bus.emit("user:loggedIn", data);
console.log("MFE A published 'user:loggedIn'");
}
mfeAPublisher();Receiving Messages (Subscribe)
Another Micro Frontend that wants to react to this event will use the on method to subscribe. It provides the event name it's interested in and a callback function to execute when that event occurs.
The callback function receives the data published with the event.
Subscribing and Reacting
Now let's put it all together. One MFE subscribes to the user:loggedIn event, and another MFE publishes it. When you run this, you'll see both actions logged.
Observe the flow of communication:
class EventBus {
constructor() {
this.listeners = {};
}
on(eventName, callback) {
if (!this.listeners[eventName]) this.listeners[eventName] = [];
this.listeners[eventName].push(callback);
}
emit(eventName, data) {
if (this.listeners[eventName]) {
this.listeners[eventName].forEach(callback => callback(data));
}
}
off(eventName, callback) {
if (!this.listeners[eventName]) return;
this.listeners[eventName] = this.listeners[eventName].filter(
listener => listener !== callback
);
}
}
const bus = new EventBus();
// MFE B subscribes to an event
function mfeBSubscriber(data) {
console.log("MFE B received 'user:loggedIn' event:");
console.log(data);
}
bus.on("user:loggedIn", mfeBSubscriber);
console.log("MFE B subscribed to 'user:loggedIn'");
// MFE A publishes an event
function mfeAPublisher() {
const data = { user: "Alice", action: "loggedIn" };
bus.emit("user:loggedIn", data);
console.log("MFE A published 'user:loggedIn'");
}
mfeAPublisher();When to Use an Event Bus
Pros:
- Decoupling: MFEs don't need to know about each other.
- Simplicity: Easy to implement for basic broadcast needs.
- Flexibility: New subscribers can be added without changing publishers.
Cons:
- Debugging: Hard to trace event flow (event spaghetti).
- No direct response: Not suitable for request/response patterns.
- Global state: The bus itself can become a single point of failure or a source of implicit dependencies.
Event Bus Quick Check
An Event Bus is a powerful tool for communication in Micro Frontends. Which of the following statements accurately describe its benefits?
Recap: Event Bus Essentials
You've learned about the Event Bus pattern for inter-Micro Frontend communication.
- It uses a Publish/Subscribe model.
- Publishers
emitevents, subscriberson(listen for) them. - It promotes decoupled communication, reducing direct dependencies.
- While simple and flexible, be aware of potential debugging challenges and ensure proper cleanup (
off).
Next, we'll explore shared state management!
Frequently asked questions
Is the “Event Bus for Cross-App Communication” lesson free?
Yes — the full text of “Event Bus for Cross-App Communication” is free to read here on the web, and the Micro Frontends Architecture with Module Federation course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Micro Frontends Architecture with Module Federation course, upgrade to CoddyKit PRO.
What will I learn in “Event Bus for Cross-App Communication”?
Learn to implement an event bus for decoupled communication between different Micro Frontends. You practise Micro Frontends Architecture with Module Federation with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start Micro Frontends Architecture with Module Federation?
No prior experience is required. Micro Frontends Architecture with Module Federation on CoddyKit is structured for beginners through advanced learners; this is — lesson 1 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “Event Bus for Cross-App Communication” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this Micro Frontends Architecture with Module Federation lesson?
Yes. Every Micro Frontends Architecture with Module Federation lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.
All lessons in this course
- Event Bus for Cross-App Communication
- Shared State Management
- Custom Communication Solutions
- Communicating with Custom DOM Events