It's understandably a little difficult to extract all of the relevant context out of that thread in the issue tracker, but the current consensus is indeed that this feature should be built with a plugin system--on top of the database's existing query language and feature set.

The plugin system will provide a sort of middleware layer alongside the database so that we don't have to bake in a lot of things that are domain specific or only relevant to particular use cases.

There's more discussion about the plugin system here: https://github.com/rethinkdb/rethinkdb/issues/4785

(Disclosure: I work at RethinkDB)

To be fair, GraphQL is, just like SQL, a query language, it specifies "what" the client wants, not "how". There is no "baking in the database". Which means, the server can use SQL or NoSQL or graph or XML database, or LocalStorage or any combination of them, to provide a response to a query -- it does not matter, long as the response is there.

This client-server separation setup has been around for some decades, and it obviously works well. For example, there is a bunch of NoSQL databases that will accept at least some SQL syntax. That is good.

GraphQL is not a query language at all. It's an API-building DSL. It's analogue isn't SQL, it's REST. Or WSDL + SOAP.

It does not have things like filtering, ordering, subqueries, etc. -- you can implement those things, but that would be just one possible implementation, specific to your data model. You wouldn't be able to point just any GraphQL client at it; the client has to know what to ask for, and how.

GraphQL is almost totally unrelated to graphs, it's a way to compose API requests in a manner that fits modern web / mobile usage patterns better than REST. GraphQL has nothing to do with the actual representation of the data. I think the name has led to a lot of misconceptions.

Hi I'm Nick Schrock and I actually came up with the name. Graph in this context means social graph or more generally the conceptual graph of data in your application, which you can query. It doesn't mean that it is a formalized graph database in any sort of way, nor does it seek to be.

I understand the name causes a bit of confusion but the ship has kind of sailed on this one :-) I think people will get used to it if/when it becomes a widely known name.

Ironically, the "query language" part also misses the mark, and I think that part confuses people more (as in that RethinkDB discussion).

GraphQL is closer to what we call a protocol; it has minimal syntax, a kind of data model, and it can only be used for declaring requests. You can't implement anything in GraphQL: absolutely all of its expressions are implementation-provided — contrast with, say, SQL, which, being an actual query language, defines operators, arithmetic expressions, mutations, etc. A defining quality of a protocol is that it's a medium through which clients can talk to multiple black-box implementations, which is exactly what GraphQL is.

I like GraphQL, but I wish you'd thought through the name before you started to publish about it. If you'd called it something like Extensible API Protocol, nobody would have batted an eyelid.

I'm sure you're right because you have the power of facebook behind you but yeah the name is problematic. I agree with lobster_johnson in that it's not a "query language" either, it's more like an analogue of JSON.

Virtually every graph database vendor now gets requests that they implement GraphQL, because from the name it sounds like it fits but in reality it's totally unrelated.

Oh, right, I've encountered examples before of Facebook saying "graph" when they mean "API".

That sounds like an even sillier thing to put in a database, then.

It's a query language. Every database supports at least one query language. It's certainly reasonable to argue that natively implementing multiple query languages is "bloat" or "feature creep" (as some in the comment thread point out and suggest alternate approaches to avoid), but I don't think it's silly.

APIQL would have been a better name