Hi, I’m Sean, and I’ve been convinced there are better ways to develop applications across the stack for years, and built time-traveling debuggers, interface builders, layout tools, and graphic design tools in his quest to explore the space. Before starting OneGraph, I was VP Engineering at PayGarden and part of the Y-Combinator Summer 2011 batch with Bushido.
Persisted Queries as Legos vs Clay: What if calling your GraphQL API were as simple as calling a serverless function?
GraphQL and REST seemingly sit on two sides of a valley: GraphQL with its dynamic flexibility and great introspection tooling, across from REST with its fantastic ops support for familiar, static endpoints. In this talk, Sean will go into persisted queries, or storing GraphQL queries on the server for clients to reference later, is a technique that promises to bridge the gap, and to not only combine the best of both worlds, but also to enable entirely new kinds of apps and APIs!
Does the cash and persistence of a query stick to a user auth? You talked about allowing others to use my auth, but I don’t want to do that. I am interested in persisting queries so that if the same user requests the same query it would provide the same data.
Also, interested in how this relates to changes in the db side of it. When does a request go to the db to see if the data changes? I sort of want the best of both worlds, persisted queries and live data, cache data, and authenticated data.
Hey Anthony, you can indeed handle the cache/auth case - in fact, it’ll work with existing REST/http cacheing tools and infrastructure! You can simply make a GET request to the persisted query and pass the doc_id, operationName, etc. as query variables, and use the Vary: Authorization header in the response. To all of the intermediate tooling, that looks exactly like the equivalent REST, and means, “Cache the result of this request for this long, but only when the Authorization/cookie header is exactly the same”.
Re: the db, the result of a query won’t be stored in a db typically, just the GraphQL query document itself, so you’re free to use whatever live-update mechanism you’re currently using.
Long story short, yes, all of that’s achievable! Thanks for the question (including the Swift type question, heh)!
i enjoyed your thorough, austute presention and use-case explanation today though i missed the link provided by the host for the t-shirt (isp edge-router replaced a couple of days ago - still spotty).
