DEV Community: James

How to Use Feature Flags in Your Laravel Applications

James — Thu, 12 Mar 2020 16:15:50 +0000

Note: This article was originally posted on devsushi.co.

Feature Flags (sometimes known as Feature Toggles) are a useful way of changing the behaviour of a system without modifying the code itself.

Feature Toggles (often also referred to as Feature Flags) are a powerful technique, allowing teams to modify system behaviour without changing code.

Martin Fowler

Since discovering their benefits, I've been using feature flags, albeit sparingly, in my applications for a number of reasons.

Integrate incomplete features — if I'm working on a feature that isn't quite ready, but I don't want to maintain a feature branch for an extended period of time, feature flags allow me to integrate an incomplete feature.

Rollback of system functionality — Feature flags provide an extra safeguard against problems with a feature. If something unexpected happens, I can simply disable the feature without worrying about deploying a fix right away.

Schedule the release of a feature — If I want to schedule the release of a feature, usually I'd have to schedule an entire deploy at the time I want the feature to be made available. With feature flags, however, I can deploy with the feature "off" in advance and just schedule the triggering of it.

A/B testing — Since feature flags are a simple boolean on/off, they can be used to build a very simple A/B testing framework within an application.

Building a Feature Flag Manager

Note: This article uses Laravel 7 to implement feature flags, but they can be applied to any version.

👉 Get the code on GitHub

So how can we incorporate the benefits of feature flags into our applications? When building any new functionality, I like to see how I'll be interacting with it as a developer; how might we want to use our new "feature manager"?

// Retrieve the feature manager from the container
$manager = $app->get(FeatureManager::class);

// Request the feature
$feature = $manager->feature('my_feature');

// Check the status of the feature and execute code accordingly
if ($feature->enabled()) {
    // The 'my_feature' feature is enabled
} else {
    // The 'my_feature' feature is disabled
}

This is a simple but effective interface — we can quickly check the status of a feature and perform a different task depending on whether it's enabled or disabled.

Implementation

Now that we know how we want to use our feature manager, we can begin implementing it. Let's begin with a representation of a "feature":

<?php declare(strict_types=1);

namespace App\Features;

class Feature
{
    private bool $enabled;

    public function __construct(bool $enabled)
    {
        $this->enabled = $enabled;
    }

    public function enabled(): bool
    {
        return $this->enabled;
    }
}

This class will allow us to see whether a feature we've asked for is enabled, and will be returned when we request a feature from our manager later on.

Next we'll implement the mechanism that will actually retrieve the boolean value for a requested feature. This value could be stored in a number of different places, such as a native PHP array, a Redis cluster or a relational database. With this in mind, we'll first add an interface to support multiple implementations:

<?php declare(strict_types=1);

namespace App\Features\Adapters;

interface FeatureAdapter
{
    public function feature(string $name, bool $default = false): bool;
}

Our FeatureAdapter interface will act as a contract for our different adapter implementations. It also allows us to specify a default value if we can't find the flag requested. For our first implementation, let's create a native PHP array adapter:

<?php declare(strict_types=1);

namespace App\Features\Adapters;

class ArrayFeatureAdapter implements FeatureAdapter
{
    private array $features;

    public function __construct(array $features)
    {
        $this->features = $features;
    }

    public function feature(string $name, bool $default = false): bool
    {
        if (!isset($this->features[$name])) {
            return $default;
        }

        return $this->features[$name];
    }
}

Our ArrayFeatureAdapter takes an associative array of features as its sole argument. The feature method is petty self-explanatory; it will search the array by key for the feature name and return the associated value if found.

Now that we've created our first adapter, it's time to add the manager itself. This will take in an instance of the adapter we want to use as it's only constructor argument:

<?php declare(strict_types=1);

namespace App\Features;

use App\Features\Adapters\FeatureAdapter;

class FeatureManager
{
    private FeatureAdapter $adapter;

    public function __construct(FeatureAdapter $adapter)
    {
        $this->adapter = $adapter;
    }

    public function feature(string $name, bool $default = false): Feature
    {
        return new Feature($this->adapter->feature($name, $default));
    }
}

The manager simply forwards our feature request to the adapter itself before wrapping it in the Feature class we created at the beginning. This helps abstract the inner workings of our adapters from the rest of our application by maintaining a consistent interface.

Putting It All Together

Before we can use our FeatureManager, we'll need to bind it to our container with our chosen adapter:

<?php declare(strict_types=1);

namespace App\Providers;

