Introducing: event type feature flags

Note: this feature has been out for a while, we just forgot to release this post. 😅

Sometimes when you're working on a new feature for your product you might want to put it in the hands of a select few customers to test-drive it before making it accessible to everyone. Or perhaps there's a feature that's only available to customers at a certain price or subscription plan. We recently added support for hiding event types behind feature flags to make it easy to support these scenarios, and this blog post will show you how.

Feature flags

But first, let's start with what feature flags, also known as feature toggles, are and how they can help.

In essence, feature flags are checks in the code of your product that determine its behavior based on some condition. It's commonly used to issue a software release incorporating a new feature without necessarily allowing users access to said new feature. Instead, you can gradually opt more and more users into the feature flag, ensuring that the new feature works as expected.

Or, perhaps you just developed a bespoke feature for a large enterprise customer but you don't want all your other webhook consumers to know about it. Feature flags can help you in both of these situations.

Event type feature flags

Now let's look at how you can use this pattern with Svix event types today!

When creating an event type you have the option of setting a feature flag on it. If a feature flag is set on an event type then only consumers with an access token bearing the same flag can see this event type in the event catalog.

To start, create an event type with a feature flag set:

import { Svix } from 'svix'

const svix = new Svix('AUTH_TOKEN')
const eventType = await svix.eventType.create({
  name: 'user.signup',
  description: 'A user has signed up',
  featureFlag: 'beta-feature-a',
})

The feature flag's name is controlled by you - it can be any string following the same naming rules as the feature flag itself, i.e. alphanumerics, dash, and underscore up to 256 characters in length.

Next, create a consumer access token, and make sure to set the same feature flag on it.

const dashboard = await svix.authentication.appPortalAccess('app_Xzx8bQeOB1D1XEYmAJaRGoj0', {
  featureFlags: ['beta-feature-a'],
})
// A URL that automatically logs user into the dashboard
console.log(dashboard.url)

When this access token is used to access the dashboard the user will see all the usual event types, but also the new one you just created.

As you may have noticed from the example above you can set multiple flags on a token and it will be able to see event types which have no feature flag set, or have a feature flag set that the token possesses in its feature flags.

You should incorporate setting the correct feature flags into your application's access token issuance process so each of your consumers see the event types you want them to be able to see.

Wrapping up

Once you are ready to release this new event type to all of your consumers you can simply update the event type and remove the feature flag from it. After that, all of your consumers will be able to see this new event type in the catalog.

const eventTypeOut = await svix.eventType.update('user.signup', {
  description: 'A user has signed up',
  archived: false,
})

If you remove a feature flag too early you can always add it back any time.

One last thing

It's worth keeping in mind that the feature flag only affects the event type's visibility in the consumer app portal and the event catalog. A message may still be sent to endpoints regardless of whether the event type has a feature flag set.

There are a few reasons for this, but the main one is that we don't want feature flags to be affecting the delivery of messages, especially given the complexity required both on our end, and our customers' end to support it. This is especially true since our customers control which messages are sent to which applications and thus they already know which events should be sent to whom. So adding this to Svix would have added little value.

For more content like this, make sure to follow us on Twitter, Github or RSS for the latest updates for the Svix webhook service, or join the discussion on our community Slack.