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

111–120 of 189 posts

Re: Cloudflare Flagship

#111

Post by la_fayette »

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…

When reading your comment, it just reminds me on how feature flags can be misused as application configuration/customization. An antipattern i could observe at various organzations already.

For me feature flags go along with trunk based development to enable features in QA settings, but not on PROD yet, for PO/PM testing. Trunk based development allows for fast/easy devops, without complicated branching strategies.

Application configuration is, for me, part of the application and has the business context for customizing the application accordingly. Not sure if there are specific frameworks/tools out there. But one should clearly distinguish these two.

Re: Cloudflare Flagship

#113

Post by melwell64 »

glasshug wrote: post #13

OpenFeature was new to me, neat! Anyone have experience integrating this? https://openfeature.dev

I have had a lot of experience with OpenFeature, and have early commits in a few of the client libraries. It's definitely the future of feature flagging, and the ecosystem is really growing.

Full disclosure, I am the CTO of Flagsmith, and we have seen a clear curve in adoption of OpenFeature over the last few years. It used to be that we were pushing customers to try it out, now they come to us with OpenFeature as a requirement.

The vendor support is pretty mature now and there is coverage across almost all languages. If you're integrating feature flags into a new service, or looking to migrate from e.g. home-grown to a third party solution, OpenFeature is definitely the way I would recommend going.

Re: Cloudflare Flagship

#114

Post by pil0u »

ZeWaka wrote: post #93
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…

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.

Statsig is a half-baked product bought out by OpenAI for data harvesting. We already reported 2 documentation issues and 1 critical technical issue, and we're barely using it.

Re: Cloudflare Flagship

#115

Post by epolanski »

la_fayette wrote: post #111
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…

When reading your comment, it just reminds me on how feature flags can be misused as application configuration/customization. An antipattern i could observe at various organzations already. For me feature flags go along with trunk based development to enable features in QA settings, but not on PROD yet, for PO/PM testing. Trunk based development allows for fast/easy devops, without complicated branching strategies. A…

> it just reminds me on how feature flags can be misused as application configuration/customization

They literally are configuration.

Re: Cloudflare Flagship

#117

Post by ahoka »

alper wrote: post #116

Anybody and everybody could use a mature LaunchDarkly alternative.

According to their page, they are an AI company, so I don’t see why would anyone choose them for feature flags.

Re: Cloudflare Flagship

#118

Post by risyachka »

gowthamgts12 wrote: post #64
jasonjmcghee wrote: post #31

Earlier quoted context omitted.

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

Their quality of the products they ship have already became shitty for quite a while now.

they are quickly turning into a slop shop

instead of polishing their existing products (and most of them do require a lot of work) they jump into any other niche someone thought was a good idea. My guess is that with ai being able to prototype things quickly they just started doing everything that is even a bit relevant.

which won't end well

Re: Cloudflare Flagship

#119

Post by Rp8yXmdmr »

jwr wrote: post #105

Am I the only one worried about Cloudflare becoming too powerful? We went through this with E-mail: we slept through the period when Google, Microsoft and AWS were growing, and we ended up with them dictating the terms. Today I get 90% of my spam from Google, Microsoft and AWS and they don't care: they can safely ignore spam reports, because at this point they are Too Big to Block. I have a feeling we are moving towa…

Cloudflare is already too powerful, their anti DDOS solution is just too good. But their serverless products/features don't really build on that, they are just another hosting company.

Re: Cloudflare Flagship

#120

Post by baq »

la_fayette wrote: post #111
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…

When reading your comment, it just reminds me on how feature flags can be misused as application configuration/customization. An antipattern i could observe at various organzations already. For me feature flags go along with trunk based development to enable features in QA settings, but not on PROD yet, for PO/PM testing. Trunk based development allows for fast/easy devops, without complicated branching strategies. A…

> it just reminds me on how feature flags can be misused as application configuration/customization. An antipattern i could observe at various organzations already.

feature flags are perfect for configuration and customization, why using them for this purpose is 'misuse' is beyond me and I've heard this claim from multiple people. they're literally configuration. feature with a flag to turn it on, off or give the flag a value. where's the misuse? is it a problem I'm not running experiments when switching over redis to valkey or whatever?

Post reply on HN