Photo by Vladislav Klapin on Unsplash
Introduction
Laravel Pennant is now available (although, at the time of writing, Pennant & Laravel 10 do not have stable releases). This means that more and more people will be learning about the concept of Feature Flags and how they can improve the developer experience and product management of their Laravel applications.
That said, the official package comes after several community-created packages that took different approaches to implement feature flags. In this article, I will briefly examine these popular packages, including the one I maintain, Feature Flags for Laravel.
What problem does using Feature Flags solve?
Feature Flags are a solution that is primarily aimed at those who are doing continuous integration.
To explain, if you don’t know what continuous integration is, code is constantly merged into your main branch and regularly deployed to move quickly and avoid things like merge conflicts. Continuous integration typically requires that you have lots of automated tests, but you will soon find this isn’t enough. Instead, it would be best if you also began to build feature flags.
Imagine this scenario. You’re building a new feature for your application, which requires communication of the end product with the users, training for your support team, and marketing, who wants to make a campaign to shout about the changes to customers. This is where feature flags come in. You will build your feature, merge it and deploy it but stop your end users from accessing it until your business is ready. Once everyone else has caught up, you change the application's state without merging or deploying new code, and now customers will have their shiny new feature to play with.
All of this can be complex to reach. How do you start segregating the functionality you want to be used versus the functionality you don’t want to be available when deploying code changes?
That’s where feature flags come in.
Do you even need a package for Feature Flags?
Honestly? It’s absolutely possible to implement feature flags using the mechanisms available in Laravel itself or with just small amounts of code. Laravel has something called Gates and Policies. These two together make it easy to control user activity in your Laravel app by calling the allows method on a Gate or a Policy. This will do what you want but will lead to more difficulties as your app scales.
This approach will mean that you must create a persistence layer for features. If you decide on using a gate, you’ll have to determine how it will store the flags. For example, it could be in the config and models, but be wary that feature flags might be accessed multiple times per request in every request that occurs and become a bottleneck for performance.
If this isn’t for you, you’d best look at one of the four following packages to help develop feature flags in your application.
The Laravel Pennant Alternatives
Spatie’s Flags Package
GitHub - spatie/laravel-model-flags: Add flags to Eloquent models
Spatie’s package is a relatively new entry to the Feature Flag space. The package itself is pretty simple and focuses on models completely. The implementation requires you to add and run a migration. Afterwards, you may use a provided trait on any models you have, allowing you to store boolean flags per model.
This is mainly about having a superficial persistence layer to control feature sets for, say, your Users or if you implement a Team model. This is fine but requires you to rely on things like Gates and Policies to perform checks on the User.
There’s no integration with the Laravel framework in any other sense, so you’ll need to create a Middleware or Blade directive to check if the user has the flags expected.
JustSteveKing’s Package
GitHub - JustSteveKing/laravel-feature-flags: A simple to use Feature Flag package for Laravel
This package is quite good in that, in the same way as the Spatie package, it interacts with the models, allowing you even to apply models to groups, something I’m sure many will want to do. You will need to add a migration to your app to install a persistence layer that your models can use with a trait.
The package allows you to interact with blade templates to isolate sections based on the page. Steve King’s package can also let you apply middleware that restricts the routes, but that’s about as far as it goes into the Laravel framework itself.
One of the neat features in JustSteveKing’s package is the TimeBomb feature. Something I can see many people wanting. TimeBomb allows you to throw an exception for a flag you no longer wish to exist in your app. Doing this means it’s easier to clean up your code as you decide to retire some flags.
ryangjchandler’s Package
GitHub - ryangjchandler/laravel-feature-flags: An opinionated feature flags package for Laravel.
I won’t waste a lot of time here. Ryan Chandler’s package is nearly identical to Steve King's. It equally allows for some integration with the framework via blade and middleware while also allowing you to manage the flags against models.
That said, one bonus feature to using Ryan’s package is first-party support for a UI using Filaments. Filaments is a component framework for Laravel Livewire designed around building an admin dashboard. If you’re using Filaments, this might push you into choosing this package over the others.
YLS Ideas’ Package
GitHub - ylsideas/feature-flags: A Laravel package for handling feature flags
Unlike the other packages mentioned, this one works with a pipeline (in version 2, at least). This means you can be selective of which features are used and where the flags persist. Nothing is stored against models. Instead, by default, you may store flags in a table, Redis or PHP file or even use Laravel’s built-in gate system. You can even use all of these in the pipeline, allowing you to query different places. There is also a cache mechanism available to reduce the time taken to discover the flag state for apps built for large scale. This means you can’t store flags against a User, unlike the other three packages or Laravel Pennant, which use this as their primary mechanism.
It is possible, though, to quickly implement your Gateway in this package if you wish to develop more complicated mechanisms, such as implementing Spatie’s package and using it to check if the user has a flag via a gate.
One of the advantages is like JustSteveKing’s package in that there are integrations to Laravel itself with the YLS Ideas package. It can perform the same tricks with blade templates and middleware but extends this further with validation rules and task scheduling based on the flag's status. A recently added feature was for a maintenance mode driver that will appeal to many who wish to control how an application might display maintenance mode in a few different scenarios.
If you want to use Feature Flags for Laravel, there is a tutorial for getting started and a dedicated documentation website.
Laravel Pennant Itself
It’s hard not to think that Laravel Pennant isn’t the best option, as the Laravel team will always maintain it. I’ve already tried it out, and it’s hard not to love it. The API for interacting with flags using different ‘Scopes’ (think Users or Teams) is cleverly simple.
At the moment, Pennant only supports the Database for persistent storage, but additional drivers can be created, so I’m sure more will be available soon.
One drawback for some is that you will need to use Laravel 10 to work with this package, but that likely won’t affect those starting new projects after this month.
Conclusion
It’s certainly not easy to suggest one particular option over the other. You’ll often need to start by thinking about how you’d like such a system to work within your app and then go from there.
While all of these packages are great, they need a well-thought-out and specifically designed user interface component to work in a more enterprise environment. This can make using feature flags challenging to scale. This is why I recently announced that I would work on something called Flagfox.
Flagfox is a premium package for Laravel designed to provide the frontend and UI experience for managing feature flags so that non-developers can enable and disable functionality when needed without having to perform any new deployments.
This will make the journey to having a full feature flagged application more straightforward than any current options available.
The landing page for Flagfox is already up, and a waiting list is available to join.
I’m Peter Fox, a UK software developer with a decade of experience with PHP and Laravel. I’ve started work on a new project. Flagfox for Laravel will build upon my established work creating open-source packages to help developers add feature flags to their applications. We currently have a waiting list for those interested in learning more.
Top comments (0)