Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Preloading features #198
Some code to help the discussion in #190
When N features are being checked in a single request this would result in N requests to the underlying store at best with memoization enabled.
This PR adds
This allows adapters to optimize
To take advantage of this
Super helpful to see this. I definitely got a few ideas by having some code in front of me. I like the overall approach. I am keen to hear your thoughts on the middleware specifically.
Also, I would love to see tests for preload, preload_all, get_multi and the new middleware (or whatever we go with there). Do you have time to add those? If not, I can work on seeing this through, but it might be a bit before I have time.
I am definitely down to merge this with tests and a few minor tweaks and I really appreciate the thoughtful PR.
Also, if you don't mind, I would love to know what you are using flipper for as well and how it is working out for you (what went well, what was hard). If you aren't comfortable leaving that information here in a public comment, feel free to email me directly (it shows up on my profile page). I'm just always curious. :)
Happy to write some tests, I also plan to have a look at how to implement
We use Flipper at Cronofy for all sorts. Hiding UI features, easing in new features to our synchronisation layer, making new endpoints/data available to specific clients during development, experimenting with new implementations of things that should be transparent.
The big thing that triggered this work for us is we're changing our data storage and so rather than generally 4-5 flags in play at any time we've got 20+. We were seeing roughly 1ms per feature flag fetch and with API endpoints that respond in around 90ms adding 20ms really shifted the needle. Using this approach has led to ~4ms on every request.
Flipper was easy to get going with, probably the fiddliest thing was wrapping things to expose a
Any other feedback from our use @stephenbinns?
@jnunemaker I think this addresses your key points. I'm not sure if I've added tests in all the places you would want them or not so any pointers you can give would be good.
I also plan to look into implementing
Sorry just got round to replying to this I don't really have much to add to what @gshutler's already said about our usage. The defaults are sensible and we've had no real issues other than when we've introduced a large number of flags.
One thing we've noticed from our usage is we rarely use the 75% enabled on the UI as we generally would tend towards going from 50% -> 100% (as usually by 50% you're pretty committed).
For us the biggest feature gap is the audit trail (I see its already on the issues list) we use Slack for most of our integrations, so we might have a look into hooking into the UI to send notifications on flag changes.