Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cloudflare Flagship

developers.cloudflare.com

Post reply on HN
Print view View original

71–80 of 189 posts

Re: Cloudflare Flagship

#71

Post by swyx »

btown wrote: 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…

> 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.

wait what? what kind of logic do you need to do that CF Workers can't do?

Re: Cloudflare Flagship

#73

Post by rustystump »

ai_fry_ur_brain wrote: post #65
stingraycharles wrote: post #55

Earlier quoted context omitted.

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

This has been the Cloudflare standard operating procedure for the last year or so. Non stop shipping alpha/beta products.

Otherwise known as vibe code snacking. Vibe out the easy 80% and say the hard 20% is “coming soon tm”

Re: Cloudflare Flagship

#74

Post by iTokio »

Feature flags are often ridiculously over engineered.

Check a config, bdd value, env var to dynamically go one path or the other.

That’s all, you must either have a small feature or refactor the code to easily switch at a high level.

If you are not able to do so easily, then yes, complex feature flags implementations might help you, to coordinate feature activation between micro services.

Or if you have many features then a dashboard might be useful.

But I would argue that both are serious indicators that you should avoid feature flags, they are better for local and temporary changes, otherwise the complexity compounds and it become hard to manage and maintain.

Re: Cloudflare Flagship

#75

Post by rustystump »

btown wrote: 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…

Could you be more specific?

Re: Cloudflare Flagship

#76

Post by LaurensBER »

iTokio wrote: post #74

Feature flags are often ridiculously over engineered. Check a config, bdd value, env var to dynamically go one path or the other. That’s all, you must either have a small feature or refactor the code to easily switch at a high level. If you are not able to do so easily, then yes, complex feature flags implementations might help you, to coordinate feature activation between micro services. Or if you have many features…

There's an argument to be made for being able to turn on a feature for a certain segment (e.g low revenue users in Italy) so you can see what the business/performance impact is.

Ofcourse you don't want users to lose the feature once they exceeded your revenue threshold or cross the border so you'll need to implement some kind of tracking. Your analytics and error tracking also needs to communicate with the feature flag service.

Definitely not rocket science but more complex than a environment variable.

Re: Cloudflare Flagship

#77

Post by pjmlp »

bg24 wrote: post #33
OptionOfT wrote: post #23

Earlier quoted context omitted.

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.

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

Re: Cloudflare Flagship

#78

Post by bfivyvysj »

LaurensBER wrote: post #76
iTokio wrote: post #74

Feature flags are often ridiculously over engineered. Check a config, bdd value, env var to dynamically go one path or the other. That’s all, you must either have a small feature or refactor the code to easily switch at a high level. If you are not able to do so easily, then yes, complex feature flags implementations might help you, to coordinate feature activation between micro services. Or if you have many features…

There's an argument to be made for being able to turn on a feature for a certain segment (e.g low revenue users in Italy) so you can see what the business/performance impact is. Ofcourse you don't want users to lose the feature once they exceeded your revenue threshold or cross the border so you'll need to implement some kind of tracking. Your analytics and error tracking also needs to communicate with the feature fl…

Enterprise software is full of this kind of stuff. Half our customers are on year old UI's because they don't want to re-up contracts yet.

That is, features are contractual and when you've only got 50 customers but they're all paying high 6 figures does anyone really care about feature flag complexity?

Re: Cloudflare Flagship

#79

Post by weego »

LaurensBER wrote: post #76
iTokio wrote: post #74

Feature flags are often ridiculously over engineered. Check a config, bdd value, env var to dynamically go one path or the other. That’s all, you must either have a small feature or refactor the code to easily switch at a high level. If you are not able to do so easily, then yes, complex feature flags implementations might help you, to coordinate feature activation between micro services. Or if you have many features…

There's an argument to be made for being able to turn on a feature for a certain segment (e.g low revenue users in Italy) so you can see what the business/performance impact is. Ofcourse you don't want users to lose the feature once they exceeded your revenue threshold or cross the border so you'll need to implement some kind of tracking. Your analytics and error tracking also needs to communicate with the feature fl…

There's an argument to be made for being able to turn on a feature for a certain segment

Not just an argument, it's the entire point of feature flags for ui experiments which is an essential practice. Dynamic adjustment of the cohorts (or even just an immediate kill switch if it's a disaster) is required.

Post reply on HN