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

Workers Cache

blog.cloudflare.com

Post reply on HN
Print view View original

81–87 of 87 posts

Re: Workers Cache

#81

Post by drdexebtjl »

kentonv wrote: post #79
drdexebtjl wrote: post #76

Earlier quoted context omitted.

Does that new architecture make it more expensive to serve worker’s static assets and do worker-to-worker invocations? Or just harder to measure? This change in billing makes enabling caching not such a straightforward decision, and encourages separating cached and non-cached parts of your workers into two separate workers, which is a bit annoying.

I wasn't personally involved in pricing here so I can't really say exactly why it is the way it is. However, I'd note that, in terms of our costs, it's often cheaper for us to run your Worker than to serve from cache. Consider that Workers run locally in whatever edge location the request landed in. We are not saving any bandwidth costs by putting the cache in front of Workers rather than behind, and we've built an a…

No objection towards charging for cache hits, when the worker would have ran. That (except in worker-to-worker invocations) is always a strict upgrade, when it comes to pricing.

Worker-to-worker invocations also now participate in the cache, so despite the pricing increase, at least we’re getting some added value.

But for static assets in particular, I don’t see what value the cache is adding, so it feels like pure price segmentation.

Or, to put it another way, you were already caching the static assets and not having the workers serve them. Now you're doing the same thing, but charging for it.

Re: Workers Cache

#82

Post by swiftcoder »

pizzafeelsright wrote: post #72
swiftcoder wrote: post #40

Earlier quoted context omitted.

It does feel a bit like the LLMs have commoditised correct writing form, and all the plebs are all up in arms about it...

I read the slop and each has a smell. Each model and company does because the humans behind it have their own taste, smell, and perspective. The human element cannot be recreated because the human element that created the beast becomes further removed and only the beast remains. I say beast to provide a tell that what I write is 'human'.

Yeah, I mean, slop is easily recognisable by structure and content. But the obvious "markers" everyone claims (emdashes, hyphenation, etc), are just the writing style taught in the predominantly ex-British-colonial schools where the labellers were educated

Re: Workers Cache

#83

Post by danabramov »

Xirdus wrote: post #33
napsterbr wrote: post #18

Earlier quoted context omitted.

There is a world of difference between well-written human text and sloppy walls of AI-generated text. There's nothing wrong in using hyphenations or emdashes -- I use them myself! That's not the point of my comment.

Whether we like it or not, em dashes are effectively verboten in online discussions and blog posts if you want people to take you seriously. If the idea that excessive hyphenation is an AI tell gains traction, it too will become impossible to use without ruining your credibility.

This is not true. I regularly get HN front page hits, and still use em dashes. Nobody accuses me of AI writing. Writing with em dashes is not a problem if you have something to say.

Re: Workers Cache

#84

Post by tarasglek »

kentonv wrote: post #71
kentonv wrote: post #67

Earlier quoted context omitted.

The honest answer is: 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,…

Realizing there's a more fundamental piece I'm not explaining well here. Our architecture is something like: ingress -> routing -> security -> workers -> cache -> origin That is, workers run "in front of" cache. That's usually what you want. Workers run on the edge, so putting them in front of cache doesn't cost anything in terms of latency, and there's a lot of useful stuff you can do only if they run in front, e.g.…

blog post didn't cover two details re stale-while-revalidate:

1. What headers does content that will revalidate use on client. Eg can a react hook trigger if a cms json revalidates?

2. If edge worker can call database worker: if database worker sends stale while revalidate, does that revalidate whole worker chain?

btw overall very cool, esp fine grained cache for authed/etc data

Re: Workers Cache

#85

Post by skrebbel »

davidmurdoch wrote: post #19
skrebbel wrote: post #10

Earlier quoted context omitted.

"slop" doesn't mean "AI generated content", it means bad content, a waste of the reader's time. Grantparent's implication is that your comment was bad content, not that it was AI generated bad content.

I was riffing off of the meaning from https://noslopgrenade.com/ which made its way around the comments here on HN a few weeks ago.

Ah, fair

Re: Workers Cache

#87

Post by dbbk »

sidcool wrote: post #80
dbbk wrote: post #58

I was a bit confused what this adds other than just standard CDN-Cache-Control page caching that we do now. Some quirks I've found; - You still get billed per request, whether the request hits cache or not (but don't get billed for CPU time) - You now get billed for static asset requests! This makes no sense to me. "One thing to watch: when caching is enabled, requests that are normally free — static asset requests a…

CPU time is not billed

I said that
Post reply on HN