The Piral Feed Service is a commercially available micro frontend discovery service with a free tier that works for many solutions such as Webpack Module Federation, single-spa, Native Federation, OpenComponents, or Piral.

With the release 1.10 the Piral Feed Service adds some new powerful features that make it even more attractive for new teams - giving them some interesting capabilities such as standalone feature flags out of the box.

In this post we'll walk over some of the highlights of this release and how these features can impact your work.

Micro Frontend Infos

Previously, the Piral Feed Service only showed some information of a micro frontend such as the used version or the name of the micro frontend.

With the arrow icon on the right hand side you can now show additional information.

This is great to see what's the size of the micro frontend, how it's structured and what dependencies are there (and if they are shared).

In case of an uploaded README.md file you even get to see some documentation of the micro frontend:

This aligns quite well with previously available views such as the dependency view, which is available since quite a while:

All in all, it is now possible to inspect the published micro frontends even better - yielding all kinds of useful information.

Feature Flags

Many of our customers told us that the included feature flag / rule evaluation from the Piral Feed Service is more powerful and works even better than dedicated feature flag services such as LaunchDarkly, Split, or Azure Configuration. What was missing is a way to have dedicated or standalone feature flags, which are independent of micro frontends and could be used within micro frontends, or some other application.

This is now possible. Every feed has a new action item called "Manage Feature Flags".

Following this action you can create new feature flags using an identifier and description.

Once created the feature flags are available - and can also be fully toggled:

There is a dedicated URL to retrieve the available feature flags. Following the /api/v1/feature/{feed} URL you'd get a response that includes the flags property:

{
  "feed": "example",
  "flags": ["feature1", "feature2"]
}

Only the enabled features for the given request are listed.

For instance, if you have a rule for a feature "my-feature" like the following:

{
  "type": "query",
  "name": "access",
  "compare": {
    "type": "eq",
    "value": "456"
  }
}

then the flag would show only if /api/v1/feature/example?access=456 is requested:

{
  "feed": "example",
  "flags": ["my-feature"]
}

But not otherwise (e.g., /api/v1/feature/example?access=123):

{
  "feed": "example",
  "flags": []
}

The best thing about feature flags is that they are also a way to re-use rules across multiple micro frontends. Let's say you want to re-use the rules for my-feature above in two micro frontends, you can just create a single rule for each micro frontend:

{
  "type": "feature",
  "name": "my-feature"
}

This way, you can easily make feature flags your primary mechanism for toggling micro frontends, without having to duplicate their rules.

Publish Overrides

One thing that the Piral Feed Service implemented from the beginning is protection against version conflicts. As such it prevented publishing one micro frontend again using the same version.

While this is great and enables a lot of optimizations (e.g., micro frontends are ensured to be immutable and therefore can be cached indefinitely) it also comes with convenience drawbacks. To mitigate this a special "preview" property has been added to the package.json. If a micro frontend has

{
  "name": "my-mf",
  "version": "1.0.0",
  "preview": true
}

then the Piral Feed Service would always append a special preview suffix (e.g., making the version 1.0.0-pre.1234). The downside of this approach was that the property is part of the package.json and therefore not something that is easily enforceable, e.g., just for a certain branch or publish action.

Now, the Piral Feed Service supports various overrides such as version or preview:

# change the version to be a preview
npx publish-microfrontend --url ... --interactive --fields.preview on

# change the version to be 1.2.3
npx publish-microfrontend --url ... --interactive --fields.version 1.2.3

While the first call overrides the preview flag of the package.json (i.e., it does no longer require that or changes its value if that property exists), the second changes the provided version. Both overrides also work together.

Additional Rules

As mentioned, the rule engine provided by the Piral Feed Service is definitely a powerful one - and features many possibilities that make dynamic rule evaluation and feature management convenient and flexible.

One thing that was wished here was time-based evaluation. While this could be introduced via custom rules, we thought that this is a great generic addition that should not be missed here.

There are three new rule types here (not_before, not_after, and cronjob). The first two are also available in a new wizard:

If you follow the wizard you'll get the option to define a time window using a not before / not after date. The times are always given in UTC.

Using this you can easily either make your micro frontends expire (e.g., for a given deal you want to show some preview here, but once the deal is off the table you want to also hide the content of the micro frontend) or just go online at a certain point in time (your big rollout is on Monday 6am, but no developer will be available - just make sure to have everyone publish their micro frontend beforehand and set the rule to make the micro frontend available at Monday 6am).

In contrast, using cronjob is for re-occurring rules, i.e., when your micro frontend should only available on Sundays or during office hours.

For instance, the following rule will activate a micro frontend at 9am UTC for 3 hours every day:

{
  "type": "cronjob",
  "duration": 180,
  "hour": 9,
  "minute": 0
}

If the duration is skipped then it will match the whole day after the time is met.

Conclusion

The Piral Feed Service is the most powerful micro frontend discovery service. The free community edition is great to get started. To try the service in your environment you can either go the Azure Marketplace to obtain Azure Container Registry access or contact us to start a free trial of the full service.