2016 GraphQL Conference takeaways

joelisawesome.com

3 points·mrskitch··2 comments

Regarding predefined queries, is the idea to be like a View in SQL [1]? Notwithstanding the abstraction benefit that brings, doesn't that negate one of the claimed advantages of GraphQL vs. something like a REST API: that the client is in full control of assembling the query, and can request specific fields, receiving only as much or little information as it needs? Contrast that with a resource-based API, where the server has decided the schema and form that the responses will take ahead of time.

In either case, I can see the benefits of pre-defined queries. I have raised this [2] (along with others [3][4]) as a possible trade-off to improve cacheability; prior to us the prospect of 'prepared statements' (in SQL parlance) was raised as a performance and security benefit [5][6][7].

[1] https://en.wikipedia.org/wiki/View_(SQL) [2] https://news.ycombinator.com/item?id=12500412 [3] https://news.ycombinator.com/item?id=12502226 [4] https://news.ycombinator.com/item?id=12504587 [5] https://forums.meteor.com/t/kadiras-learn-graphql-project/11... [6] https://medium.com/the-graphqlhub/graphql-tour-variables-58c... [7] http://www.rubydoc.info/github/rmosolgo/graphql-ruby/file/gu...

The idea was rather intriguing, however I haven't ran into perf issues in clients yet where this would be beneficial.It does sort of negate one of the benefits of the spec, which is human-readable static queries.

It did very much feel like prepared statements. There was even talk of some implementations of predefined queries as a mechanism to whitelist queries, which was interesting.

I hope we'll see more about this as projects grow and eventually need it.

Reply on news.ycombinator.com