I responded in a twitter thread[1], unrolled here here:
As all good things in life, and programming, this is a tradeoff. GraphQL is better when what you are requesting is best expressed as a tree (or a "graph", though only the DAG variety). This is not always the case, but it very often is when building API:s for production use.
Of course, you can express tree structures in table form, but it is not very convenient for clients to consume. In particular if your client is rendering nested component views, what you want is very often something hierarchical.
Another aspect of GraphQL that is better for us production people is that the performance is more predictable, exactly because the language is more restricted. You can't just join in all the things, or select billions of rows by accident. The schema dictates what is allowed.
Of course, again, it is possible to restrict this in SQL, just configure your schemas, limits etc appropriately, but SQL is anything-goes by default, whereas GraphQL is nothing is allowed by default. Whitelist vs Blacklist.
This said, as a language, SQL is clearly superior. It is the most (only?) successful 4GL (declarative) language. I wish more languages were this well-designed, and that there would be more language innovation in this direction.
The way I see it, GraphQL is a DSL for flexibly requesting hierarchical data from API:s in JSON format, optimized for complex evolving API:s. SQL is a full-fledged generic language for relational data transformation. They have different niches, but SQL has a much bigger one.
> a DSL for flexibly requesting hierarchical data from API:s in JSON format, optimized for complex evolving API:s
Perhaps the same goal could be achieved with more flexibility by issuing CONSTRUCT queries to a SPARQL endpoint (CONSTRUCT requests a custom RDF graph as opposed to a set of variable bindings ala SELECT) and obtaining results in JSON-LD format.
Exactly. I was always interested in all this semantic web stuff and as I have time now, I'm experimenting with Apache Jena. It's super neat! SPARQL endpoints use HTTP per default. "API for free" so to say. Plus you can even use a binary format for receiving the data. Querying the database is three lines of code in Kotlin. Fuseki (the SPARQL Server in Jena) also supports crazy stuff like "recursively traverse this graph by following the specified type of link until you can't go any further". I'm pretty sure this is not possible in GraphQL.
> You can't just join in all the things, or select billions of rows by accident.
How does GraphQL prevent you from selecting billions of things? I'm not too familiar, but if the answer is something like "you can limit to N results", SQL does have a LIMIT clause, so I'm unsure what is being meaningfully distinguished.
A good implementation will calculate the estimated "cost" of a given query before executing it. This is quite tricky to do well, and I doubt many people do it. Once you know the cost of a given query, it's trivial to reject it if it's too expensive.
A much better alternative is to only allow specific queries in production. These persisted queries can then be assigned an ID, and making a request is a matter of sending the ID with any variables.
It's very different. The main difference is that you define the capabilities on the back end through your GraphQL schema once, then clients generate the query ids through an automated process in development.
In the old way, someone would have to write backend code to build and maintain each individual endpoint. With GraphQL, you only maintain the schema on the backend.
As all good things in life, and programming, this is a tradeoff. GraphQL is better when what you are requesting is best expressed as a tree (or a "graph", though only the DAG variety). This is not always the case, but it very often is when building API:s for production use.
Of course, you can express tree structures in table form, but it is not very convenient for clients to consume. In particular if your client is rendering nested component views, what you want is very often something hierarchical.
Another aspect of GraphQL that is better for us production people is that the performance is more predictable, exactly because the language is more restricted. You can't just join in all the things, or select billions of rows by accident. The schema dictates what is allowed.
Of course, again, it is possible to restrict this in SQL, just configure your schemas, limits etc appropriately, but SQL is anything-goes by default, whereas GraphQL is nothing is allowed by default. Whitelist vs Blacklist.
This said, as a language, SQL is clearly superior. It is the most (only?) successful 4GL (declarative) language. I wish more languages were this well-designed, and that there would be more language innovation in this direction.
The way I see it, GraphQL is a DSL for flexibly requesting hierarchical data from API:s in JSON format, optimized for complex evolving API:s. SQL is a full-fledged generic language for relational data transformation. They have different niches, but SQL has a much bigger one.
[1] https://twitter.com/joakimlundborg/status/125091692202945740...