Unlocking Scalability with Smart Feature Gating Strategies

Feature gating is something most applications probably do, even if patterns are not formalised. Some typical examples:

• Authorisation (admins can access Feature X, but other users cannot)

• Feature toggles (Feature Y is still in development, or is only accessible by insiders)

• Plan limitations (basic plan does not get access to Feature Z, but pro plan does)

There are often many of these kind of gates within any application and they can cause significant maintainability issues over time. For this post we will be focusing on authorisation and plan limitations.

Feature gate examples

Let's look at some of the ways you can use features gates in your application. 

Authorisation - Role based access control

Most applications have some form of access control and it’s very easy to get wrong. The first mistake people often make with role based access control is to check if the user has a particular role. For example:

if (user.role === 'admin') {
  // Admin only functionality
}


This approach becomes extremely hard to scale over time because the implementation is missing an important concept, permissions. The better way to implement role based access control is that a role grants permissions and your code checks permissions, for example:

if (user.permissions.includes('some-privilaged-function')) {
  // The permission is protected, code doesn't know what roles the user has
}


This approach scales far easier. As the complexity of your application grows you can introduce new roles, or update roles very easily. It also becomes far easier to do a permissions audit to see what roles grant what permissions.

Plan limitations

For SaaS products you almost always want to gate some premium features behind certain plans. As with the above examples, we could make our code directly aware of the plans our product supports:

if (user.plan === 'pro') {
  // Some feature only available to pro users
}

And once again, this approach will end up being difficult to maintain. SaaS products have the added complication of sales wanting to sell custom plans, and over time you will want to restructure your plans, likely wanting to grandfather your current plans.

This can become a nightmare to manage, but the solution to manage this complexity is the same as role based access control. You need to couple your code to whether the user is allowed to see a feature, not to the logic which makes that decision. e.g.

if (isFeatureAvailable('my-premium-feature', user)) {
  // Some feature which is gated by some logic
}

Centralising decisions

The ‘pattern’ here is that your code should be gated to the concrete function you are protecting, ie limitations like the maximum number of users, a permission like being able to create a user rather than your code being coupled to the thing which grants that permission/entitlement (pro plan or admin role).

This is where FeatureBoard comes in, it has been designed to ensure your team models these types of problems consistently and in a scalable way.

Introducing audiences

Audiences are a generic way to think about and solve the above problem.

To start with, FeatureBoard gives you a number of Audience Categories which you can customise per project

In the above image we have a number of audiences under the Plans and Roles categories. If we take a look at the plans audience category