[zzbzq]

That might look more like graphQL over websockets with realtimes updates. Somebody told me about an already-existing GraphQL with real-time push updates ready-made for integrating with the front-end framework, wish I knew the name of whatever this was, but maybe somebody will chime in.

Not sure how anything is RESTful anymore once it's over websockets. The whole point of REST is it's a perfection of HTTP, and the whole point of HTTP is it's the slowest, most awkward networking protocol ever devised made to pander to the browser's flaccid capabilities.

[jondubois]

One problem with GraphQL is that there can some overlap between the results of different queries so it can be wasteful. Also access control is more difficult because a GraphQL query might reference multiple different data types which have different access control rules (a user may only be allowed to see part of the query result) - So it makes access control a lot more complicated.

[lwansbrough]

Facebook has a solution for over-fetching, which they call dataloader.

As for the access control problem: it's easily solved with existing features of GraphQL. GraphQL exposes a user context which can be referenced on a per-property basis and thus used to check the permissions of the user.

[yen223]

Those aren't trivial problems to solve in a traditional REST framework either. In GraphQL, having one whole query delivered upfront means the server can do some clever query-planning and app-level caching to efficiently fetch its required data. REST endpoints can't do that, since the queries will be spread across multiple network requests.

[hn_throwaway_99]

Here is what's on the horizon: https://dev-blog.apollodata.com/new-features-in-graphql-batc...

Subscriptions already exist: https://dev-blog.apollodata.com/graphql-subscriptions-in-apo...

[x5t23]

Here is an example how to do realtime subscriptions with GraphQL

https://www.graph.cool/docs/tutorials/worldchat-subscription...