Live data from Hacker News

Cloudflare Flagship

developers.cloudflare.com

161–170 of 189 posts

Re: Cloudflare Flagship

#162
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…

Which is not hard to do (it is a modulo over a mersenne twister or something similar), but in my recent gigs just Flipper with optional "state of the flags table as of now" endpoint was more than enough. That modulo+random combo required tools like LaunchDarkly to ship SDKs in several languages, and the ones I had to work with were just plain horrible fit for their language of choice. But because the evaluation was relegated to the edge, the whole system got way more complex than desirable. In actuality, I think a refetch of the current flags table "for this customer" every so often is just fine, and way less of a nuisance.

So glad Flipper exists and I don't have to deal with this stuff anymore.

Re: Cloudflare Flagship

#163
post #162
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…

Which is not hard to do (it is a modulo over a mersenne twister or something similar), but in my recent gigs just Flipper with optional "state of the flags table as of now" endpoint was more than enough. That modulo+random combo required tools like LaunchDarkly to ship SDKs in several languages, and the ones I had to work with were just plain horrible fit for their language of choice. But because the evaluation was r…

which Flipper is this?

Re: Cloudflare Flagship

#164
I love direction and features Claudflare is taking, they are really impressive. And since I use their service on several projects, I can say I am overall very happy with service.

Only thing, they are going strongly in AWS territory and not in any good way. Finding what I need and what I use has become harder as times go by. By contast, Azure (MS) even though it looks crazy complex, once you get used to it, you can find things.

Re: Cloudflare Flagship

#166
post #108

Earlier quoted context omitted.

I’ve seen whole teams at companies set up fail to provide these booleans-as-a-service well. There are whole companies like LaunchDarkly for them. If you boil it down to this, you may as well boil down every service that exists to bits-as-a-service. Turns out theres legitimate business value in these things, and complexity in delivering them.

It's like saying Dropbox is just rsync.

I mean... I, for my own needs, which are rather simple, can replace Dropbox with rsync. That's one thing. But yes, it's an entirely different thing to consider you don't need, or worse, could own, such business, on the simple premise you don't need it at your own level. That would be madness to mistake one for the other.

Re: Cloudflare Flagship

#167
post #114
post #93

Earlier quoted context omitted.

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.

Well, OpenAI already sold it (but kept the team), so it’s in someone else’s hands now.

Re: Cloudflare Flagship

#168
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…

Yes, feature flags are conflated with remote configs (or its more useful variety: "dynamic configs"). The difference is subtle, hence why people are talking past each other.

Feature flags are gates for whether a piece of code runs; basically, an if-condition. Remote configs are a mechanism for changing runtime values without redeploying[1].

For example:

  # Feature flag — variant gate for rollout
  flag = sdk.check_gate(user, "checkout_flow")
  if flag == 'open':
      render_new_checkout()
  elif flag == 'warning':
      render_warning_checkout()
  else:
      render_old_checkout()

  # Raw remote config pulled — structured values for tuning behavior
  config = sdk.get_config(user, "checkout_settings") # if the config changes based on user or context, this "remote" config is considered "dynamic"
  timeout_ms   = config.get("timeout_ms", 5000)
  max_items    = config.get("max_items", 50)
  allowed_tlds = config.get("allowed_tlds", [".com", ".org"])
In practice, feature flags are implemented on top of dynamic configs[2] to manage the temporary lifecycle of a feature — aka, ship a new block of code, ramp its execution up to 100%, then delete the flag. Whereas dynamic configs are a deeper primitive meant for semi-permanent/safer operations like tuning rate limits or changing text copy on a marketing website.

As I've seen it: the forcing function that separates the concepts are experimentation platforms: when human-control of feature flags is shared (via dynamic configs) with automated & randomized assignments. That's how Statsig built their system and, in part, why they could sell for a billion. Whereas companies that ignored the difference, like LaunchDarkly, struggled outside of feature flags.

[1] https://engineering.atspotify.com/2020/10/spotifys-new-exper...

[2] https://docs.statsig.com/dynamic-config/overview https://blog.x.com/engineering/en_us/topics/infrastructure/2...

Re: Cloudflare Flagship

#169

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

Don’t forget they now also have an OpenRouter alternative.

[dead]

Re: Cloudflare Flagship

#170

Gold-plated booleans-as-a-service

I don't mind it. I don't want to keep track of thousands of feature flags in my DB, have to create an admin dash, etc. You could call any SaaS tool "excel-as-a-service" and it would hold the same power as your comment.

It makes sense to not want to create an admin dash, but to avoid having to keep track of thousands of feature flags in your db, it seems all you're doing here is moving them to another db
Post reply on HN