Microfrontends architecture

Microfrontends are a way of architecting your frontend application as a composition of loosely coupled features. Each feature is owned by a separate team, and can be developed and deployed independently.

In this guide, we will learn how Eventvisor and microfrontends architecture can complement each other, enabling your organization to ship faster with more confidence and control of your analytics.

Benefits#

Going deep into microfrontends architecture is not the goal of this guide. But we will briefly mention some of its key benefits:

• Development: Each team can develop their features independently allowing work to be done in parallel
• Tech stack: Each microfrontend can be developed using the technology that best suits the team
• Deployment: Each microfrontend can be deployed independently at their own pace
• Ownership: Each team can own their own feature and be solely responsible for it
• Rolling back: If a particular microfrontend breaks, it can be rolled back without affecting rest of the application

See this talk by Luca Mezzalira for further explanation here.

Challenges#

With all the freedom and autonomy, microfrontends architecture also comes with its own set of challenges, including when it comes to governance and control of your analytics events:

• Consistency: It can be hard to maintain consistency of all tracked events across all microfrontends
• Overlaps: Some events may overlap across multiple microfrontends
• Reviews and approvals: It can be hard to keep track of and coordinate all the events and their changes across all microfrontends

Rest of this guide will help us understand how Eventvisor can help mitigate these concerns in your team and organization.

Your application#

Imagine you have an e-commerce application, where you offer your users the ability to:

• browse products
• sign up and in
• add to cart and buy products, and
• manage their account

We can approach it as a microfrontends architecture next.

Mapping activities against microfrontends#

We can map all these activities to their own microfrontend as follows:

Each microfrontend will be accessible via its own URL path, like yoursite.com/products, yoursite.com/signup, etc.

Configuring tags#

Your entire application can make use of several events. But given it is a microfrontends architecture, we want to make sure that each microfrontend only loads the events and relevant configuration it needs.

Instead of creating multiple Eventvisor projects for each of your microfrontends, we can have a single project that contains all the events and their configurations, and then build separate datafiles for each microfrontend.

To achieve that, we need to let our Eventvisor configuration know which tags we want to build our datafiles for:

module.exports = {
  tags: [
    'products',
    'signup',
    'signin',
    'checkout',
    'account',
  ],
}

Once this configuration is in place, we can build our datafiles:

$ npx eventvisor build

And it will output the following datafiles in the datafiles directory:

datafiles/
├── eventvisor-tag-products.json
├── eventvisor-tag-signup.json
├── eventvisor-tag-signin.json
├── eventvisor-tag-checkout.json
└── eventvisor-tag-account.json

Tagging definitions#

When we create or update any of our entities in your Eventvisor project (like events, attributes, destinations, and effects) we can tag it with the microfrontend it belongs to:

description: Button click
tags:
  - products # tagging with `products` microfrontend
# ...

It is possible some entities may overlap across microfrontends. In that case, we can tag the entity with both of them together:

description: Button click
tags:
  - products
  - checkout
# ...

Review and approval workflow#

Given Eventvisor is a centralized governance tool for all your events and attributes, it can help you manage your events in a microfrontends architecture in a single place conveniently.

In our case, it is a single Git repository that contains all the events and their configurations, which will go through a review and approval workflow by all relevant teams before they can be deployed in the form of generated datafiles.

Learn more in ownership page.

Consuming datafiles in your microfrontend#

Once you have built and deployed your datafiles, you can consume them using Eventvisor SDKs in your microfrontends:

// in `products` microfrontend
import { createInstance } from "@eventvisor/sdk";
const DATAFILE_URL = "https://cdn.yoursite.com/eventvisor-tag-products.json";
const datafile = await fetch(DATAFILE_URL).then(res => res.json())
const eventvisor = createInstance({
  datafile: datafile,
});

Benefits#

We have seen how we can use Eventvisor to manage all our event definitions and their routing configurations in a microfrontends architecture in a single place declaratively, even if those events overlap and are used in multiple microfrontends together.

The freedom and flexibility that microfrontends architecture brings in is great, but it also comes with its own set of challenges. Eventvisor can help you manage your events in a microfrontends architecture bringing all parties together with a strong reviews and approval workflow, and make sure your events are consistent across all your microfrontends for your users.