Webpack 5 | Federated Module | Micro-FrontEnd | ESI | NPM | Micro Frontend Architecture

So, I thought to share my knowledge on some more advanced, easy and interesting concept on Micro Frontend Architeture.

So, up until last October 2020, the implementation of micro front end strategy seems to only bring increased complexity and inconsistent performance where the bad outweighs the good.
Hence, WEBPACK 5 introduced Module Federation to try and change that.

hmm whats that now : Basically, it is a JavaScript architecture invented by Zack Jackson who then proposes to create a Webpack plugin for it. The Webpack team agrees, and they collabrated to comeup with the plugin.

Let me explain this in more detail how this works:
Consider we have 2 projects one is Project A and other is project B. And we have one cool widget in Project A and I want the same to access in Project B. How can I access that?

Basically, I can achieve it by following trends in the market :1- I can extract the code and put that in npm library and then can access it in both the projects.
Challenge: If I want some modification in the widget, I need to publish it get the new version of it, maintaining a whole new project kind-a-thing. hmm, thats bad, I need to look for some run-time approach here.

2- ESI — Edge side Includes, In this case we’re going to extract the code and create a bundle of html, js and css and put that in some server lets put that in AWS-S3. And then we can use ESI to bring that in right before it goes out. This approach will work too. But this sort of approach will not go well with React architecture, because of injecting some arbitrary html in the middle of 2 projects.

3- Micro FrontEnd — We can use Single SPA concept, but the thing here is we have to extract the widget component again and bundle it or register it somewhere and then consume it in these projects and no doubt we can get it because once we published it will be live everywhere. BUT its still its own externalised thing

4- Federated Module — Part of Webpack 5, here what I can do I will leave that cool widget in place like inside Project 1 and still it will be externalised and second project can include it almost seamlessly and it can also bring its dependencies

I can add that plugin in webpack config file:

plugins: [
    new ModuleFederationPlugin({
      name: "project1",
      filename: "entry.js", // it has the meta description of all the stuff that app exports 
      remotes: {
        entry: "project2@http://localhost:3002/entry.js", // Also include the path in Project 1
      },
      exposes: {
        "./CoolWidget": "./src/CoolWidget"
      },
      shared: {'react', 'react-dom', 'WIDGET-LIBRARY'      }, // all thh dependencies 
    }),

And that’s it!!!! Yes that was so easy and exciting. Isn’t IT!!

Yea this is so amazing and so extensible mechanism and I think this changes the architecture of how we think about a web application can do, it is not just serving html/css/js and renders and so on and so forth. But now we have an entirely separate surface which is an exposure of internals to other application. And this is all doable via SSR too. If our code is available on the server side and we cann start all kind of way to extend server with externalised code live…. Just one word, WOW!!!!

I personally want to see, how this will evolve in next couple of years!!!

#webpack #esi #microfrontendarchitecture #federatedmodules #javascript #react