timsuchanek

You’ll still very likely end up with dozens of http REST calls that could be one GraphQL query, hence one http call. Bias alert (I’m the founder), but I believe you should have a look at GraphQL edge caching: https://graphcdn.io

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.

Yes, which we btw also offer. However, it's just one way to invalidate. The first request after the max age expired will still be stale, even if new content is refetched within the swr time frame - in certain applications not acceptable.

Most of our customers even use both things together to reduce the likelyhood for stale content.

Thanks blorenz! When working with Max, I was surprised how little he cared which library we use to get the job done. In fact, he's also a big fan of it. [0]

To be fair, we use the Tailwind system, but a lot of customizations on top.

[0] https://mxstbr.com/thoughts/tailwind/

Exactly, that is what we provide. Including Etag support btw.

The question that had to be asked :D First of all, with the current query string size, you can already send quite big queries (8kb), which should suffice for many use-cases. The introspection query, already quite huge for reference is 1kb. For the ones who need more - splitting the values into `Vary` headers is an option to further increase it. At some point - around 50kb there just is a hard limit. If you then want to send an even bigger query - we have persisted queries on our roadmap. Then you'd just send a hash.

Yes, but as long as a cached version is still returned at the edge (while the real content might have changed), the ETag won't help. It can only save you from unnecessarily downloading content you already have - in case it didn't change.

Thanks Michael, we just fixed it! In a few min it'll be deployed.

Under the hood, we're turning the POST requests into get requests, so that limitation shouldn't affect us. As far as I know, underlying C@E behaves like the one used in a VCL service.

That sounds correct! These are ways of purging we support today: 1. Automatic through mutations (if we can detect) 2. A purging api (GraphQL) - you can e.g. `purgeUser(id: 5)` 3. The usual Max age + SWR based invalidation

You can check out some more examples here: https://graphcdn.io/docs/cache-purging

Thanks a lot kenrose! We promise to not dare tackling the 3rd big problem in computer science... 2 are enough for now. And indeed - current CDNs (as powerful and great as they are) are not at all equipped to deal with GraphQL.

Many production GraphQL apps these days use persisted queries [0] via GET requests. So the HTTP caching itself is not an issue in GraphQL anymore.

[0] https://blog.codecentric.de/en/2020/05/how-to-secure-a-graph...

That makes sense! I like the versioning approach - of course requires apps to have a version for their entities, but if they have, that's indeed a great way to leverage it. And yes, that also sounds like a solution that wouldn't take months to build.

We give you a purging API (GraphQL as well) where you can target specific queries (`allUsers`) or types (`User`) that you want to purge. You can read more here: https://graphcdn.io/docs/cache-purging

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.

As of now, GraphCDN only caches queries. Subscriptions are just passed through to the origin - a normal WS connection is built. One WS connection counts as one request.

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.

Yes, it does! We have more and more people who want a more powerful cache setup than what Hasura offers or are just self-hosting Hasura. Both self-hosted and Hasura cloud work!

+1

That is not a naive, but very good question. Traditionally, many people assume, that GraphQL itself is hard to cache, while REST isn't, because REST can leverage HTTP's power, while GraphQL with its POST requests can't.

However, that is missing the point. What we need to talk about first is, how you want to invalidate your cache. Do you want to set a TTL of 60 seconds? That might work for certain apps - both in REST and GraphQL, but many apps can't afford stale content for such an amount of time.

You'll need cache invalidation when content changes. That on its own is a hard problem, no matter if REST, GraphQL or any other protocol. And it is one of the main reasons we built GraphCDN: Making it easy to purge the cache, when relevant content changed. How? We give you a purging api (also GraphQL) and additionally GraphQL has the concepts of mutations. Once you run a mutation through GraphCDN, it'll detect the relevant entities involved and purge the cache accordingly.

So - yes, in GraphQL caching on the surface might seem harder - but we're not just solving the "I can't cache POST requests" problem, but rather give you powerful cache purging - which is only possible due to the well-defined structure of a typed GraphQL Schema.

