Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question | How does remote-ui ultimately differentiate from Module Federation? #245

Closed
dhyegocalota opened this issue Oct 11, 2023 · 3 comments

Comments

@dhyegocalota
Copy link

dhyegocalota commented Oct 11, 2023

  • Consideration | Couldn't figure out a better way to ask this question than opening an issue
@lemonmade
Copy link
Member

Hey @dhyegocalota, sorry I missed this issue being opened. This is a very interesting question — I'm curious what made you connect these two technologies together?

I think the main similarity is that both in theory let you split up a larger application into multiple smaller, independently-deployable applications. In module federation, this is done by making shared asset dependencies be loadable asynchronously from each of the smaller applications. In remote-ui, this is done by forcing each of the smaller applications directly call into the host to access any shared logic.

The main difference is that module federation lets you patch together a bunch of these "micro frontends" together on the same HTML page. In remote-ui, the intention is for you to load each of the small applications in a sandboxed environment controlled by the main HTML page, like by using a web worker or iframe. The good part of remote-ui’s approach is that you can fully control what the micro frontends can do — what components they can render, where they are rendered on the page, and what APIs they can access. However, this is most useful for potentially untrusted code; if you trust all the code that’s running, and don’t care about potential conflicting uses of global variables, running several applications on the main page using a technique like module federation is totally fine.

@dhyegocalota
Copy link
Author

dhyegocalota commented Feb 28, 2024

Hi @lemonmade! That's a great question!

So, I'm currently building a marketplace, in which we don't trust the third-party code deployed on our website. We're doing some experiments with Module Federation yet, but it's clear that it has some drawbacks and limitations like unwanted access to global APIs (potentially causing conflicts or compromising security).

When I asked this question, I was interested in using remote-ui as an alternative to Module Federation so that my marketplace website can embed entire web apps (initially only React apps) with safety by all means.

How do you see remote-ui fitting the scenario I described above?

@lemonmade
Copy link
Member

That's a cool use case, thanks for sharing! remote-ui (or, as we just recently updated it to, Remote DOM) is definitely capable of sandboxing untrusted code in this way — that's how we use it at Shopify, where we sandbox third party code from our checkout and admin “host” applications. remote-ui also definitely allows use of React, and the newly-released version uses the DOM API, which makes it possible to use standard React DOM, in addition to libraries like Preact, Svelte, etc.

The main concern you'll likely have is that Remote UI/DOM expect you to define the list of allowed components; third parties can’t just write an application using raw HTML, as they might expect if they were running on the main page. This is a pretty big restriction, but it's one of the main design goals of the library. If that's not what you want, you'll likely prefer using standard iframes instead, which offer the same kind of sandboxing as Remote UI/DOM, but allows developers to use all the power of the browser in their sandbox.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants