By the end, you'll be equipped to evaluate whether microfrontends are the right solution for your team's specific needs.

I’ll cover the following:

• What are Microfrontends?

• Traditional Microfrontend Patterns

  • Server-Side Composition

  • iframes

  • Build Time Integration – Packages

• Modern Microfrontend Patterns

  • Module Federation

  • Single SPA

• Detailed Comparison

• Tradeoffs and Challenges with Module Federation

  • Setup Complexity

  • Runtime Challenges

  • Operational Concerns

• Conclusions

  • What’s next?

What are Microfrontends?

If you've heard about microservices on the backend, microfrontends represent a similar approach in the frontend world, with many of the same benefits.

Your team might adopt a microfrontend approach to enable team autonomy, reduce deployment risks, and scale development across multiple teams. Each team owns its technology stack, deployment cadence, and workflows. Yet they still deliver a single, cohesive user interface.

The overall idea is to move away from a big monolithic UI to decoupled UI codebases that can be owned, managed, and deployed by separate teams independently.

The simplest way to think about Microfrontends is the following:

Integrate one piece of UI into another

What can this piece of UI be, you may ask? Here are some examples:

• Pages – parts of a website owned by specific teams. For example, the Auth team may own login/signup pages, whereas the engagement team may own the marketing pages, and so on.

• Components – Components like header and footer are good candidates for a microfrontend approach as well. They’re relatively static but need to stay consistent across the website and may integrate with teams who own different sets of pages.

• Widgets – A recommendation widget may be owned by a recommendations team, for example, and it can be integrated into different parts of the page based on the context. This is different from a static component, as given the context, the recommendation widget may also fetch relevant data via APIs (also owned by the recommendations teams).

Traditional Microfrontend Patterns

After reading the definition of a microfrontend, you might be thinking, oh, wait, who builds UI with a big monolith these days anyway (except giants like Google)? If that’s the case, your team is most likely using one of these traditional approaches to building Microfrontends:

Server-Side Composition

This is the most common approach I've encountered across various organisations. The idea is to split your website based on route patterns or pages. For example, you might route users to the accounts team for any routes starting with /account/* (/account/login or /account/signup may fall under this pattern). Or you may have a similar route prefix for other parts of your web app, like /blog/* for the marketing section of your app.

This is typically implemented at the reverse proxy layer (such as using NGINX), which routes traffic to the appropriate downstream UI service based on the path matching.

iframes

Another common approach is using iframes, though this method has significant limitations.

Unlike server-side composition, which operates at the page level, iframes can integrate as widgets within pages. Using iframes, you can load another website as a part of the website you want to integrate it within using the <iframe> tag.

Some examples of this approach, which you may have seen, are websites that integrate Twitter feeds, Google Maps, and so on. Although these are examples of external widget integrations with iframes, companies may integrate certain widgets that are powered through iframes.

Build Time Integration – Packages

This approach involves publishing components as a UI library that other applications can integrate.

This is useful if you want to integrate full-blown apps with multiple pages, widgets, or static components like headers and footers, where this approach is pretty common.

Typically, this approach means that one team publishes their components as a package, while other teams integrate a specific version of this package.

In this example, it’s important to note that the Widget component is pulled in during the dependency install phase of the app. The web app can utilise this widget like its own component, which gets built together as one module and shipped to the users.

Modern Microfrontend Patterns

Module Federation

Module Federation enables you to integrate remote UI pieces within a host application at runtime. These pieces can be full pages, widgets, or components.

Module Federation originated as a Webpack 5 feature, extending the bundler's capabilities to load JavaScript code from remote sources at runtime.

Module Federation 2.0 is the evolution/improvement of the original Webpack 5 feature, with implementations available for other popular bundlers like RSPack and Vite as well.

Even if you’re using Webpack 5, I would recommend using Module Federation 2.0 as it takes care of some common gotchas that exist in the original Webpack 5 implementation.

Let’s take an example to understand some of the common pieces of Module Federation.