use App\Features\Adapters\ArrayFeatureAdapter;
use App\Features\Adapters\FeatureAdapter;
use Illuminate\Support\ServiceProvider;

class AppServiceProvider extends ServiceProvider
{
    public function register(): void
    {
        $this->app->bind(FeatureAdapter::class, static function () {
            return new ArrayFeatureAdapter(config('features'));
        });
    }
}

Here's what our feature config (config/features.php) looks like:

<?php declare(strict_types=1);

return [
    'feature_one' => true,
    'feature_two' => false,
];

We've defined two features; feature_one which is enabled, and feature_two which is disabled.

We can test it out in a controller like so:

<?php declare(strict_types=1);

namespace App\Http\Controllers;

use App\Features\FeatureManager;
use Illuminate\Contracts\Support\Renderable;

class IndexController extends Controller
{
    private FeatureManager $manager;

    public function __construct(FeatureManager $manager)
    {
        $this->manager = $manager;
    }

    public function index(): Renderable
    {
        $featureOne = $this->manager->feature('feature_one');
        $featureTwo = $this->manager->feature('feature_two');

        dump($featureOne->enabled()); // true
        dd($featureTwo->enabled()); // false
    }
}

Bonus: Additional Adapters

The ArrayFeatureAdapter we created earlier is all well and good, but we'd still need to deploy code to update a feature flag — something that we're trying to avoid. Below are a couple of examples that would allow us to manage flags "remotely". Better still we could eventually build a UI around them to make toggling features even easier.

Eloquent Adapter

An obvious choice for feature flag storage is a database table. Since we're using Laravel here, we'll use Eloquent to access them. We'll start with a migration to create our features database table.

<?php declare(strict_types=1);

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

class CreateFeaturesTable extends Migration
{
    public function up(): void
    {
        Schema::create('features', static function (Blueprint $table) {
            $table->id();
            $table->string('name');
            $table->boolean('is_enabled');

            $table->unique('name');
            $table->index('name');
        });
    }

    public function down(): void
    {
        Schema::dropIfExists('features');
    }
}

Next, we'll create the accompanying Feature model for the features table.

<?php declare(strict_types=1);

namespace App;

use Illuminate\Database\Eloquent\Model;

class Feature extends Model
{
    protected $casts = [
        'is_enabled' => 'bool',
    ];
}

Our model will automatically cast our flag values to a boolean for us.

Finally comes the adapter itself. This is straight forward too:

<?php declare(strict_types=1);

namespace App\Features\Adapters;

use App\Feature;

class EloquentFeatureAdapter implements FeatureAdapter
{
    public function feature(string $name, bool $default = false): bool
    {
        $feature = Feature::where('name', $name)->first();

        if (null === $feature) {
            return $default;
        }

        return $feature->is_enabled;
    }
}

Here we find the feature by its name. If we can't find it, we merely return the default value. All that needs to change in order to use this adapter is our service provider:

<?php declare(strict_types=1);

namespace App\Providers;

use App\Features\Adapters\EloquentFeatureAdapter;
use App\Features\Adapters\FeatureAdapter;
use Illuminate\Support\ServiceProvider;

class AppServiceProvider extends ServiceProvider
{
    public function register(): void
    {
        $this->app->bind(FeatureAdapter::class, EloquentFeatureAdapter::class);
    }
}

Redis Adapter

A Redis adapter would pretty much follow the same approach as the other adapters we've created. First we'll need to install the predis/predis package:

composer require predis/predis

Here's the adapter itself:

<?php declare(strict_types=1);

namespace App\Features\Adapters;

use Illuminate\Support\Facades\Redis;

class RedisFeatureAdapter implements FeatureAdapter
{
    public function feature(string $name, bool $default = false): bool
    {
        $feature = Redis::get($name);

        if (null === $feature) {
            return $default;
        }

        return (bool) $feature;
    }
}

Much like the Eloquent adapter, we request the value and, if it exists, return it. Again, we just need to update our container binding to use it:

<?php declare(strict_types=1);

namespace App\Providers;

use App\Features\Adapters\FeatureAdapter;
use App\Features\Adapters\RedisFeatureAdapter;
use Illuminate\Support\ServiceProvider;

class AppServiceProvider extends ServiceProvider
{
    public function register(): void
    {
        $this->app->bind(FeatureAdapter::class, RedisFeatureAdapter::class);
    }
}

That's It!

