This does not apply to Cloudflare, especially not for an auth token that needs to be published on your website that cannot be restricted.
I think you're thinking this:
> If you are not embarrassed by the first version of your product, you've launched too late. -Reid Hoffman
There is no way 6 months ago someone at CloudFlare thought it was a good idea to build a competitor to say LaunchDarkly.
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
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
Their core network stuff always seemed pretty robust but all the newer stuff was much more thrown together. Thinking specifically of Zero Trust/Argo Tunnels which has been around a few years (and I do like) but has some rough edges.
Here's why we built it!
How many minutes do I need to wait until app-scoped tokens are live?
How can we possibly trust the AI to disable the 'CODE_IS_SKYNET' flag.
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?
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.
Not sure if that's possible/how easy it is on Vercel
> 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.