Need an example to perform loading of a component via wire, proxy server or external server

[zetekla]

The React component isn't part of the filesystem but rather from external server or a proxy way. Ideally, if possible, can you provide an example package where/how this is done?, the component shall be loaded and rendered properly.

[ScriptedAlchemy]

Hmmm I think I know what you are asking me. If it’s what I think it is, then we need to chat further.

Are you by any chance trying to build microfrintends where each service runs on its own, but you want the client to act as one build?

Essentially adding modules and the urls that resolve them to the existing Webpack manifest,even though they were not necessarily bundled by your build?

Many builds acting as one?

If this is the case. I’ll be willing to take a phone call with you or your team. I know ways to do this, but I’m looking to architect a solution so solve one of the biggest remaining challenges in micro architecture, many builds working as one on the client.

Please let me know if you require this solution. If you’d be interested in architecting a real one with me - I’m open to collaboration. If you just need a quick fix, that fine and over a phone call I can walk through the ways it achievable.

[ScriptedAlchemy]

@zetekla bumping this because i took so long to see this.

Sorry it took 24 days to respond 😑

[ScriptedAlchemy]

@zetekla bump

[ScriptedAlchemy]

@faceyspacey look what’s starting to surface a year later.... well visioned

[regalius]

Hi @ScriptedAlchemy , I came across this thread and from what I understand, we're currently trying to achieve the same thing. So our team are currently building a framework Treats and micro-frontend architecture around it. The idea is that we want to have each page served by multiple frontend services (server-side) that would be joined together on the client to form a Single Page Application.

My initial (wild) idea is (1) we could create a master (Webpack JSON stats & route aggregator) and slave (frontend services) system. (2) Each time a frontend service started it'll register its JSON stats and get the current state of the aggregated JSON from the master, the master would then send a broadcast message to the other slaves to update their JSON stats to match with current state. (3) For each user request to a frontend service, we would then just send away the aggregated JSON to the client via JS variable/HTML markup. (4) In the client we can dynamically generate the Webpack manifest and the webpack dynamic chunk entry (with react-universal-component) based on the JSON stats that had been sent to the client. (5) And when the route requested we could then load it like a normal dynamic loaded webpack chunk.

I wonder if you've ever tried this approach and would like to hear more from your experience regarding microfrontend.

[ScriptedAlchemy]

Hey @regalius

Thanks for reaching out! While ive not publicly disclosed anything just yet. I have just finished designing a fleet of micro-frontends over at Starbucks. In which there was a good amount of time dedicated to thinking this very issue through.

This is a tricky hurdle to overcome, and in my opinion - one of the few remaining ugly sores not yet attended to in frontend technology (at least not well publicized)

Your idea isn't so wild! In fact this was one of my initial solutions.

Would you be open to either a chat over slack, or a phone/skype call? I'm more than happy to walk through some of the solutions that ive used and disclose one of the newer ones that I'm currently working on, my later solutions lean more heavily on webpack magic.

In short (and to hopefully entice a conversation over a more efficient means of communication) manifest entry point reporting to an upstream source is totally viable! Problem ive discovered is its still not quite as smooth as an SPA and you need to make sure that those JSON chunks are reported effectively (something cached between MFE's and you got problems)

The webpack JSON tends to bee a little large too which can make reporting to a central source sluggish and sometimes unreliable.

Some of my older solutions: during deploy, publish the entry points of the code split to something like consul, then map the resources manually (theres variations of this but more or less is similar to your mentioned idea). While consul/some layout engine is responsible for sending scripts to the client, each MFE is still responsible for its own render and operates independently, which is i think what you are indeed aiming for.

Here's some gotchas that ive been working to squash, and ideally the more modern solution would be best communicated over a call - due to it being a little hard to explain clearly via text.

1) code-split resources have tons of duplication between builds. Because Webpack doesn't have context of other builds, there tends to be a massive amount of duplicated vendor chunks under different names. You could mitigate this by manually controlling the externals per webpack config 2) If you land via one micro-frontend, the entry point is likely expecting a fresh React.renderToDOM... should still work but it's basically a fresh render 3) Even just putting the various applications entry points on the page is going to end up being sizable by default. The manifest is usually attached to other various things.

My main dislike with the whole JSON centralizing and reporting is you depend on some server based logic for those JS files to be mapped initially. Once the entry point is loaded, Webpack can take over. It's just not so awesome when you have many MFEs and your app depends on the server to flush stuff out for it to kick off between the various hops (between MFEs)

My newer solution, initially developed as an experiment for react static - is as follows. I use a custom function to determine the chunkgroups and split everything up a little better then Webpack does on its own. I then configure Webpack to isolate its internal asset manifests that usually are bundled into main.js. I use either use hash based chunk ids or named module ids for the build. Under the hood Webpack will concatenation all assets manifests on the client into one large, single manifest.

Because the chunk groups are assembled in a specific way, if MFE 1 were to load a resource, when the codesplit part of the next frontend attempts to require it, either the chunk name or module Id will resolve instantly because it's already been recpquired or the browser has it in cache because the chunkgroup function ensures a predictable file name is generated.

The last sticky issue is routing... at render routing makes this really hard to accomplish (react router and the likes), we have solved this by building our own solution known as redux first router.

Again this isn't the easiest solution to explain over text, but can provide more details via a better communication medium if need be. Given our close accociation with Webpack and pioneering code split SSR, there's few challenges we haven't solved in some capacity in relation to these issues.

Can't say I know every trick there is and I myself am still architecting a seamless SPA-like solution. But I'll gladly share my knowledge in micro-frontend architecture, to which I maintain virtually all my own intellectual property and share it willingly to move the industry forwards for the greater good of us all