That's really nice, but "real REST services" have never really been a thing, because the reality of "real REST services" is, at the end of the day, that they're not very useful or convenient for machines to consume.
REST works in browsers because there's an intelligent agent driving the interaction. For an automated system it's just pointless drudgery and unnecessary extra requests and data. GraphQL basically fixes all the slow bits, by allowing for a single query in which the client specifies exactly what they want, it cuts down drastically on both the number of network round-trips and the size of data retrieved. And at the end of the day, that means it also (by and large) cuts down on server resources, because those extra connections and that extra data to extract & format is not free.
So GraphQL ends up being both more convenient and more efficient than "real REST services", and that's before we even get to the self-documentation from the schema and to graphiql explorers, which are superior to what "real REST services" could (but never did in my experience) (even less so as browsers kept on not supporting anything other than GET and POST) have provided.
Did your browser somehow post this comment on its own, on your behalf, without you being involved in any way?
I'm guessing no, and that's exactly why REST work. The tiny human is not inside the computer, it's sitting between the keyboard and screen, able to (to a very variable extent) intelligently interpret every document's information and react on the fly depending on their whims and needs.
> Did your browser somehow post this comment on its own, on your behalf, without you being involved in any way?
No, but that's not what rest means?
It did accurately figure out that a file was CSS and to pain the DOM, JS is a program and to run it, to automatically display any images of the correct type and not explode when it sees a image of a type it doesn't know about, and it showed me actions I could click.
It kinda is, if there's no interaction back and forth the entire thing is completely trivial.
> It did accurately figure out that a file was CSS and to pain the DOM, JS is a program and to run it, to automatically display any images of the correct type and not explode when it sees a image of a type it doesn't know about,
Little of which is of any use to two automated systems interacting without human intervention, and the bits which are of use are not hard.
> it showed me actions I could click.
That's the useful bit when working with an API, knowing that an action can be performed and being able to perform that action.
And that's where REST falls down, because at the end of the day it's not very helpful or convenient at programmatically exposing and allowing these interactions for automated systems.
Again, very good when there's an intelligent and flexible meat bag at one end of the interaction, but that's not what APIs are for in colloquial use.
GraphQL is (a DSL syntax for) a restricted subset of SQL—one that's restricted enough that it's okay to allow arbitrary clients from the public Internet to request of you.
Like SQL, though, its proper place is "inside" the API abstraction-layer, not "outside" it. GraphQL queries, like SQL queries, are things your backend app-layer logic can generate and send to your DB layer (presuming your DB layer supports GraphQL.)
There are certain APIs where you might want to expose the ability to use GraphQL to modify the composition of the tree of data-structures returned by a particular controller-route. But this doesn't mean you should be using GraphQL "as" your API. GraphQL here is just a parameterization of your API, like result-set pagination. The API itself still needs to exist regardless of GraphQL, and needs to speak something that allows for all the standard CRUD operations.
Respectfully, this is false. First, GraphQL is not a subset of SQL, nor is it in any way related to SQL. Second, GraphQL is designed for safe client-server interaction. GraphQL is not a query language in a traditional sense, it is simply a syntax for a consumer to describe how the data it receives should be structured. This does not preclude server-side usage as well, however.
While a real-life application may want to expose a REST interface, there is no inherent reason why a service cannot expose a GraphQL-only API, and each client only consume that API.
> First, GraphQL is not a subset of SQL, nor is it in any way related to SQL.
I didn't mean to imply the language syntaxes are related. But they're both syntaxes for relational algebra, and GraphQL has a strict subset of SQL's capabilities in terms of what relational-algebra queries/mutations it can express. (I.e. GraphQL can express joins, but only inner joins with an aggregate projection on the left side; and GraphQL can express projections, but only trivial projections applying the identity function to a subset of the available tuple fields.)
(Note that other, more powerful graph manipulation languages, e.g. Datalog or SPARQL, are also syntaxes for relational algebra. They're similarly limited in some ways compared to SQL—and yet the types of queries they express easily would balloon out to hundreds of lines of SQL.)
> there is no inherent reason why a service cannot expose a GraphQL-only API, and each client only consume that API.
There is no inherent reason why a service cannot expose an SQL API, either, provided you lock down the restrictions on the role the DB is acting as (both in terms of ACLs on DML query types, and in terms of caps on compute time, memory, etc.)
But people don't do that, and they avoid it for more than just the challenging ops story it implies. You don't expose SQL-based APIs to the public internet, because you tend to build APIs to service the needs of particular clients with particular use-cases, and those use-cases can be optimized for by adding things like caching middleware, but only if you can filter out and tag the particular use-case each request is for. REST lets you do that; the use-cases are directly named by the (method + origin + path), and the semantics are already there, built into the protocol, for caching them, substituting them, access-controlling them, etc.
GraphQL, like SQL, doesn't have any place for naming the use-case of a request, in the request. So, if you want any of the useful properties like cacheability or access-control or whatever else to apply, you probably want your GraphQL request to appear "inside" a RESTful request, such that you still have individual REST endpoints for particular use-cases.
> 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.
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;
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.
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.
You seem to be confusing graphql with something graph-like but completely unrelated. It was fully designed as an external API protocol. At no point is it intended to sit between your server and your DB, though I guess you could use it that way if you really wanted to.
> The API itself still needs to exist regardless of GraphQL
I think maybe we're using "API" differently, here? GraphQL lets you query and mutate an object graph, but things exist that can't be (canonically, compactly) represented as a tree of objects. And usually at least a few of those things are necessary for any given API.
For example, how do you implement your AAA login logic using GraphQL? You don't, right? Logging in isn't really anything to do with querying or mutating an object tree. (You can deform your logic into making it so, but you'll be breaking things like the ability to do OpenID Connect.)
How do you implement an endpoint to stream chat message events in GraphQL? You don't, right? You want a stream of trees? A tree of stream-poll-results? There's an impedance mismatch here.
You want to use GraphQL to upload attachments? Use GraphQL for webhooks? Use GraphQL for Operational Transformations in a Google Docs-alike? No, no, no.
GraphQL is useful for implementing the message-format of particular endpoints of an API. It doesn't work for all endpoints. Unless your API is entirely just about a particular object graph, you still need to put your GraphQL inside a larger abstraction that distinguishes the GraphQL endpoints from the other endpoints.
HATEOAS is designed so clients and servers can evolve independently, like on the open web. If you control both ends, HATEOAS is probably overkill. (And that’s ok.)
REST works in browsers because there's an intelligent agent driving the interaction. For an automated system it's just pointless drudgery and unnecessary extra requests and data. GraphQL basically fixes all the slow bits, by allowing for a single query in which the client specifies exactly what they want, it cuts down drastically on both the number of network round-trips and the size of data retrieved. And at the end of the day, that means it also (by and large) cuts down on server resources, because those extra connections and that extra data to extract & format is not free.
So GraphQL ends up being both more convenient and more efficient than "real REST services", and that's before we even get to the self-documentation from the schema and to graphiql explorers, which are superior to what "real REST services" could (but never did in my experience) (even less so as browsers kept on not supporting anything other than GET and POST) have provided.