Content requests

[ScriptedAlchemy]

Need to know more about something.
Request a article and I'll try and write one on the topic.

[XiaofengXie16]

1. What's the best practices on managing remoteEntry files? When the host consumes multiple remotes, the host needs to load the remoteEntry files upfront. This can be a problem as you consume more and more remotes.

2. What's the best practices on managing/upgrading shared singleton dependency? (You've kinda answer my question previously in slack which is to use an adapter module but I think this is still worth to talk about this in details in an article)

[juanrivera32]

Not sure if Dynamic remotes would help for number one: https://github.com/module-federation/module-federation-examples/tree/master/dynamic-system-host

[ScriptedAlchemy]

Medusa would be the solution for 1. That's going to be online soon as a saas to remote control webpack MF

[marsh73]

Would love to see some examples of both error handling and smoke testing remote apps... one on how to handle errors in a micro frontend better, and one on approaches to predeploy integration testing... Both seem not module federation specific, but likely valuable for anyone using this in production?

[jrestall]

An updated example of how to use federated modules with a webpack 4 host would be great. Like this video but that works with the new APIs since window[scope].override is now undefined. https://www.youtube.com/watch?v=tigwyK5Khck

[ScriptedAlchemy]

Override would be replaced with init. Check dynamic remotes example. You'd call init with the fake share scope object. Console log webpack share scope in a w5 build to see the shape of share scope object you need to recreate.

[juanrivera32]

How to properly handle updates on shared dependencies across container apps and remotes: breaking changes, backward compatibility, and how to safeguard container apps in case remotes make upgrades on their own (when working in a micro frontends architecture where remotes are owned by different teams)

[einarq]

I guess these concerns aren't really solely related to module federation as such, but mainly a micro-frontend architecture in general?
I don't think there are any silver bullets when it comes to this. Micro-frontends come with the tradeoffs you are describing here. You are trading off the security of a monolith, for the flexibility of sharing code across FEs and for the autonomy of the teams working on them.

They are all very valid concerns though. My personal take on it:

• Handle updates: Teams need to communicate and coordinate.
• Breaking changes: Basically cannot do breaking changes I guess. This is why its so important to keep the API surface as small as possible. Ideally the remote module that an app is pulling in should be more or less a black box.
• Backwards compatibility: Same point as above, back compat is key. You can potentially version the remote some how, perhaps you could have some cloud infrastructure set up for this. If the remote module also comes with some api access then its even harder I think.
• Safeguard container apps: If you are using React, then its key to set up some error boundaries where needed, and perhaps test that they work as intended. Also should have some "smoke tests" running in a main release pipeline, which ensures that the remote loads successfully at least.

These points have also been raised on some blogs posts I've seen here and there.
This article is quite good, see the "Mitigate breaking functionality in a Host" section:
https://rangle.io/blog/module-federation-federated-application-architectures/

That being said, it would certainly be interesting to hear some thoughts from Zack on this as well.

Where I work we are sharing an App Header across several apps via module federation. The header is also hosted on npm, so if the error boundary fails, it will attempt to load it from npm instead. This approach was inspired by the module federation book that Zack has published. This works well for components that are also on npm, but doesn't really apply to sharing of entire modules between apps (since they are typically not on npm/not versioned in the same way).

[juanrivera32]

@einarq thank you for your response. These are concerns about micro frontend architecture using ModuleFederation, as you mentioned. I will keep digging around this topic and read the post you just shared! 😃

[ScriptedAlchemy]

Yeah this is a good one.
I'd use adapter modules and patterns like self sustaining components with small apis but they essentially get their own data. Like my jsx component works almost like a app you mount on the dom. Just in a single react tree.
But there's lots of other good questions in here that would be great to respond to

[einarq]

An article on this would be good, and why/when to use it:
https://twitter.com/scriptedalchemy/status/1526415368972931073?s=21&t=K-IbAvT-VcE15qEpzzwNKg

[ScriptedAlchemy]

Yeah this is a little known treasure. Webpack can import urls at build and download the content to bundle like any other import on disk

[einarq]

Would love to see an example of this. Is there an example on the examples repo maybe?