Re:PostGraphQL: PostgreSQL meets GraphQL
by jrs95 on Tuesday December 13, 2016 @11:50AM
(#13168218)
Does GraphQL actually provide performance advantages right now? From what I've read about it, it seems like it suffers from a bit of an N+1 queries problem if you don't do a lot of custom optimization, which seemed like considerably more work than a REST API.
[ Parent
| on HN ]
Re:PostGraphQL: PostgreSQL meets GraphQL
by paulddraper on Tuesday December 13, 2016 @11:56AM
(#13168273)
Just like SQL, GraphQL needs a good query planner for complicated queries.
REST is more like a NoSQL database where you write all the joins by hand: on the plus side, you get to control the query execution, on the negative side, you have to control the query execution (also you have round-trips and lack some possible internal optimizations).
The "performance" of GraphQL refers to the fact that most things can be queried in one round-trip, rather than many for RPC, REST, or vanilla HTTP. Each of these are abstractions, not implementations.
So the maximum performance of GraphQL is better than the maximum performance of REST, particularly over mobile networks...as you said though, the devil is in the implementation.
fwiw I think Facebook's current implementation interfaces with a read-through cache. I think they've managed to make it fast without having to spend all of the effort on query planning that way.