REST vs. GraphQL – A search for evidence on which is better

For me this is the point that I feel isn't well argued against by GraphQL proponents. Why if I'm a Javascript developer with probably a similar learning curve I couldn't just whip up a simple stateless frontend (in Node since its the same lang) and write the query in SQL? More to the point the skills learnt by doing so are more transferable. You also give your data store a chance to be more performant (e.g. better query plans for a typical DB) using that DSL to query the data store and there's a lot less complexity (components, libraries) in your solution.

Also from what I've seen the approaches that may result in single ideal query plans in your database increase the complexity of GraphQL significantly with "GraphQL to SQL" compilers which still may not give tuned SQL especially with large graphs. Reminds me of using ORM's where often the generated SQL wasn't performant/slow. Even if it does work the complexity of your solution just increased - all for what? To translate one query language into another? There's also times where it may pay NOT to expose too much of your internal domain structure to public API's which I feel from a naive developer's perspective GraphQL could encourage (direct internal API structure to contract mappings).

It feels, at least to me, that it is another abstraction layer that solves a problem that could also be solved at the org level. If there's suddenly a use case that requires a tuned query/algorithm/index as well (happens a lot from my experience) then its easy to add as a separate endpoint and test for regression test against other endpoints/use cases supported.

This is more or less what dataloader accomplishes. Generally speaking when creating a gql service, graph traversal is not app code but library code.

Dataloader avoids the N+1 but I wouldn't call it a good solution, you have to twist your app code to make it work. Its an inelegant solution, imo.

The language here is getting a little squirrly. "Can't be a hypertext" is too restrictive. "Isn't a hypertext" is how I would say it.

JSON as JSON isn't a hypertext in the same way that XML as XML isn't a hypertext. XHTML is a hypertext based on XML. (HTML itself isn't proper XML.)

There are hypertext specs based on JSON, such as: https://json-schema.org/draft-04/json-schema-hypermedia.html

But, without clients that treat the data as a uniform interface, it's all mostly pointless, which is why most JSON APIs stop at Level 2 of the Richardson Maturity Model, and why things like GraphQL are becoming more and more popular.

In the original model of the web (which is what Fielding was describing w/ REST) where HTML was being delivered to a browser, the uniform interface works: a browser has no idea what the HTML document means but can render it to a form that the human looking at it can make sense of.

That query is completely contrived (doesn't match anything I'm working on), but here's what the response would look like:

    {
        "products": {
            "abc123": {
                "id": "abc123",
                "name": "Some Widget"
            },
            "def456": {
                "id": "def456",
                "name" "Some Other Widget"
            }
        },
        "images": {
            "xyzabc": {
                "id": "xyzabc",
                "product_id": "abc123"
                "url": "https://example.com/xyzabc"
            }
        },
        "reviews": {
            "4": {
                "id": "4",
                "product_id": "abc123",
                "user_id": "hjk453"
                "review": "This thing sucks!"
            }
            "15": {
                "id": "15",
                "product_id": "abc123"
                "user_id": "pos999"
                "review": "I love this thing!"
            }
        },
        "users": {
            "hjk453": {
                "id": "hjk453",
                "handle": "somebody",
                "name": "Some Body"
            },
            "pos999": {
                "id": "pos999",
                "handle": "someone",
                "name": "Some One"
            }
        }
    }