Published on

To Federate Or Not To Federate

Table of Contents

Module federation has been a game changer for large frontend projects. It has brought simplicity to building a micro-frontend architecture by abstracting away all the challenging parts such as loading remotes and deduplicating dependencies.

Not only that, but the module federation plugin also makes it easy to configure micro apps that require minimal setup to build.

After working with and thinking about Module Federation for approximately a year and a half, I have come to realise one thing:

Module Federation does not solve technical challenges (to the most extent), but rather solves organisational challenges.

What do I mean by the above?

From most articles I have seen (including the ones I wrote myself), the point that stands out is always "Module Federation helped improve our test times, build times, and deploy times." But, Module Federation can't do all of that. At its core, Module Federation is simply a way to share code at runtime. You can think of it as an abstraction over building each project as a JS file and loading and running the file lazily. Granted that module federation does much more than that, like deduplicating dependencies and managing singletons and so on. But that's just what it really is - a way to share code at runtime.

So if you think that module federation itself is going to solve all of your technical problems, that is not going to be the case. You will need to configure the other tools that you already use to work with module federation.

Before you add module federation to your project, ask yourself the following questions:

  1. Are my problems organisational or technical in nature?
  2. Is module federation itself fixing the problem, or is something else that we are doing to make module federation work fixing the issues?

One way to figure out if you actually need module federation is to ask the question:

Will my problems get solved by using a monorepo instead?

If your answer is yes, then you don't need module federation

When should you actually use module federation?

I previously mentioned that module federation is a tool to solve organisational challenges rather than technical ones. Have you heard that being said somewhere else before? Perhaps for micro-services?

First and foremost, module federation is a tool for team independence. Use module federation when multiple teams contribute to the same codebase and it has become difficult to get all developers on the same page regarding libraries and decisions.

Another reason to use module federation would be in cases where teams want more independence in deployments. A team can convert their code into a remote and deploy independently without having to worry about what else is going into production when they run a pipeline.

Did you like what you read?

You can follow me on Twitter or LinkedIn to get notified when I publish new content.