Imagine that we’ve a blog application, owned by the Content Team & a Widget, which is owned by the Recommendations team.

Now, let’s say the content team wants to integrate a recommendation widget within their application. Assume these teams have separate codebases hosted on different domains. The content team is on website.com & the recommendations team is on recommendation.com

Here’s how you can achieve this MFE integration via Module Federation:

Remote

Responsible for exposing JavaScript files as remote (for example, utilities, components, and so on).

In our example, it would be the Recommendation’s team acting as a remote & would require a configuration to ‘expose’ the Widget.

new ModuleFederationPlugin({
  name: 'recommendation',
  exposes: {
    './Widget': './src/Widget.js',
  }
})

Remote Entry

Remote entry is the URL for the entry point for a remote. A remote may expose multiple JavaScript files, & remoteEntry file would be aware of all of them.

Module Federation by default hosts the remote entry file at the root. In our example, recommendation teams might host their remote entry on https://recommendation.com/remoteEntry.js

Host

An independent website that consumes JavaScript from one or more remotes via Remote Entry. Think of remote entry as a namespace for your app under which it can export multiple things like components, utils, and so on, as exposed by a particular remote.

In our example, the Content Team would act as a Host & they’ll define the recommendation team’s remote entry within remotes configuration.

new ModuleFederationPlugin({
  name: 'content-blog',
  remotes: {
    "recommendation": 'recommendation@https://recommendation.com/remoteEntry.js',
  },
  // ... other configs
})

Shared

Both hosts and remote can specify dependencies as SemVer that are automatically negotiated and shared during runtime. These can include common framework dependencies, such as React, which may require being a singleton, or other vendor libraries that can be potentially shared.

Having the right shared configuration ensures that the client does not download libraries or code that is already available on the host when fetching UI pieces from a remote location, which is key for optimal performance when integrating Module Federation.

const deps = require("./package.json").dependencies;

new ModuleFederationPlugin({
  shared: {
    ...deps,
    react: {
      singleton: true,
      requiredVersion: deps.react,
    }
  },
  // ... other configs
})

Imports and Usage

Module Federation integration lets you use imports as if those JS files were available locally. Module Federation does all the stitching behind the scenes at runtime, in terms of fetching the remote entry and appropriate dependencies to make it available when you use it.

// Import is of the format - <remote>/<expose-from-remote>
import Widget from 'recommendation/Widget';

// Render somewhere, making sure to handle loading via Suspense
// & errors via error boundary in React
<ErrorBoundary>
  <Suspense fallback={<Loading />}
    <Widget />
  </Suspense>
</ErrorBoundary>

In a nutshell, the module federation concept is this simple —

Fetching JS code (components, utils, and so on) from a remote server at runtime and still being able to share dependencies and be performant while doing so.

Single SPA

When you look up microfrontends, Single SPA often appears as a popular solution. But its primary use case is quite specific: integrating components across multiple frameworks (for example, React + Angular + Vue in the same application). Here's how it works in practice:

Single SPA acts as a JavaScript router that mounts and unmounts entire applications based on URL routes. Each "single-spa application" is a framework-specific app that gets loaded when its route becomes active.

// Register applications with Single SPA
registerApplication({
 name: '@mycompany/react-app',
 app: () => System.import('@mycompany/react-app'),
 activeWhen: ['/react-app']
});

registerApplication({
 name: '@mycompany/angular-app', 
 app: () => System.import('@mycompany/angular-app'),
 activeWhen: ['/angular-app']
});

Single SPA handles the "orchestration" part – deciding which app should be active and managing their lifecycles. It doesn't solve the "how do I load remote code" problem – you still need to pair it with one of the approaches we've discussed (Module Federation, build-time packages, and so on).

If your applications use the same framework (like all React), you can skip Single SPA entirely and use Module Federation directly. Single SPA adds complexity that's only justified when you truly need multi-framework integration.

Detailed Comparison

Tradeoffs and Challenges with Module Federation

The primary tradeoff in using Module Federation is the initial setup effort, which I briefly discussed in the previous comparison table.

Here are some other challenges to anticipate when integrating via Module Federation:

Setup Complexity

1. Bundler-specific challenges – Some things may require you to know your bundler's internals to make the integration work for your app. For example, with Webpack 5, if your remote not only exposes federated components but also serves a user experience, you’ll need the appropriate chunk setup to make that work. This is because Module Federation by default expects a certain chunk optimisation strategy and exposes the remoteEntry from the root of the app.

2. Shared dependencies – You'll need to review your dependencies to make sure you share as many dependencies as possible to optimise bundle size and loading performance. You’ll also need to mark critical libraries (like React) as singletons to prevent runtime conflicts.

Runtime Challenges

1. Cross domain – if your remote is on a different subdomain, for example remote.website.com and is being loaded from host.website.com You’ll need appropriate handling for CORS on your server to allow data fetching from the host’s subdomain. You’ll also need an appropriate credentials fetch configuration to make sure the browser sends the authentication cookies in data fetching requests to your remote endpoints.

2. Styling conflicts – You’ll want to make sure the remote’s styles don’t override the host’s styles and that the remote components don’t inherit unintended styles from the host. There are multiple strategies here, from using styled components to a virtual DOM.

Operational Concerns

1. Observability and Analytics – Based on your requirements, you may want to either share an instance of your observability scripts, for example, an error monitoring service, or instantiate a completely different one within your MFE’s context. This becomes challenging, as there is no ‘index’ file being rendered, but rather components that are being exposed from the remotes.

2. Deployment & Caching – It’s recommended that MFE remote bundles be hosted on S3 buckets for high reliability as opposed to loading them from a remote server. You may require appropriate long-term caching for files other than the remoteEntry.js which is typically non-hashed and contains the link to other dependencies to be loaded.

Conclusion

Microfrontends offer a compelling solution for scaling frontend development across multiple teams, with Module Federation emerging as the most flexible modern approach.

While traditional methods like server-side composition remain valuable for specific use cases, Module Federation provides the runtime flexibility and performance characteristics needed for complex applications.

The decision ultimately depends on your team’s structure, technical requirements, and tolerance for implementation complexity. Start with simpler approaches if you're new to microfrontends, then consider Module Federation as your needs evolve.

What’s next?

This article was more about giving you a bird’s-eye view of the landscape. I’ll be writing more on Module Federation and going beyond the basics next. I’ll cover the technical challenges in more detail, along with possible solutions. Watch out for the same!

In this article, you'll learn what reactivity means, what signals are, and then you'll build your own implementation of Signals from scratch.

What We'll Cover

• What is Reactivity?

• What are Signals?

• How to Build Your Own Signals

• Conclusion

What is Reactivity?

Here's a generic definition for reactivity:

"Reactivity is the way a system reacts to data changes."

At it's heart, reactivity in UI applications refers to changes in the UI in response to changes in the data.

Having an understanding of how Reactivity works behind the scenes gives you a deeper understanding of some of the common paradigms that you already use when developing web applications. But it also helps deepen your understanding of the frameworks / libraries you work with on a daily basis that use Reactivity under the hood.

Here are some common paradigms where reactivity comes into play behind the scenes, along with some examples:

• React to data fetched from an API: Show loading / error / success indicators based on the state of data being fetched.

• Single data, multiple Reactive UI elements: In an ecommerce website, when an item is added to a cart, it should be marked as added and the cart badge's count should also increment.

• React to a task being completed: Show a checkmark when a user is done uploading an image.

• React to events: Show a promotional banner when a user is at the bottom of the page.

• Reactivity in CSS: Recalculate the spacing based on the height of the component via calc(--height).

Here are some of the popular frameworks / libraries and how they depend on Reactivity at their core:

React let's you save data in form of state via hooks like useState , anytime this state changes, the corresponding UI element where the state is used is also updated reactively.

Under the hood, React achieves this by re-constructing and comparing the Virtual DOM when some state updates so that it only updates the relevant part of the UI element on the screen.

RxJS uses observables to produce data and observers to consume that data, notifying them whenever new values are produced. You can read more about this here.

Vue uses objects and proxies to provide reactivity via ref(). Proxy, in a nutshell, lets Vue intercept when an object's property is accessed or set, which is the basis of its reactivity system. You can read more here.

SolidJS uses Signals to achieve fine-grained reactivity. This means that it can update specific parts of the DOM when data changes, without the need of a virtual DOM.

What are Signals?

Signals are an important concept in Reactivity within JavaScript. Signals can hold a value and then allow a piece of code to react to it when this value changes.

Signals allow you to manage the state in a more controlled manner. They also allow fine-grained reactivity where components can update selectively based on the specific state changes, rather than re-rendering entirely.

Different frameworks have their own implementations of Signals like I mentioned earlier (for example, Vue calls them ref, while Angular, Preact, Qwik call them signals) and they differ slightly in their implementations.

In this article, we'll try to rebuild signals from scratch as they exist within the SolidJS framework.

Signals in SolidJS

Let's start by understanding how signals work in SolidJS. Then we'll be recreating the same with just JavaScript.

**createSignal** is used to create a signal, takes initialValue as an argument, and returns a pair of getters and setters. Here's what this looks like:

const [count, setCount] = createSignal(0);
        ^ Getter   ^ Setter

Here:

• count() is used to access the value in the signal

• setCount(newValue) is used to set a new value in the signal

The **createEffect** function allows arbitrary code ("side effects") to be reactive and re-run whenever its dependencies change. It accepts a callback function and re-executes this function whenever any signal dependencies accessed within the callback change.

Unlike effects in React, there is no need to explicitly list dependencies in an array. createEffect automatically determines signal dependencies by tracking which signal getters are accessed within the callback.

const [count, setCount] = createSignal(0);

// Runs once with value at this point in time
// Print 0
console.log(count());

createEffect(() => {
    // Prints 0
    // Prints 1
    console.log(count());
});


// Updates the count to 1
setCount(1);

In the above example, the first console.log is printed only once, as SolidJS runs everything just once, whereas the callback within the effect runs every time the "count" signal's value is changed.

How to Build Your Own Signals

Let's try to re-build a simpler implementation of the above demonstrated SolidJS Signals by breaking it down:

• Implement Signal Class – which manages handling of a Pub-Sub mechanism to power createSignal

• Implement **createSignal** – uses the Signal class to implement this function, which should accept an initial value & returns getter & setters.

• Implement createEffect – runs the callback provided to it once, and re-runs it when a signal value changes

Implement the Signal class

This class will use the Pub-Sub pattern, which means it should:

• Maintain a value and provide a getter to access this value

• Maintains a list of subscribers as an array and a method to subscribe

• Provides a setter to set a new value and communicate the updated value to all subscribers

class Signal {
  constructor(value) {
    this.value = value;
    this.subscribers = [];
  }

  getValue() {
    return this.value;
  }

  setValue(newValue) {
    this.value = newValue;
    this.emit();
  }

  emit() {
    this.subscribers.forEach((subscriber) => subscriber(this.value));
  }

  subscribe(callback) {
    this.subscribers.push(callback);
  }
}

A use case for the above may look like this:

const signal = new Signal(0);

// Subscriber callback is re-run by the class when value changes
signal.subscribe((value) => console.log(value));

// There can be as many subscribers
signa.subscribe(...);

// Updates the value within the class
// Emits the value to all subscribers
signal.setValue(1);

The subscribe method pushes callback functions provided within an array of subscribers while setValue calls the emit method which loops through those subscribers and runs each subscriber callback with the newValue.

Implement the createSignal method

Let's try to use the above to implement a createSignal method which should:

• Accept an initial value as an argument

• Return an array of getter and setter methods

export const createSignal = (value) => {
  const signal = new Signal(value);

  return [
    function value() {
      return signal.getValue();
    },
    function setValue(newVal) {
      signal.setValue(newVal);
    },
  ];
};

const [value, setValue] = createSignal(0);

// Logs 0
console.log(value());

setValue(1);

// Logs 1
console.log(value());

The above createSignal creates a new instance of the Signal class with the initial value provided to it.

It currently also returns a getter and setter which internally calls the respective getter and setter of the signal instance.

You'll notice that we're still writing console.log(value()) twice manually when we want to access the latest value() as there are no subscriptions to the signal yet.

We'll achieve that with createEffect's implementation next.

Implement createEffect

Our createEffect should:

• Receive a callback as an argument

• Execute the callback once, immediately

• Subscribe to the signals used within the callback

export const createEffect = (callback) => {    
  // Let's execute the callback
  callback();

  // Wait how do I subscribe?
};

So you might be wondering: how can I possibly know whether this callback uses a signal getter or not?

Short answer is, you can't. As createEffect is a generic method, it can't possibly know what signals are being used within the callback passed to it. It can only execute this callback with different arguments at the very best.

If we think differently, there is still a way this function can communicate with the code within the callback (getter).

Let's introduce a new variable, effectCallback, which is an intermediate variable used to communicate between the effect and signal getter method. This variable should hold the callback that an effect receives.

An effect registers a callback subscription based on signal's getter that has been accessed within it.

Let's modify our createSignal code to handle that:

export const createSignal = (value) => {
  const signal = new Signal(value);

  return [
    function value() {
      // Subscribes the effectCallback if exists
      if (effectCallback) {
        signal.subscribe(effectCallback);
      }

      return signal.getValue();
    },
    function setValue(newVal) {
      signal.setValue(newVal);
    },
  ];
};

Let's see when we can set the effectCallback. We know that createEffect should execute the callback immediately once, which means we can capture the callback in this variable before executing it and clear it up after it's done executing the callback.

export const createEffect = (callback) => {
   effectCallback = callback;
   callback();
   effectCallback = null;
};

Putting everything together:

let effectCallback = null;

export const createEffect = (callback) => {
   effectCallback = callback;
   callback();
   effectCallback = null;
};

export const createSignal = (value) => {
  const signal = new Signal(value);

  return [
    function value() {
      if (effectCallback) {
        signal.subscribe(effectCallback);
      }

      return signal.getValue();
    },
    function setValue(newVal) {
      signal.setValue(newVal);
    },
  ];
};

Here is a CodeSandbox where you can play around with this code.

The order of execution would be something like this:

• createEffect is executed with a callback function, and the same is stored within effectCallback.

• The callback is executed and will invoke any getter signal methods used within it.

• The getter method value within createSignal is executed and enters the conditional which checks whether the getter is accessed from within an effect callback.

• The callback is subscribed for any further value changes and re-executes when setter is called.

Here's something to help you visualise this process:

Diagram illustrating order of execution of the final solution

This was of course a rudimentary implementation of the concept.

SolidJS does a lot of things under the hood which can include:

• Optimisations: a signal will maintain its observers until they're manually disposed. This can become complex in web apps where nesting is common.

• Allowing a way to batch updates

• Supporting async subscribers

and much more.

Conclusion

In this article, we explored the concept of reactivity and its role in web applications. We examined how various frameworks implement reactivity, with many using signals as a foundational mechanism.

By breaking down the SolidJS implementation of signals, we created our own version from scratch using the Pub-Sub pattern.

I hope this provided you with valuable insights into reactivity, signals, and enhanced your understanding of JavaScript.

Whether you're forced to use VIM at your workplace or you're a mad VIM fan like I am who obsesses about productivity, the project-wide keyword search is a basic requirement every developer needs in their editor's arsenal. And we expect it to be blazing fast. ⚡️

I've been using VIM for about 3 years now. And coming from a Sublime background, the need for project-wide search was essential.

ripgrep and ack.vim were things I adopted early on after my unfulfilling experiences with grep and the_silver_searcher(ag). I haven't looked back since then.

