Fork me on GitHub

Good Morning!


morning. back at work today


Good morning! Does anyone have good or bad stories to tell about feature flag systems you have used and/or developed/maintained?


I’d be interested in that, too! I can throw in this article, but no experience:


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))
This bit of code should probably not worry too much about the reason why the feature is available to the user, so something like
(when (available? feature user)
   (render feature))
could be favourable. But then your feature-flag system and your authsystem becomes intertwined, and your world becomes chaotic again.


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


(if (enabled? new-feature user)
   (render new-feature)
   (render old-feature))
I would presume.


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 ( which does everything and a bit more. Initially developed at (the company running blocket)

❤️ 2

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.


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)

👍 3

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.

❤️ 2

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 :)

👍 4
🙏 2

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))
But, the way that this access is granted may very well be quite different: Ardoq, being a multitenant saas solution, permissions, ie authorization, is granted by the customer, whereas feature-toggling is done by ardoq. For this reason, in our case, these are two different datasets that need to be merged at some point so that we can arrive at
(when (has-access? user some-feature)
   (render some-feature))

👀 2
👍 2

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


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

❤️ 2

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


They mention this extensive look at feature flags, by Martin Fowler:


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}))
So my thinking is that one can hijack such defns to express:
(defn can-use-dashboard? [user]
  (or (-> user :role #{:admin})
      (-> user :toggles #{:dashboard}))
The idea is that you introduce zero mechanisms in the codebase; you keep using the same solution (presumably a very simple one). It's only thin, localized parts that might change (vs. more pervasive conditionals)


> 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. 😃


good morning


Good morning 🙂