Hacker News Reader

Comment by 0xy | Hacker News Reader

This is a super interesting project and thanks for posting it.

I'm just wondering why you decided on Fastly over Cloudflare Workers or AWS Lambda Edge for this?

Good question! These are the main reasons:

Fastly has much faster cache purging - it can purge any content globally in about 150ms. Purging is one of THE crucial parts which make GraphCDN work. With such a fast purging, we can deliver Read-after-write consistency . In our tests with Cloudflare that took a few seconds.

Additionally, in our tests, Fastly was in general just a bit faster.

While we're also JavaScript and V8 fans, our edge layer on Fastly is written in Rust - which is a pleasure to use, especially for a product as ours. Fastly runs it as WASM on the edge - they can load the worker in about 40 microseconds.

Fastly Compute@Edge is still in limited availability, but if you get a chance, I highly recommend checking it out!

Man, we had this exact use case and a similar solution designed but we weren't able to get access to Fastly's new edge compute.

Now you can just use GraphCDN and don't have to build it yourself! ;)

This was at a fairly large enterprise that utilized Fastly, and has since switched to Akamai. We had many meetings with our AM and their architects to get access to their compute engine over multiple years but never could get them to open the doors. If I could migrate our GraphQL services to a new domain, I'd certainly try it out!

> we can deliver Read-after-write consistency

Based on the comment on max below that's not read-after-write consistency but it just becomes eventually consistent but ideally within ~150ms. What would be the consequences of bypassing the cache for read after write, does that break your model in any way? (I guess at the very least you will lose your statistics feature)

In all mutations you run through GraphCDN, we wait until the purging is done (as you said, ideally ~150ms). So that means at the point the mutation result comes back to the client, all other queries will get the new content from then on.

You can bypass the cache if you want to, but it's not necessary. As it would just be like a Cache MISS, that would totally work.

I suppose that means writes slow down with the number of dependencies/ dependent caches? How does one estimate the added cost of that write?

Well, that depends on the purging characteristics of Fastly - this blog post is quite nice to read https://www.fastly.com/blog/building-fast-and-reliable-purgi...

We have a limit - you can only "tag" up to 1k items within one query. If you have more items in there, we can't purge all of them.

Due to the nature of the broadcast protocol of Fastlys purging implementation, I assume that it scales quite well - they have really big customers using this for a few years already.

There is a big difference if you're using fastly's cache purging for simple cache invalidation without consistency requirements or if you are trying to do something like you're building.

We're using Fastly ourselves and I was not aware up until today (and in fact I'm taking your word for it, since I can't find it in the docs) that fastly provides consistency guarantees for purges.

> it can purge any content globally in about 150ms

Hmm, how can that be? Light in a straight-line fiber optic cable would take 200ms to traverse a greater circle around the world. Add some bends, relays, routers, not to mention servers, and it'll only get longer...

Are you sure the content is really being purged globally in that time, and not just from your local point of presence?

(Disclosure: I'm an engineer on Cloudflare Workers. I have no idea how Fastly does purges. Just trying to understand what you mean here...)

What do you mean by greater circle? The circumference of the earth is 40,075,000 m. Speed of light is 299,792,458 ms. So we're talking about 40,075,000 / 299,792,458 = 0.1337 -> 134ms to get around the earth once. As the earth is an ellipsoid that is mostly perfectly round, you can assume, that from any point A to B you'll just need to travel half of that, so we're at 67ms for light speed.

Looking at the 150ms now, which is about 2.3 times the 67ms, this kinda seems reasonable.

And yes, this is global purging - I just reconfirmed it with someone from Fastly.

That's the speed of light in a vacuum. The speed of light in fiber optic is slower.

Travelling half of the distance is not good enough, because if you haven't received _confirmation_ of the purge, then you can't trust that it really happened. There could be network errors, etc.

Sorry but it's not physically possible to do a global purge in 150ms.

Reply on news.ycombinator.com