timsuchanek

9 ms·

31.
by timsuchanek 4y ago
Actually 11 by now ;)
32.
by timsuchanek 4y ago
Tim, Co-Founder here. Yes, this applies to everyone within the company, including the founders and investors.
33.
by timsuchanek 5y ago
Depends how fast your data changes. SWR can be very effective for that. I suggest having a look at GraphCDN (bias alert, I’m one of the founders, so take it with some salt ;)
34.
by timsuchanek 5y ago
You could do that or directly cache at the edge [0] - makes it much faster for the user and is cheaper. https://graphcdn.io does that.
35.
by timsuchanek 5y ago
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
36.
by timsuchanek 5y ago
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
37.
by timsuchanek 5y ago
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 acceptabl
38.
by timsuchanek 5y ago
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
39.
by timsuchanek 5y ago
Exactly, that is what we provide. Including Etag support btw.
40.
by timsuchanek 5y ago
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.
41.
by timsuchanek 5y ago
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
42.
by timsuchanek 5y ago
Thanks Michael, we just fixed it! In a few min it'll be deployed.
43.
by timsuchanek 5y ago
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.
44.
by timsuchanek 5y ago
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
45.
by timsuchanek 5y ago
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.
46.
by timsuchanek 5y ago
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-gra
47.
by timsuchanek 5y ago
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 t
48.
by timsuchanek 5y ago
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
49.
by timsuchanek 5y ago
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
50.
by timsuchanek 5y ago
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.
51.
by timsuchanek 5y ago
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. Yo
52.
by timsuchanek 5y ago
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!
53.
by timsuchanek 5y ago
+1
54.
by timsuchanek 5y ago
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. Howev
55.
by timsuchanek 5y ago
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 chan
56.
by timsuchanek 5y ago
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...
57.
by timsuchanek 5y ago
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" - wh
58.
by timsuchanek 5y ago
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.
59.
by timsuchanek 5y ago
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. Apol
60.
by timsuchanek 5y ago
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 r

More ›