61–70 of 87 posts
The previous Worker in-front of the cache never made sense to my old school proxy in-front of the appserver mindset. Already using this to speed up a tool. Nice work.
Finally proper stale-while-revalidate support!
Reinventing the web, one service at a time. Is it really that hard to build things like this on a per-case base, small scale, all on a bare bones VPS? Do we need a global gateway to help us not screw up the basics? Service looks nice but makes me sad somehow.
The feature is great. The post itself is a slop grenade.
One of the recent AI tells other than em dash is the excessive usage of hyphenated words: > multi-tenant-safe cache keys > on a server-rendered app > byte-for-byte identical (classic) > gets a cache-speed response > cached-file-extensions list Honestly, this is terrible. I had to add a "use simple words only, don't hyphenate unnecessarily" warning to my Claude config. After a full day of work, having to read these Cl…
Also, most engineers will likely just be skimming this article before feeding it into their harness to implement the changes anyway, so it makes sense for it to be more heavy on context than it would be if meant for only humans to consume.
Time to migrate rarely-updating websites that still need a CMS to Cloudflare.
> One thing to watch: when caching is enabled, requests that are normally free — static asset requests and worker-to-worker invocations through service bindings or ctx.exports — are billed at the standard request rate, because each one now consults the cache in front of your Worker.
That’s a very weird limitation from a product standpoint. You might end up spending more money by enabling caching.
I wonder if static assets and worker-to-worker invocations are really more expensive to them with caching enabled, or if this is just a metering problem.
I would have made this free in the interest of making billing simpler and of making the decision to enable caching more straightforward.
If you’re min-maxing costs, this encourages awkward setups where you split workers into two, one with caching enabled and one with caching disabled.
> This is the caching API we've always wanted Workers to have. Here's why it took us this long I was looking forward to the "why it took us this long" explanation but it wasn't explicitly spelled out. Any Cloudflare staff here able to expand on that? (The article does a good job of showing how many different smart design decisions went into this, but given caching is core to what a Cloudflare does I'm still a little…
We implemented the "standard" Cache API back in the early days because it was a standard, one which was intended to be used together with the Service Workers API, which we were also building around back then.
But it was never a good fit. The get/put API was designed for a local browser cache, not a distributed cache like Cloudflare's. We probably should have realized this before implementing it, but it really became obvious over the years of actual use.
But given we had something that mostly worked for most use cases, it was hard to prioritize redoing it against all the other things on our plate. So we deferred.
More recently, architectural changes we've been making in Workers for other reasons happened to make it significantly easier to finally implement this the way we wanted, and we were able to find some engineering time to get it over the line.
Gory details for the curious: We've been improving the infrastructure around the notion of workers having multiple "entrypoints", with the ability to parameterize those entrypoints. ctx.props[0] and ctx.exports[1] are part of this. A lot of this was motivated by Dynamic Workers sandboxing, but the concept also presents a clean way to inject a cache between two parts of the same worker, by applying it to the entrypoint and having the worker call itself using ctx.exports.
Moreover, the introduction of "channel tokens" made a big difference[2][3]. Essentially I created a way to encode a token (bytes) representing an arbitrary entrypoint to a Worker, complete with its serialized parameters. I did this to enable these entrypoint stubs to be passed over RPC, which is again useful for sandboxing use cases, but it also created a convenient, encapsulated way to pass information through our cache infrastructure about what worker should run at the other end.
It's not a huge breakthrough or anything, but I think it made the architecture clearer in everyone's mind to the point that we got excited about using it to implement caching properly, finally.
[0] https://developers.cloudflare.com/workers/runtime-apis/conte...
[1] https://developers.cloudflare.com/workers/runtime-apis/conte...
[2] https://github.com/cloudflare/workerd/blob/main/src/workerd/...
[3] https://github.com/cloudflare/workerd/blob/main/src/workerd/...
The previous Worker in-front of the cache never made sense to my old school proxy in-front of the appserver mindset. Already using this to speed up a tool. Nice work.
But now the platform has evolved to where you’re running the entire app from Workers.
Earlier quoted context omitted.
I have an over-hyphenated writing-style as well. Probably my Germanness.
There is not reason whatsoever to hyphenate "writing style".
> What's the competition in the gaming-capable pre-built mini-PC category
Earlier quoted context omitted.
At least for me I don't really read these posts/docs, I just give the link to claude and it'll implement it regardless of wording
This is also 100% what I just did. In fact, I think companies should be releasing a human readable format as well as a machine readable format.
I think you are looking is the signal separated from the noise. I read technical documents very quickly while having very high retention and comprehension. The AI slop and AI content generation is pushing my limits.
'AI summarization' is what I naturally or learned to do growing up. I read your request as 'human readable format' being something more conversational or perhaps with known intent: inform the human.
It is not possible. Socratic method is the better path to learning. AI can make it easier.
Suggestion: AI, summarize and then ask me questions about this topic in increasingly more difficult questions, and after passing the depth of this document push further into the deeper fundamentals and first principals of the topic.