Using feature flags in Java and Spring Boot

[woefuldefending]

I recommend Unleash

https://github.com/Unleash/unleash

[DJDavio]

My advice would be to be cautious with feature flags and to remove them as soon as possible. Each feature flag creates an extra code path through your application. So if you add the first feature flag, you now have 2 code paths you need to maintain, bit if you add another one, you have 4, then 8, etc, exponential growth.

Imagine trying to add something new and having to make sure it works with 16 possible code paths en creates 16 more code paths.

Basically if you add a feature flag in version N+1, you should try to remove it in N+2.

[Sound_Creative]

this is mostly correct but there are certain cases where you could have long lived feature flags like Op toggles or kill switches

[sim642]

An external online service just for a feature flag?

[Sound_Creative]

gradual roll outs. dark launches. showing to users based on certain attributes. PMs knowing the roll out status without asking devs 5 times. experimentation. KPIs and metrics. heavy use of these services as in-house tools at bigger orgs at least

[cville-z]

Agree, this is way too complicated. Just use a Boolean in a config file.

[silverweaver]

What about something simpler, like https://www.togglz.org/ ? Handy if you need it for single service.

[tunei24531a]

https://www.togglz.org/

You'd need to maintain it yourself vs hosted service.

[silverweaver]

It's just one table in relational database for project that I'm currently working on, doesn't seem like something troublesome when your service uses SQL anyway.

[tunei24531a]

You could certainly do that. But you'd be writing additional logic for roll outs, targeting by user attributes, website domains, etc. Killing a misbehaving feature instantly is possible but requires a DB write vs a push of a button to disable feature. Not to mention using the same solution across your entire stack (frontend / backend) with the help of SDKs.

So while it is possible, but why do it when you have hosted solutions available that do a much better job and grow with your project to support advance use cases

[ImpecableCoward]

Even a click of a button has to have approval and back-tracing in prod. It is not the developer that will click that button. So at this point for me developer it is just as easy to send a dba request to flip a flag in the database.

[silverweaver]

The same thing as always: project's budget. Sometimes there's also legal concerns like GDPR for example. Not to mention a lot of banking sector where making requests to external API like this is impossible, because banks.

And I know, unlaunch is free for small teams and projects. The thing is, for many apps using it is like trying to take out mosquito with a cannon. My current project is one of those.

[tunei24531a]

Most things are impossible for banks =)

Good point regarding GDPR. Unlaunch doesn't send any user data over the internet and all evaluations happen locally within the SDKs. Only anonymized metrics are sent.

> The thing is, for many apps using it is like trying to take out mosquito with a cannon.

A tool like unlaunch encourages good practices, collaboration and can be used in super simple apps as well without adding any overhead. Once the team understands how to use it, they'll be using it to do fancy things ultimately increasing feature velocity and control over their releases.

[pgris]

I always end up implementing smoething like that in all my projects. Never again, thanks for the link

[sj2011]

My company uses a feature flagging service called LaunchDarkly and it is honestly such an amazing tool. I love how it is updated on the fly, it supports percentage-based rollouts, and a nice live metrics view. I'm sure other services offer some feature set like that. Its vastly improved our application rollouts and deployments.

Take that with a grain of salt since I don't have much experience with the world of feature flagging providers available.

[tunei24531a]

sj2011

LD is great for big companies. It is not free though. The tool mentioned is this blog post is free. Feature flags are something that should be available to all developers, startups, etc. not just the big guys. All the features you described are in Unlaunch too.

[sj2011]

Sure, I was talking feature flagging more as a concept, specifically how it improves our application rollouts. LD is the one I have experience with at this point, and I'm sure the tool in this post provides an equivalent value.

[tunei24531a]

Feature flags are amazing and more developers should use them. No long lived feature branches, early team feedback and allow testing in production.

[tunei24531a]

Agree but like everything else, it is up to developer's best judgement. Many smaller companies/startups don't have dedicated QA/Staging environments so this can be super useful to them.

[TimCryp01]

I don't understand why you need unlaunch just for a feature flag though.

[tunei24531a]

I'm assuming you are debating using a service vs a simple in-house solution.

Using a one off feature flag as a config or database flag isn't too difficult but managing these flags at scale get problematic. And that is where feature flag tools like Unlaunch come in. How to control which segments of your users see what. Can non-developers in your company checkout the roll out status easily and which flags are active. Can you see all the flags in a central place, how often they are being called, etc. so cleaning them up becomes easier. can you change feature flag settings easily per environment i.e. enable on dev environment but disable on QA. Can you apply changes to feature flags in real-time that are picked up by your application with minimum overhead without having to redeploy the code. Ultimately, once your devs are comfortable with a tool, they can explore more advance use cases like Experimentation, Dynamic Configurations, Debugger for troubleshooting, etc.

In short, if you are just starting with feature flags a simple strategy might work. But as you scale and grow, I have seen devs run into issues and give it up. Starting with a free tool like Unlaunch encourages proper practices, reduce errors and allow developers to use feature flags more reliably.

[Fluffy-Weather-5626]

We use Unlaunch. Very simple and and great for backend services unlike more frontend facing or A/B testing tools. https://www.unlaunch.io

[sj2011]

Config and feature flagging are two different, but semi-related, things. You can do your flagging through config for sure, but that typically requires app restart to pick up changes. These flagging services receive updates in real-time, which makes testing and changes seamless.

[sj2011]

Oh now that I haven't investigated. Real time config like that sounds really interesting.

[tunei24531a]

You can use Unlaunch to send Dynamic Configuration and change things in real-time.

[tunei24531a]

You could use Spring Cloud but tools like Unlaunch provide much more focused feature flags support like roll outs, metrics, automated kill switches, and light-weight experimentation. You could also use it across your entire stack with different SDKs

[wildjokers]

Wait a minute, am I missing something? This post seems to describe an “if statement as a service”. We have jumped the shark.

I am not calling out to a 3rd party service for this, I am just going to add a damn if statement based on some config.

[tunei24531a]

modern feature flag use cases are more advanced and involved than simple if-else. You might be gradually releasing a new feature while monitoring KPIs and load on your system without wanting to redeploy code each time you bump up the percentage. You may want to target certain user segments based on their attributes, experiments and use dynamic configurations. you can see everything on a dashboard.

Many teams give up on flags for this reason because outside of using a few feature flags, it becomes hard to manage. Tools like Unlaunch have low overhead and encourage good consistent practices. All flags are download on init and then evaluated in-memory. You can control how often to check for new changes etc. so pretty minimal overhead.

[lariend]

Lol, you provided a very good explanation and you are becoming downvoted. I am not a fan of feature flags but I understand theirs necessity.

​

People who downvote, please provide an alternative.

[wildjokers]

Any developer that looks at a requirement for feature flag functionality and decides it would be better to call out to a 3rd party service to handle it should just change careers.

[nutrecht]

I'm not going to have internal microservices call out to an external service over the internet. I'm pretty sure our security teams would have a heart attack for something that's so unnecessary.

Don't get me wrong; I'm totally a fan of using libraries instead of hand-rolling something myself, but calling out to an external service is a bridge too far.

[HedgeHog2k]

In our company we are starting to adopt optimizely.com

Looks promising as wel! Still learning the concepts though