We've outlined the benefits of using feature flags and I've shown how they can be implemented in a Laravel application. Of course they can be easily adapted to any application — you'll just need to change how you register the feature manager with your container.

I'd advise against using feature flags absolutely everywhere, but when used sparingly they can certainly provide freedom and flexibility in how we develop and deploy features.

Thanks for reading! Don't forget, you can get all of the code you've seen here on GitHub. If you enjoyed the article, consider sharing it or giving me a follow on Twitter, and stay tuned for more ✌️

Building a Micro-SaaS - Part One: Starting the Journey

James — Tue, 18 Feb 2020 10:58:52 +0000

Welcome to part one of the Building a Micro-SaaS series! This is an opening article that will introduce the product, talk about first steps and set us up for the rest of the series. Thanks for joining; I hope you'll stick around.

I'm going to start by saying that this is going to be a learning experience for all of us — I am by no means an expert in launching online businesses (quite the opposite actually). It should, however, be an enjoyable learning experience for us all.

My vision for the series is to document every step of the way in building adsoup.co — a display advertising platform that caters to indie software makers looking to promote their products. Here are some of my planned topics:

The problem and reasoning
Planning
Tech stack considerations
Individual feature design & development
Marketing

In my eyes, if it's a success then hopefully there will be some actionable takeaways for people looking to launch their own Micro-SaaS. If it's a failure, then perhaps it will act as a guide on how not to build a Micro-SaaS. Only time will tell.

Finally, I think it's worth mentioning that my background is in software development, so many of the articles may have a more technical bias. I'll try and keep this to a minimum to benefit as wide of an audience as possible. I think that's enough of an introduction, so let's begin...

A solution to a problem

So you've just launched your hot new SaaS - how are you going to market it? Newsletters? Social media? Monthly sacrifices to the black box that is Google? There are plenty of directories that makers can submit their software for others to find, but many of these rely on users visiting and browsing the directory. What about those who don't know about Product Hunt, or don't realise they need your product to actively look for it?

Adsoup aims to solve these issues by pushing awareness of a product from beyond the confines of a discovery platform and out into the wilderness of the Internet. In a nutshell, makers can add their product, build a creative (ad) and promote it on a CPM basis. On the flip side, publishers can earn by displaying these promotions alongside their content.

More than just an advertising platform?

At first glance, Adsoup may seem like an advertising platform. Well, in some regards it will be, at its core. The value proposition, however, will lie in how it caters specifically to online software businesses — for both the advertising and publishing aspects. This proposition will be met in several ways, all of which will be explored as the series progresses.

From launch, the aim will be to onboard as many diverse software products onto the platform and an army of excellent publishers to drive awareness. Starting small and steady allows a level of flexibility that you just can't achieve if you go all-in on the biggest, coolest functionality.

Where to begin?

So we've defined the problem, and we've touched on how Adsoup will attempt to solve it. Where on earth to begin? Well, in typical fashion, Adsoup has entered the world as many fledgeling SaaS products do — as a simple pre-launch landing page with an email signup form. This is a common strategy as it carries the following benefits:

Allows gauging of interest without actually building the product;
Supports the gathering of feedback from the target audience before committing to anything major;
Gives the option of promoting the product and generating hype through newsletters.

Not disregarding the above, the main reason we're collecting pre-launch signups is to try and counter the dreaded chicken and egg problem. As a sort of marketplace, the platform will be dependent on both "buyers" (advertisers) and "sellers" (publishers). Without a decent number of both, the platform simply won't work. Of course, there are other tactics we can employ to offset this problem, some of which we'll explore at a later date.

Lastly, with such a heavy reliance on email at the early stages of our product, it makes sense to squeeze every bit of value out of each signup. One way in which we can do this is by introducing a referral scheme. We'll be exploring this in the next issue of the series.

Up next...

That about concludes the first article in the Building a Micro-SaaS series.
Now that you're a devoted reader, please don't hesitate to get in touch on Twitter if you have any feedback, or if there's anything specific you would like me to cover in future instalments. Next time we'll cover the implementation of the landing page, with special consideration to the newsletter referral system. This is a custom build on top of Mailchimp, so make sure to keep an eye out for that!

I want Adsoup to be a formidable tool available to all types of indie makers, and to achieve that we'll need a community of amazing people. If the product sounds like something you'd be interested in, please do signup at adsoup.co. All pre-launch signups receive a 12.5% CPM rate improvement. That means a 12.5% CPM discount if you're advertising your product, and a 12.5% increase in earnings if you're a publisher.