DEV Community

Discussion on: ⚔️ Cross micro frontends communication 📦

View post
Collapse
 
dgreene1 profile image
Dan Greene •

I like the window observable approach you've recommended, but I think it's important to list that it has a "con" to the approach: It misses type safety.

Sure, you can change the type in the interface from T extends any to T extends unknown and that will help a little bit. But that doesn't solve the problem that occurs when a MicroFrontend falls out of date. To phrase that as a question:

What does the observing MicroFrontend (let's call her "O") do when the publisher (let's call her MicroFrontend "P") changes the structure of the event that it's publishing?

For instance:

// in P's code on Monday
obs.publish({ foo: "bar" })
// in O's code on Tuesday
const { foo } = obs.listen();

// in P's code on Friday
obs.publish({ body: { foo: "bar" } });
Enter fullscreen mode Exit fullscreen mode

What happens?

Well, MicroFrontend O is going to have a runtime error since there was no requirement to re-compile/re-deploy MicroFront O after MicroFrontend P changed it's code.

Note: Consider subscribing to me, as I'll be writing my own article on this specific problem, and I'll likely refer to yours as a starting block. Thank you for your hard work @luistak.
Enter fullscreen mode Exit fullscreen mode
Collapse
 
luistak profile image
Luís Takahashi •

Over that problem, I would suggest creating a new abstraction that will always handle both sides and exposes a consistent API that may not change

This is the same problem as Rest api's

I've seen some folks solving this problem versioning their endpoints, so another solution would be versioning those namespaces to something like:

const observable = new Observable('v1/items');

const observable = new Observable('v2/items');
Enter fullscreen mode Exit fullscreen mode

And each version would have different responses