Hey HN,<p>When I built my last startup, Spectrum, we spent months building custom caching for our GraphQL API from scratch. It never worked well enough to alleviate our scaling troubles as we could only cache data for unauthenticated users since we had no invalidation. (since we open sourced it all before GitHub acquired us, you can even read through my terrible code[0])<p>When Tim told me he had built a prototype of a CDN specifically for caching GraphQL query results with proper invalidation, my first thought was: "Finally!" Not only had he made it possible to cache POST requests (which GraphQL requests usually are), he had made it possible to purge cached query results per specific GraphQL object. For example, when a user edits their name the API can call a purgeUser(id: $ID) mutation and any cached query result that contains that user's data is invalidated.<p>GraphCDN is based on Fastly Compute@Edge under the hood, which is really the main reason we were able to spin this up so quickly. Huge shoutout to the folks building that!<p>We'll be around all day to answer any questions you have about GraphCDN — ask us anything!<p>[0]: <a href="https://github.com/withspectrum/spectrum/blob/alpha/api/apollo-server.js" rel="nofollow">https://github.com/withspectrum/spectrum/blob/alpha/api/apol...</a>
Hey HN,<p>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.<p>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.<p>We're super grateful to be able to announce this today - ask us anything!
I asked Max in private, but i'll ask again here for visibility.<p>How do you handle smart invalidation? Or more specifically, how do I trust that you're handling smart invalidation _correctly_. Looking at the site, it indicates that calling a mutation like `editUser(id: 5)` would presumably invalidate the User type record with ID 5.<p>But how do you actually do this reliably? There's nothing in the spec that would indicate the argument ID maps to a record of a certain type with an id field of the same value. Max indicated that you make assumptions based on the return type of the mutation, e.g. editUser has a return type of User, therefore you can infer the relationship. This might be _generally_ true, but it's not 100% reliably true. Additionally, my mutations _never_ just return the naked entity type like this, there's always a wrapping payload type (philosophically, the mutation payload should contain points to all the parts of the graph that _may_ have changed as a result of the operation). Editing a User doesn't _just_ edit a User, the effects on the graph can propagate far and wide. Another point here is that my mutations are rarely just CRUD operations, but more CQRS in nature, they're built to support a specific system capability rather than allowing generic write operations.<p>The problem of smart invalidation seems to have the exact same shape as smart store invalidation/updates after a mutation in the client. Even after all these years, Relay only does fairly superficial automatic updates, you nearly always have to use custom updaters (or client-side directives in some cases) to get the client-side store back in sync after anything but the most trivial mutations.
Pardon me for asking a perhaps naive question, but how is this not a solution to a self-inflicted problem? Using a normal restful HTTP api has none of these issues. What is the big problem that GraphQL solves, and is it really serious enough to reinvent existing infrastructure for it?
This is such a great idea!<p>There are a lot of plays in this space that try to move the database, or serverless-functions closer to the end-users, but in all likeliness if you're already building a single-page-app the static content is already on a CDN and close to your customers, so this gives you a very easy way to increase performance dramatically without having to modify your infrastructure.<p>Awesome!
I’ve being waiting for a product like this for some time now, I think there is a huge (not yet served) market for this. I’ve tried to implement something using Cloudflare workers, but failed, also tried to use Apollo Cloud trough a Apollo Federation server in front of my (non Apollo Server) API, failed too.<p>Some questions:<p>How it compares with Apollo Cloud on feature set terms?<p>My graphql server load is like 20 request/s average. At first the pricing looks a little bit intimidating for me, but running the numbers it looks like $500/m, is that right? Hopefully it will offset some of my origin servers costs.<p>What count as a request? Just request coming from the “outside” or also calls to purge for example?<p>I’ll be trying GraphCDN soon, maybe even today.<p>Good luck
Two hard problems solved:<p>1. Cache invalidation
2. Decent project name<p>Joking aside, this is great. Traditional CDNs + GraphQL always felt like an impedance mismatch.
I don't see any mention of support for subscriptions on your website. Is that currently supported or is it on the roadmap?<p>Also to seed an idea for you, it'd be great if you were somehow able to provide subscriptions dynamically based upon queries and mutations being performed.<p>Acting as the middleman, you can see the freshest data and so therefore know when something updates. If I could hook that up to my existing GraphQL API and not have to worry about eventing and subscription services for every single object that would be a huge value add for me.
I've always felt that there should be a cloud hosted object database that should be query-able via graphql. It should offer auth and access rules like firebase.<p>Really don't want to maintain a server. I love firebase for that reason, although querying it is a pain sometimes. Would love to make graphql queries so I can fetch multiple things in a single call.
Looks really good, well done! Just fyi, I noticed my phone (new iPhone) got really hot when looking at your site. I’ve had this before on sites and it’s usually a bug or a really tight loop somewhere that’s causing high cpu usage (maybe the animations). Sometimes it’s not high enough to notice on a laptop or full pc, but it’s enough to warm up a phone.
GraphCDN seemingly is an innovative service I'll be checking out, though I just wanted to comment that the app is a beautiful example of the use of Tailwind. I was a little taken aback because I was presuming styled-components but was delighted to see the well-executed use of one of my favorite libraries!
Q: Is the CDN cache consistent? i.e if I delete or change an object, does it immediately reflect across all the POPs across the globe?<p>If so what are the potential read/write/latency speeds we can expect per object?