cloudflare now has a built-in feature flag service π
flagship enters public beta today, and you can integrate it into your workers apps already deployed on
@CloudflareDev, or deploy a worker in front of your app to do feature flipping and more w/o any additional config (read on!)
there's a simple binding api (env.FLAGS w/ <10 methods, easy for your agents to pick up):
env.FLAGS.getBooleanValue - return basic boolean values, like "is this flag set or not?"
but you can also do some funky stuff like storing objects
env.FLAGS.getObjectValue - return a full JSON object. you can store full configurations and flip per-user or org. neat!
flagship is also openfeature-compatible. the cloudflare/flagship npm package has full support and interoperability with openfeature's sdk. so you can easily swap in flagship from your other providers and trial it
on the setting of flags side - support for booleans, strings, numbers, and json
and for targeting, you can use operators (things like "user_id is equal to xyz") or you can do percentage rollouts. all available in the dashboard.
the dashboard is also quite powerful - you can create flags from the beautiful ui, see where your app is bound (across multiple workers, even!) and there's full analytics. knocked it out of the park
the last thing i'll mention that i think is quite compelling and unique about workers and flagship is something we've talked a lot about in workers/cf land - i don't have a great name for it so i'll call it "originless" behavior.
you can do a "v2-enabled" feature flag and make a fetch request to a totally different host, do URL rewrites etc without any changes to your actual application. eg `isflagEnabled ? fetch(newUrl) : fetch(origin)` - since the worker runs _in front_ of your app, you can do all sorts of behavior w/o ever needing to talk to your origin
quite excited about this release and looking forward to playing w/ it. more on flagship in our changelog:
developers.cloudflare.com/chβ¦