| (Author here) You are right about REST not necessarily replicating the N + 1 Query problem. ORMs have already provided solutions for this problem. See https://guides.rubyonrails.org/active_record_querying.html#e... for example. Looking at GraphQL as being a media type for REST misses the point because: 1) If you were to build a system that primarily used GraphQL for communication, you would be breaking the spirit of uniform resource constraint. Since the URI is the resource for REST, you would be having exactly 1 resource. The article talks a bit more about this.
2) The value add from GraphQL is primarily faster (and more efficient) front end development. So the question is do you want to implement the GraphQL media type? Typed vs non typed interfaces are a personal preference. Typing adds safety but historically made getting started harder. That has changed in the recent years though as tooling has significantly improved. I've talked about sparse field sets in the article. They are an alternative, but any form of query language requires a parser and implementation in the backend and GraphQL has good tooling for this. On the third point of N + 1 queries: Hasura compiles the sql query where possible and otherwise uses a batching technique for external APIs, similar to haxl. |
Apart from that, expressing queries in URIs is bloody hard.
I rather like the PostgREST approach.
Another idea is to POST queries to get a nice URI for each query, then you can GET the URI for a query using URI query parameters to supply values to the... query's parameters. (Look ma', no SQL injection.) PostREST gives you this if you wrap queries with functions, which is a bit sucky, but it gives the DB owner a lot of control over what queries get run.