This article is the result of experimenting with different search tools and incremental improvements I made over a period of time until it felt just right.

Why ack.vim & ripgrep?

1. Fast: I've worked on Symfony and JavaScript projects with thousands of files and it is just blazing fast. Here's a quick comparison with other search tools.
   My benchmark for speed is, "it should never feel slow". I noticed a tremendous improvement after I moved from grep, the_silver_searcher and ack.

2. Quick navigation: ack.vim takes care of populating the Quickfix list, which lets you conveniently move through all those search results across different files.

3. Sensible defaults: ripgrep by default considers gitignore and automatically skips hidden files/directories and binary files.

Overview

ack.vim is a VIM plugin that acts as a wrapper to search keywords and populate the Quickfix list for navigating the results.

ripgrep (rg) is a command-line tool that ack.vim will internally use to perform the actual project-wide search.

Steps

Step 1: Install ripgrep

If you prefer Homebrew like I do, run the following to install rg:

brew tap burntsushi/ripgrep https://github.com/BurntSushi/ripgrep.git
brew install burntsushi/ripgrep/ripgrep-bin

Here's an automated script which I use as part of my dotfiles.

If you prefer any other mode of installation, refer to ripgrep's official installation section.

Step 2: Install ack.vim

To install ack.vim using the vim-plug package manager, add the following in your vimrc:

Plug 'mileszs/ack.vim'

or refer to the ack.vim's installation section.

Step 3: Configure ack.vim to use rg

Add the following configuration in your vimrc:

" ack.vim --- {{{

" Use ripgrep for searching ⚡️
" Options include:
" --vimgrep -> Needed to parse the rg response properly for ack.vim
" --type-not sql -> Avoid huge sql file dumps as it slows down the search
" --smart-case -> Search case insensitive if all lowercase pattern, Search case sensitively otherwise
let g:ackprg = 'rg --vimgrep --type-not sql --smart-case'

" Auto close the Quickfix list after pressing '<enter>' on a list item
let g:ack_autoclose = 1

" Any empty ack search will search for the work the cursor is on
let g:ack_use_cword_for_empty_search = 1

" Don't jump to first match
cnoreabbrev Ack Ack!

" Maps <leader>/ so we're ready to type the search keyword
nnoremap <Leader>/ :Ack!<Space>
" }}}

" Navigate quickfix list with ease
nnoremap <silent> [q :cprevious<CR>
nnoremap <silent> ]q :cnext<CR>

Note: let g:ackprg defines the command which ack.vim will internally run.
Also note that we're using rg here with some options. Look at the man rg to modify the options that may meet your requirements.

To explore options for ack.vim, look into the following documentation.

Usage

Now that we're up and ready, here are the most common use-cases:

Look for a word under the cursor

Press / followed by enter.
Since we've set let g:ack_use_cword_for_empty_search = 1, Ack falls back to the current word under the cursor for the search, so no need to type that word.

Word search

Press / followed by the word (without any quotes) & enter.
Since we're using smart case with ripgrep, that'll do a case insensitive search if the word is all lowercase, and a case sensitive search otherwise.

word search with ack.vim

Regex search

Press / followed by a regex pattern in quotes & enter.

regex search with ack.vim

Navigation through the results

Ack.vim populates the results in the Quickfix list, which opens up as a separate bottom window. There are multiple ways to navigate the results list:

• You can navigate the Quickfix list using j/k and press enter to close the Quickfix list. VIM will take you to the exact location of the found word.

• You can also use the hotkeys ]q or [q. VIM will move the cursor to the next/previous result and will open the file in a new buffer if required.
  To close the Quickfix list once you're done, you can either go to the bottom Quickfix window and close it or just run :cclose

• To open the Quickfix list back up, run :copen

Closing Note

And there you have it, a seamless search and navigation for your next project-wide keyword search!

If you're stuck anywhere, look for the respective ack.vim and ripgrep docs/issues in their respective repositories, or send me a message. Share the configuration you're proud of, so it can help others improve theirs.

Here are my dotfiles.