I’d be interested in that, too! I can throw in this article, but no experience: https://martinklepsch.org/posts/homoiconicity-and-feature-flags.html

Not much, other than extra ifs proliferating all over the source code. I wonder if there is a way to do this without the source code getting harder to read.

if the long term goal is to have a new feature replace another one, we have implemented it using with-redefs-fn to centralize the dispatch logic.

this has worked for us quiet nicely

My biggest problem with feature flags is that it kind’a ends up having to be considered along side authorization. Consider:

(when (and (enabled? feature user)    (authorized? action user))
   (render feature))

(when (available? feature user)
   (render feature))

What is mean by “have a new feature replace another one”, @U0J6U23FW?

(if (enabled? new-feature user)
   (render new-feature)
   (render old-feature))

Do you need the ability to turn on/off the feature flag dynamically?

i.e., when the system is running?

Makes sense. I guess that is one goal for me. Even if I think the main use is to toggle a feature on or off.

@U0ETXRFEW example: we want to release a given feature, but we want to test how it behaves live first, so what we could is release to a group of users so that we could monitor once we are confortable we then enable the feature to everybody. hope it makes sense.

There is unleash (https://github.com/Unleash/unleash) which does everything and a bit more. Initially developed at http://finn.no (the company running blocket)

Has a clojure client IIRC

Yes @U11EL3P9U. I’d like for the product owners and marketing people to be in charge of what is released or not. So things should be a bit decoupled from the release process.

(and since you’re Swedish, https://podcasts.apple.com/no/podcast/1-feature-flags-og-unleash-med-fredrik-oseberg/id1568283785?i=1000522426286)

Awesome. I’m so happy I asked in this channel! Please keep it coming. I need to learn about this quickly and deeply.

@U04V5VAUN unleash looks pretty great! thanks a lot! definitely will check it out!

If you want PMs to do that then you'll need a nice UI (and the flag will have to poll on every invocation)

That unleashed looks nice!

There is a clojure lib 🙂

I think you're on to a winner there 🙂

Haha, that would be great. But I really am on the problem statement stage still. 😃 It’s great with unleashed because I can reverse engineer some of the problem statement stuff. Haha.

FWIW, we’re not using anything other than code for this at ardoq. I’ve been aware of unleash for some time, but I want to understand our problem properly before I throw a tool at it.

Life becomes simpler when you consider feature flags to be simply an instance of the 'authorization' problem "Should I enable feature x" becomes "Should I allow feature x for user u". Rolling out a feature to 10% of users becomes authorizing 10% of users. This idea of mine throws some people off because it looks as if you were conflating two concerns... I don't think one is. It's the same problem with different English words attached to it. Computers don't care :)

I guess that’s what I’m getting at. From the frontend code this is basically the same thing, hence we’d prefer:

(when (has-access? user some-feature)
  (render some-feature))

(when (has-access? user some-feature)
   (render some-feature))

Did you intend to post two different code blocks, @U04V5VAUN?

No

Just checking 😃

To me it makes sense to treat it as “Should I allow feature x for user u”. I wonder if services like unleash support that…

Even more. Maybe not spot on, but unleashed is mentioned https://nrkbeta.no/2021/08/23/feature-toggling-transient-errors-in-load-tests/

That Norwegian podcast episode you linked to, @U04V5VAUN. Exactly what I needed!

Cool!

They mention this extensive look at feature flags, by Martin Fowler: https://martinfowler.com/articles/feature-toggles.html

Fowler defines a category of flags as Permission Toggles, which I then connect back to @U45T93RA6’s suggestion to treat all feature flags as an instance of the authorization problem. Fowler talks about using Permission Toggles for cutting out groups of users like “premium”, “beta”, etcetera. I mean, that is pretty clearly a permission problem, but if I get your idea correctly, @U45T93RA6, you are more talking about the implementation?

Also, is feature toggles a way to implement product pricing plans, would you people say?

Permission Toggles sounds to me like treating authorization (or at least part of it) as a subset of the feature toggles problem domain. I advocate the opposite: treating feature toggles as a subset of the authorization problem Being specific, let's imagine we had an app with vanilla authorization system such that you had defns like these:

(defn can-use-dashboard? [user]
  (-> user :role #{:admin}))

(defn can-use-dashboard? [user]
  (or (-> user :role #{:admin})
      (-> user :toggles #{:dashboard}))

> Also, is feature toggles a way to implement product pricing plans, would you people say? It seems to me that toggles return a boolean, not a number (for expressing a currency amount) Working around it would seem to imply a sequential scan ("can he access plan A?", "can he access plan B?") which doesn't sound efficient

Thanks! I’ll ponder this now. 😃