Because of that, we're actually thinking of providing REST "connectors" one day - turning REST into GraphQL, so you can have one unified interface that is easy to cache and invalidate.

I think it depends what you want as your cache invalidation policy. Simple TTL-based cache invalidation wouldn't necessarily need GraphCDN. However, no matter if REST, GraphQL or any other protocol - making sure, that when content changed, to invalidate it properly on the edge is not trivial.

If I understand correctly, you're suggesting to cache on a data-layer level (below the app in the stack) instead of what we do - above the app in the stack - just in front of the client.

That is also a valid approach. It'll need more custom code in your application and has the disadvantage, that your origin will still be hit on every request, while we fully cache on the edge - cached queries won't hit your server anymore and will take load off origin and have the minimum latency possible.

That is correct, you need to first transform the POST request into something Fastly can cache. They don't have a K/V Store besides the edge dictionaries with max 8kb value size yet, but I've heard something is coming...

Good question pbowyer! We actually do a bunch of GraphQL parsing / calculations in the Compute@Edge layer. So without that, we would not be able to provide our current features.

We also support a feature we call "scopes" - where we both support cookies and headers in the "Vary" header so you can cache user-specific data only for the user with a specific "Authorization" header for example.

In order to support scopes with cookies, we needed Compute@Edge and could not make that work with VCL on its own. But believe me - we tried. Our first version was actually mostly built on top of VCL.

Interesting to know. For enterprises we even go down with the price per million requests, as the volume is much higher and therefore the enterprise pays enough already.

Thanks @hcentelles, that's great to hear and gives us validation that there is a need!

Compared to Apollo Cloud: We're mostly focused on the caching part right now and have a different architecture where we are in your stack. Apollo runs a sidecar next to your application. We are a proxy in front of your API.

When it comes to the analytics part - which Apollo rather calls metrics, I think Apollo gives you field-level information, while we for now just have query-level information. However, we are fully server agnostic - you don't need to use Apollo Server. Any GraphQL API works. You just need to switch the URL in your clients. We even have customers just using the analytics part for now and disabling the caching in the beginning.

For the pricing: That is correct - you'd have about 50mio requests a month, so $500. However, the pricing there is not set in stone and we're happy to give you an early discount. Just contact us at support@graphcdn.io.

Right now only outside requests count as a request, no matter if cached or not. Purging calls might also count in the future.

On the first sight, the moat indeed is shallow. We have a great contact with Cloudflare and Fastly and exchanged our thoughts about exactly this already.

One of them actually recently looked into building their own solution. However, they realized, that in order to create something really valuable, you need at least a couple of months of dedicated engineering efforts of people who really understand GraphQL.

Our automatic and powerful cache invalidation - currently only possible with Fastly, a whole GraphQL-specific Analytics solution and a Security suite is nothing you can quickly clone.

Anyone of course can, but you need a highly GraphQL-specific product with many workflows like CLI workflows to upload your GraphQL Schema etc - it requires quite a bit of thinking and engineering to make that work.

Thanks a lot benjamoon ! It probably is the main animation on the landing page. We'll look into it - maybe we'll just disable the animation on mobile.

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!

Thanks Peter! Yes, we also think that there is a lot of exciting stuff happening in the space. However, we built GraphCDN because we think it's a very practical approach _today_. I think it will take a couple of years until edge compute becomes mainstream. You need your whole database etc on the edge, otherwise it doesn't make sense.

So we're happy about this level of abstraction, because any app can use it _today_!

Hey HN,

It's a pleasure to share this announcement with you! In all the GraphQL projects I worked on, it was always a pain to get the caching and security right.

Instead of you all spending time on building your own caching and security solutions, you can check out GraphCDN! It has powerful caching with invalidation in 150ms all around the planet. Powerful analytics showing you on a Query-level, how fast your queries are.

We're super grateful to be able to announce this today - ask us anything!