Even though the underlying implementation details differ, at a high level GraphCDN and GraphQL clients are actually kind of similar. Our gateway analyzes incoming GraphQL queries and outgoing results and caches them accordingly. When it sees a GraphQL mutation change a piece of data it invalidates any cached query result that contains that stale data.
Over to you, Phil.
Hiya 👋 If you don't know me, I'm a web engineer, and have been working with the React community since around its inception. You may know me from some Open Source projects, like
styled-components (which is how I met Max), smaller projects like
urql, the now third most popular choice in the community for GraphQL clients.
I've always been passionate about Open Source projects and pushing the boundaries of certain spaces I'm interested in, and that's how I found myself working on a GraphQL client, while bringing my usual perspective into the mix. I like to approach problems from first principles and create intuitive APIs that remain versatile over time and choose the correct constraints.
What I like best is working on projects that allow people to do things they couldn't do before. This can be small things, like making it easier to write parsers, or larger things, like making it easier to write complex GraphQL apps. GraphCDN feels like a natural progression of that, in a space and community I'm already familiar with.
It also aligns with a lot of what I see GraphQL being and becoming. As I've said, I see GraphQL as a beautifully balanced combination of old ideas, a specification that a large community is aligning on, and a protocol that allows a lot of complicated problems to be automated away. GraphCDN is essentially right on top of all of this: It leverages GraphQL for yet another tough problem.
Also, it has a lot of potential to both champion this perspective on GraphQL in the community, and bring GraphQL to even more established players in and outside of our industry. All while using other delightful tech, for instance edge-compute.