[joshribakoff]

You wrote..

> GraphQL, like SQL, doesn't have any place for naming the use-case of a request

This is not true, see the docs:

> The operation name is a meaningful and explicit name for your operation. It can be very useful for debugging and server-side logging reasons

https://graphql.org/learn/queries/

You wrote...

> There is no inherent reason why a service cannot expose an SQL API

GraphQL let's you query across backends, such as relational (SQL), graph databases, REST APIs, it is backend agnostic. You're comparing apples to oranges, SQL & GraphQL are different abstractions.

[derefr]

SQL is backend agnostic. And I'm constantly surprised that people aren't aware of this, especially the people who think that a DB needs to be "NoSQL" just because it necessarily can't support all the features that SQL offers. No RDBMS supports 100% of the features in the SQL standard, either! It's okay to "support SQL" in a way where you just throw errors if 90% of SQL's syntax is used! Many systems do that! Clients are Required by the SQL standard to cope with that!

Every modern DB labelled "NewSQL" is fundamentally just a "NoSQL" database that has been made to speak SQL. Sometimes it is, in fact, literally a previously-built NoSQL database, with an SQL adapter layer like https://en.wikipedia.org/wiki/Presto_(SQL_query_engine) used as middleware.

And your application can speak SQL, too! It's not that hard to:

1. grab an SQL2016.y grammar file and generate a parser for it in your language-of-choice;

2. expose a port on your daemon that speaks a protocol wire-compatible with some particular RDBMS's wire protocol, e.g. the https://www.postgresql.org/docs/current/static/protocol.html (like CockroachDB has done.)

If you do these two things, then other programs can connect to your app as a database, and use their ORM tools to handle your data model. (Consider this option if you're ever developing e.g. an MMORPG server; it can save hundreds of hours of work in exposing new APIs and deprecating old ones, for the cost of a little front-loaded work.)

---

But I digress.

You can make any application layer, or database layer, speak GraphQL. Because it's a syntax for relational algebra, and relational algebra is just "How You Describe Relationships When Making Requests." It has nothing to do with the fundamental underlying schema of the data; it's a language for communicating your intent—the things you want to get, or the things you want to change—by naming them through their relationships to other things.

Now replace "GraphQL" with "SQL" in the above and notice that nothing changes.

[joshribakoff]

1 - I don't have to fork my database to use graphQL... it was designed to be an API gateway.

2 - forking databases to speak the same language still doesn't solve the issue of how to coalesce data from multiple backends into one response. You need an API gateway for that.

3 - forking a db would take months or years for me. I added graphQL to my stack in a few hours without modifying my backends, again because it's designed as an API gateway.

Yes they both declare data requirements. But no they aren't both relational and only one of these two technologies was designed as an API gateway.