Feature Flags explained with Laravel

Hi folks!! It has been a while since my last write-up. At this time, I’ll try to explain the Feature Flags pattern, described by Pete Hodgson in Martin Fowler’s blog, and how to apply its principles in a PHP application using Laravel Framework.

Feature toggling is a pattern that allows running or not a piece of code. It brings us the ability to deliver new functionalities to production in a safe and fast way.

Sound good? As a starting point, we can take a look at the trade-offs that come with it.

PROS:

• Safe Delivery: We can deliver production code and enable it only for developers and stakeholders involved in the feature validation. Once the matter is validated, we can open it for everyone.
• Partial Delivery: In complex or huge developments, the pattern allows the delivery of incomplete parts of code. These parts will not execute until each of the required pieces for its operation is complete.
• Segmented Delivery: We can put a specific feature in production for a group of users segmented by business logic. For example, put some marketing campaign for people accessing from some location.
• Experimentation: Perfect for A/B testing and also for multivariate tests.
• Disaster preparedness: When everything goes wrong, and we deploy a 500 error to put an example. We can use the kill-switch pattern. It turns off the failing feature and leaves the system running again as before we made a mistake.

CONS:

• Inherited complexity: Every of the described benefits carries a new cognitive charge to the team, like conditionals, polymorphism, forgotten features, and so on.
• Technical debt: Following the previous con, it forces us to deal with dead-code. Also, the toggles themselves require maintenance for deleting unneeded flags.

We can enumerate a few use cases where the pattern will work using the Laravel PHP framework and Pheature Flags PHP library.

Now we are going to install the feature toggling library In our running Laravel PHP.

composer require pheature/laravel-toggle pheature/php-sdk

Don’t forget to publish the newly installed vendors.

php artisan vendor:publish --provider="Pheature\Community\Laravel\ToggleProvider"

Now we are ready to start explaining the different Toggle types using PHP examples. The complete repo is available on Github.

Release Toggles

Allow us to deliver untested or incomplete code to production, which will possibly never run. A release toggle is a handy tool when you are part of a trunk-based development process, where all the teammates hit against the main branch.

Code Examples:

In the following example, we have a flag named “release_toggle_example_1”. When this toggle is enabled, the application will execute the “already_un_existent_view” code path.

As its name says, this view has not any implementation, and the code will fail. But we can put this code in production confidently because if we disable the flag, it always will go from the “welcome” template path, and everything will continue working perfectly.

Ops Toggles

The Ops toggles works for delivering features with performance implications. They usually have a short life. Once the doubt is clear up, it will not be required anymore.

In complex systems, we can have some long-lived flags. For example, for the cases when we may want to disallow some slow part on unexpected high traffic moment, or a prime-time marketing campaign.

Code Examples:

In the current example, we are trying to move the product creation to a queue to avoid interacting with the database in the HTTP request scope. This action may have unexpected side effects. With the ops toggle, we can test the performance and analyze the possible undesired behaviors. Once we make a decision, we can enable or disable the new functionality.

Experiment Toggles

We use the experiment toggles to compare the behavior between different code paths. It places each user in some segment and drives them to the expected feature depending on their segmentation value.

The pattern is also known as A/B Testing or Multivariate Testing.

Code Examples:

In this example, we will show a custom view to logged users located in Barcelona. Every other visitor will go to the default path.

Permission Toggles

We put permission toggles in the parts of the application where some users need to run extra functionalities depending on their roles, for example, giving custom features for beta-testers or paid users.

Code Examples:

The permission toggle example will show customized data depending o the logged user account type. We want to add more value to our paid users, showing them some additional sections to the website.

When dealing with several flags of different types, we need to avoid technical debt. To do so, we have to take care of two concerns: longevity and dynamism.

Dynamism

The more dynamic the feature is more complex will be the routing to the correct code path. It means that flags of the types of Permission toggles and Experiment toggles need to evaluate requests on runtime. They will add more complexity and less performance compared to more static flag types like release toggles and ops toggles.

Longevity

The longevity of the toggle depends on its purpose. In the desired situation, we want to remove the experiment as soon as the hypothesis is validated. We can delete the release toggles as soon as the stakeholders validate the feature. Also, we may want to quit ops toggles as soon as we control the performance implications of the functionality. Usually, this will take more time than before mentioned types.

On the other side, some critical ops toggles and especially permission toggles will remain for a long time living in our systems.

I made the examples using the Laravel Framework. The concepts explained are perfectly applicable to any other PHP framework or programming language, the magic of the Software Architecture;-D.

Thank you so much if you reach here. I hope these lines will help you better understand what Feature Flags are, how and when to use them. Likewise, I highly recommend reading the pattern description given by Pete Hodgson.

Happy coding!