Feature flags is a pattern allow you to build system with confidence. You can ship new code / adding new behavior or conducting A/B testing without deploying new code.
Here I am going to share an opinionated way to doing feature flag in Rails project using flagr.
What is Flagr
Flagr is a feature flag evaluation framework. Basically, it provides the flexibility of:
- assigning any JSON value to a "flag"
- designing any passing condition (or even condition combination) for flag
- adding rollout percentage
- a simple interface where the team can modify it directly.
And it's super fast (written in Go and usually the evaluation took few ms to finish).
Setup
First you will need to decide where do you want your flagr service to store data. Check doc for available storage option.
And then you might want to decide how to host it. In my current setup, given the low memory footprint and lightweight design of it, we just make it as a "sidecar" container sitting internally aside our web service.
So inside your Ruby code, you can just do a POST request to the internal path http://flagr/flagr/api/v1/evaluation/batch to get evaluation result almost without any latency.
Check their detailed doc on how the evaluation work.
Downsides
The whole design of flagr is that evaluation is stateless meaning that you will get the same result with the same input (in most case, User ID). This might cause some issue when we are building a more complicated rollout mechanism. The fix would be adding an extra layer of persistence storage on top of flagr.
The other issue would the condition design of flagr is too simply that you won't be allowed to construct complicated conditions. And for that one, you would need to model multiple flags in your own code.
Conclusion
After trying lots of feature flags library, hosted or not, I think flagr provide a good enough abstraction with flexibility for any size Rails project.
Top comments (0)