Live data from Hacker News

Cloudflare Flagship

developers.cloudflare.com

91–100 of 189 posts

Re: Cloudflare Flagship

#91

I've never understood feature flags. How are they fundamentally different to a Boolean in a database?

The flags (whether they be booleans, strings, numbers, or anything else) are the trivial part. It's the targeting and rollout rules (i.e. who gets to see which flags), and the requirements for extremely fast and consistent evaluation of these rules, that can get surprisingly complicated fast, and folks who have rolled their own usually find that product management or marketing or sales wants to target using more complex rules, and the problem balloons.

I agree that problem is not particularly hard in the grand scheme of things, but it is actually quite big, meaning it requires a lot of features that aren't obvious at first glance.

Edit: Thought of another analogy that may help explain the complexity. At their heart, feature flags are really a permissioning system: only certain users get access to certain pieces of functionality. Anyone who has ever dealt with permission systems know how complex they can be: group membership, including hierarchical groups, roles, ACLs, etc. All of those things are really analogous (actually, a subset really) to the various types of targeting rules that can be used in a feature flags system.

Re: Cloudflare Flagship

#92

I've never understood feature flags. How are they fundamentally different to a Boolean in a database?

It's the tooling around them.

How do you set a boolean to only return true for queries to 5% of the fleet? And which 5% of the fleet? And then ramp up on a predefined cadence? Or how about returning true only for customers in the preview group for the feature? Does the database return false automatically if the 5% of the fleet where it's true start crashing or throwing exceptions? Does it hook into your observability stack?

Fundamentally, sure, you could just implement it as a boolean in the database. It's the integration and tooling that works with the rest of your stack that makes it worthy of the name "feature flag".

Re: Cloudflare Flagship

#93
post #34

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…

Statsig has worked great at my work, really polished and rich feature set. Their tooling to identify unused flags as candidates for removal is neat.

The per-seat billing we have in our agreement is a bit rough but it's workable.

Re: Cloudflare Flagship

#94
post #34

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…

Good advice. I'll add a protip / reminder that feature flags, AB tests, and entitlements are three distinct concepts. This blog post (no affiliation) has framing I found helpful: https://www.stigg.io/blog-posts/entitlements-untangled-the-m...

Amazing resource, thanks!

Re: Cloudflare Flagship

#96
post #81

Earlier quoted context omitted.

That sounds like the product is not finished and should not be released?

"If you are not ashamed by what you are shipping, you are not shipping early enough" (Quoting from memory)

That's a terrible attitude for an infrastructure company. This is what private betas / close iteration with customers is for.

Re: Cloudflare Flagship

#98
post #77
post #33

Earlier quoted context omitted.

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.

Now waiting for Cloudflare to allow me to use Rust for serverless, real native code, not WebAssembly. https://vercel.com/docs/functions/runtimes/rust

They have containers, does that count?

If you’re specifically thinking of native ephemeral workers with very fast startup, it seems like those would have to be sandboxed somehow, and WebAssembly seems like a decent solution. Is there really a significant native code gap between WebAssembly workers and native containers?

Re: Cloudflare Flagship

#100
post #77

Earlier quoted context omitted.

Now waiting for Cloudflare to allow me to use Rust for serverless, real native code, not WebAssembly. https://vercel.com/docs/functions/runtimes/rust

They have containers, does that count? If you’re specifically thinking of native ephemeral workers with very fast startup, it seems like those would have to be sandboxed somehow, and WebAssembly seems like a decent solution. Is there really a significant native code gap between WebAssembly workers and native containers?

Containers seem to only be "Available on Workers Paid plan", whereas Vercel supports it on the hobby account as well.

Kind of relevant on those cheapskate projects that only start paying licenses after the SOW is signed, but already expect some kind of prototyping in place.

WebAssembly is a solution looking for a problem outside the browser, with worse development experience.

If I want bytecode based runtimes, I already have them with first class development experience, and decades of deployment experience, between Erlang, JVM and CLR.

Post reply on HN