16 ms·

Interview with Christian Schwendtner “GraphQL is good, but it’s not an alternative to ‘real’ REST services“ https://jaxenter.com/graphql-good-no-alternative-re

Interview with Christian Schwendtner “GraphQL is good, but it’s not an alternative to ‘real’ REST services“ https://jaxenter.com/graphql-good-no-alternative-rest-services-142814.html https://jaxenter.com/graphql-good-no-alternative-rest-servic...

masklinn 8y ago
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.
- krainboltgreene 8y ago
  > 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. Browsers seem to work fine, unless it's just been a tiny human inside my computer this entire time?
  - masklinn 8y ago
    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.
    - krainboltgreene 8y ago
      > 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.
      - masklinn 8y ago
        > No, but that's not what rest means? 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.
derefr 8y ago
I wouldn't say GraphQL is an alternative to REST. 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.
- headcanon 8y ago
  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.
  - derefr 8y ago
    > 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.
jrs95 8y ago
HATEOAS is a great idea. So is CQRS + event sourcing. But the implementation doesn't live up to the idea on paper.
- jmakeig 8y ago
  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.)

masklinn 8y ago

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.

krainboltgreene 8y ago
> 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. Browsers seem to work fine, unless it's just been a tiny human inside my computer this entire time?
- masklinn 8y ago
  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.
  - krainboltgreene 8y ago
    > 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.
    - masklinn 8y ago
      > No, but that's not what rest means? 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.

derefr 8y ago

I wouldn't say GraphQL is an alternative to REST. 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.

headcanon 8y ago
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.
- derefr 8y ago
  > 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.

jrs95 8y ago

HATEOAS is a great idea. So is CQRS + event sourcing. But the implementation doesn't live up to the idea on paper.

jmakeig 8y ago
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.)