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.
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.
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.
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.
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)
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.
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.
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.
Let's think about it. This is probably something used internally at CloudFlare and someone thought I'd be interesting to make it public.
There is no way 6 months ago someone at CloudFlare thought it was a good idea to build a competitor to say LaunchDarkly.
Hmm not sure I necessarily agree. Cloudflare's strategy has been looking like "the only platform you need" for a while now.
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
Care to share why
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.
The work ivnvolved
This is nice, but I’m still waiting for this to be delivered (which ironically is probably using Flagship):
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...
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.
I don’t think zero trust will be anytime soon, based on this post:
https://community.cloudflare.com/t/making-enterprise-product...
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.
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.
This is exactly what stops me from using them for real work. I love their free tier for my hobby stuff.
Yes! I just opened a support case today asking for more fine grained permissions.
After years of AWS I gave Cloudflare a whirl and loved the UX but ultimately retreated back due to the same concern. They are so close though..
Will never use them without prepayment or spending limit options. Insane to be a bug, attack, or misclick away from 6-7 digit invoice
Just let everyone have access to prod?
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.
Poor access and change management governance.
hooboy that was a good one!
OpenFeature was new to me, neat! Anyone have experience integrating this? https://openfeature.dev
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 flagship with no pirates, all fired due to ai.
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.
Cloudflare oss?
Worth noticing a Vercel equivalent: https://github.com/vercel/flags
That is actually their SDK / provider agnostic library. The better parallel to this new Cloudflare offering is Vercel Flags[1] (confusing I know)
[1] https://vercel.com/docs/flags/vercel-flags
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's literally a field in your database. I could never fathom why this needs to be an outsourced service never mind an entire company.
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:
https://github.com/Qbix/Q.js/blob/main/src/js/Q.minimal.js#L...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.