Never underestimate the power of a zero-network-hop abstraction over f(feature_name, context).
And context can be extremely tailored to your niche: specific inventory, from a specific supplier, for a specific user of a specific B2B client of a specific business model subtype, who should or shouldn’t see certain features on that specific inventory at certain times.
When you can write your own logic, and just run this in a tight loop as easily and performantly as you can use a constant, it makes your business incredibly agile. Think some text might change for some customers? Just write the code to make it configurable, and you get tests and flags for free.
Sadly, that zero-hop setup requires a sophisticated client execution engine, which it doesn’t appear Cloudflare has implemented here. Makes sense for their memory constrained workers, less sense for traditional infrastructure.
Statsig has an approach here that I quite like:
> To be able to do this, Server SDKs hold the entire ruleset of your project in memory - a representation of each gate or experiment in JSON. On client SDKs, we evaluate all of the gates/experiments when you call initialize - on our servers.
You can also roll your own - just sync your rulesets to a few data structures every few seconds in a background thread and atomically swap the reference to them. Then you just need a CRUD interface over the applicability ruleset dimensions.
Just be careful to have governance on who can play with which would-be constants. Great power and great responsibility and all that!
Looking at the docs for their JS SDK, they have this warning:
> The client provider requires an API token to fetch flag values. This token is not scoped to a single app, so anyone with the token can evaluate flags across all apps in your account. Use the client provider with caution in public-facing applications.
Can anyone clarify... why the client SDK, designed to be deployed to browsers, requires caution? Does this mean that any client could send requests with a new targetingKey and observe other users' flags?
While flags probably shouldn't be critical information, this seems like an interesting design choice.
Both Cloudflare and Vercel have feature parity. Flags is a feature already in Vercel. While customer-first is a thing, it is also a no-brainer to start with: we use it, Vercel has it, let us build it.
Yes, this! I am dying for need of zerotrust enterprise features and am about to have to actually talk to one of the enterprise sales folks, which will chew up a bunch of time and add stress I’d rather avoid.
Cloudflare are winning these days, they’re just lacking good fine grained permissions. You still have to make an entirely separate account for prod, which messes up SSO since one domain can only be bound to one account.
Their products are cool and I've been happy with them over the years, but their blog right now has had some blunders recently. Also their reliability seems to have been having trouble but does seem better recently.
One account gets compromised and your doomed. A lot of companies even have prod access be a request based system. Most modern security models with zero trust don't let everyone have access to everything, quite the opposite.
It’s pretty useful. We used it at a previous company. We built a custom backend, but used the spec and SDKs.
It took like 2 weeks to build a full custom backend. SDKs across languages worked flawlessly (okay, we did find one bug, reported it, and it was fixed within the day)
A bit tangent but related: These things I'm never sure if I should be shipping on day one with mobile apps (Flutter in particular): Flagships, bug gathering, A/B testing ?
I feel strong inclination too but its also way too early before any real users can prove PMF. I've been using Google stuff but wonder if Flagship and perhaps other Cloudflare offerings can help.
The other side is that again it feels too early for this stuff and I just want to ship something quickly.
Missing gradual rollout of feature flag changes themselves. Yes, you can do percentage based rollouts for individual features but still should have ability to canary all changes before they cause an insta-sev.
More of this please: essential tools for building modern software must be oss; Im fine with paying for a hosted version but just the benefit of learning one tool and being able to use it everywhere (linux, k8s, python etc) is amazing.
Has anyone struggled to run their own feature flagging service? After root causing slow app starts to be caused by the equivalent offering from Firebase, I've been cautious to use any off the shelf solutions
It can get complicated quickly if you're actually using it in a production system. At my prev enterprise saas company we had feature flags that could be turned on per customer / per environment (dev, staging, prod) with permission + logging model such that our support team could also toggle flags with history of who turned on what. We also had "per user" feature flags for certain test users at companies and had DSL rules to evaluate the features
If anyone is interested, you can implement something like that with a few lines of code on the front end. We expose a function that generates a uniformly-distributed hash that you can use for A/B testing and other uses:
Essentially, this can support a huge number of "variants" and within each variant you can have N equal segments. That will help you do A/B testing and flipping features on or off.
And context can be extremely tailored to your niche: specific inventory, from a specific supplier, for a specific user of a specific B2B client of a specific business model subtype, who should or shouldn’t see certain features on that specific inventory at certain times.
When you can write your own logic, and just run this in a tight loop as easily and performantly as you can use a constant, it makes your business incredibly agile. Think some text might change for some customers? Just write the code to make it configurable, and you get tests and flags for free.
Sadly, that zero-hop setup requires a sophisticated client execution engine, which it doesn’t appear Cloudflare has implemented here. Makes sense for their memory constrained workers, less sense for traditional infrastructure.
Statsig has an approach here that I quite like:
> To be able to do this, Server SDKs hold the entire ruleset of your project in memory - a representation of each gate or experiment in JSON. On client SDKs, we evaluate all of the gates/experiments when you call initialize - on our servers.
https://docs.statsig.com/sdks/how-evaluation-works
You can also roll your own - just sync your rulesets to a few data structures every few seconds in a background thread and atomically swap the reference to them. Then you just need a CRUD interface over the applicability ruleset dimensions.
Just be careful to have governance on who can play with which would-be constants. Great power and great responsibility and all that!
> The client provider requires an API token to fetch flag values. This token is not scoped to a single app, so anyone with the token can evaluate flags across all apps in your account. Use the client provider with caution in public-facing applications.
https://developers.cloudflare.com/flagship/sdk/client-provid...
Can anyone clarify... why the client SDK, designed to be deployed to browsers, requires caution? Does this mean that any client could send requests with a new targetingKey and observe other users' flags?
While flags probably shouldn't be critical information, this seems like an interesting design choice.
There is no way 6 months ago someone at CloudFlare thought it was a good idea to build a competitor to say LaunchDarkly.
Their recent features / announcements have been equivalent to:
(LaunchDarkly)
Resend, Firecrawl, CrewAI, Helicone, Replicate, Pinecone
-
Which like… many companies have a painful procurement process. If all you need is Cloudflare, and prices are within reason- why not use them
https://blog.cloudflare.com/enterprise-grade-features-for-al...
—-
I don’t believe a single enterprise only feature has made its way to lower tier (paid) account yet.
I’m most interested in:
https://developers.cloudflare.com/speed/optimization/content...
https://community.cloudflare.com/t/making-enterprise-product...
It took like 2 weeks to build a full custom backend. SDKs across languages worked flawlessly (okay, we did find one bug, reported it, and it was fixed within the day)
I feel strong inclination too but its also way too early before any real users can prove PMF. I've been using Google stuff but wonder if Flagship and perhaps other Cloudflare offerings can help.
The other side is that again it feels too early for this stuff and I just want to ship something quickly.
The work ivnvolved
[1] https://vercel.com/docs/flags/vercel-flags
And on the back end, you'd use it like this:
https://github.com/Qbix/Platform/blob/main/platform/classes/...
Essentially, this can support a huge number of "variants" and within each variant you can have N equal segments. That will help you do A/B testing and flipping features on or off.