thunder

There are even more implementations of live queries available by now. e.g. https://github.com/samsarahq/thunder (go) or https://github.com/n1ru4l/graphql-live-query (JavaScript).

At Samsara our golang graphql implementation (https://github.com/samsarahq/thunder) works this way. We write out resolver functions using plain old go types and use some reflection magic at startup to compute the graphql type information. Our docs are a bit spare at the moment, but this means with code like: type User struct { Id int64 Name string } func rootUser(ctx context.Context, args struct { id int64 }) (*User, error) { // ... } schemaRoot.FieldFunc("user", rootUser); We can derive the graphql SDL types automatically (looking at the arguments and return values) and use them with other graphql tooling, but it saves folks time from writing out a separate schema and keeping it in sync.

I think this is something that graphql implementations are still trying to figure out. At work (samsara.com) we use a time-based batch[0] for our queries to help with n+1 issues in our graphql server. Separate branches of the the graphql query are handed to independent goroutines. When batchable rpcs (to the database, or other services) occur, we delay execution by ~1ms and wait for any other rpcs of the same type (and keep delaying for up to ~20ms). This works pretty well for our more expensive field resolvers. We've also thought about ways to examine and track the execution of the goroutines (similar to the facebook/dataloader approach), but the time-based batches have worked pretty well for us so far. We also aggressively cache queries and rpcs so that the same data is not expensive to fetch across different branches of a query. [0] Yo