4 ms·

REST != GraphQL

by lolive 5y ago

REST != GraphQL

hn_throwaway_99 5y ago
That's the whole point, GraphQL is an alternative framework for composing APIs, so comparing it to REST makes sense.
- deleted 5y ago
  [deleted]
Cthulhu_ 5y ago
Yeah we know they're not the same, can you explain what you mean by that? REST and GraphQL try to solve the same problem.
- lolive 5y ago
  I would say data oriented vs service oriented. But basically, the question comes down to where the DAO is. And what contracts are exposed Sounds to me like important questions, as a data engineer.
- JohnHaugeland 5y ago
  rest attempts to solve interface normalization between services graphql attempts to solve query normalization over a single api they're as related as a vcr and a broadcast system - the problems they solve are adjacent, but do not overlap, and whereas their default sensible use is together, they can both be used without the other, or with alternatives to the other
  - hn_throwaway_99 5y ago
    > the problems they solve are adjacent, but do not overlap I think this is just factually wrong. I've experienced many situations where exposing a GraphQL API, even when just intended to be called by another service, provided a number of advantages over a "plain REST" service, so we went with GraphQL, and I have seen other companies do the same. GitHub, for example, has a set of FAQs of "migrating from our REST APIs to our GraphQL APIs".
  - throw_m239339 5y ago
    I disagree. But it depends on your own definition of REST, which according to its "creator" is HATEOAS. GraphQL certainly is not HATOAS. REST is a philosophy while GraphQL is a spec. There is no "REST spec", HTTP isn't REST.
    - Zababa 5y ago
      By "REST" I meant the way it's mostly used, so "REST API" to mean "HTTP API with maybe a notion of resources", since REST is the term people use to talk about these things.
      - throw_m239339 5y ago
        REST is HATEOAS, as Roy Fielding said. "HTTP API" is something else, it's not REST. You can't just redefine words to suit your argument.
  - handrous 5y ago
    In practice, what I've seen is GraphQL used where REST[0] would have been. I've not seen it used in any case where the solution wouldn't, previously, have been REST, or in a case for which there would otherwise have been no solution. They are, de facto, competing tech, from what I've seen. I expect there are some examples where that's not true, but I think as experienced by most people it's an alternative to REST. [0] The colloquial sense of REST, that is, which is RESTish. Yes, I know, no-one actually does REST, for practically any value of "actually".
  - devit 5y ago
    GraphQL can be seen as a programming language to write API endpoints, which you can expose as HTTP endpoints in a RESTful way if you want (or use a single POST endpoint, or use WebSockets). In a traditional REST system you implement each API endpoint in a traditional programming language. With GraphQL you first create a single GraphQL model and then write each API endpoint as a GraphQL query/mutation; often the code is in the source of the client apps and is extracted by the build system to generate the endpoints on the server. It is also possible to let the client send arbitrary GraphQL at runtime to the server, although that's not recommended for security, performance and efficiency reasons. In practice this means that if you change the client frontend to include different details in views (e.g. you decide to change a GraphQL-enabled HN so that the bio of the comment author is shown below every comment) then you only need to change the frontend and the GraphQL query (to include the extra data you need) and not the server backend code.
Zababa 5y ago
You're right, but I proposed that to get an idea on how big is GraphQL compared to other things present in the same space. GraphQL doesn't replace REST and they can leave together, but still, if there are as many searches/results for GraphQL than for REST, or 10 times more, or 10 times less, it would say a bit more about its position. Edit: someone posted a comparative google trend in the thread: https://trends.google.com/trends/explore?date=all&q=REST,GraphQL,RPC https://trends.google.com/trends/explore?date=all&q=REST,Gra.... That's the type of info I expected.

REST != GraphQL

by lolive 5y ago

REST != GraphQL

hn_throwaway_99 5y ago

That's the whole point, GraphQL is an alternative framework for composing APIs, so comparing it to REST makes sense.

deleted 5y ago
[deleted]

Cthulhu_ 5y ago

Yeah we know they're not the same, can you explain what you mean by that? REST and GraphQL try to solve the same problem.

lolive 5y ago
I would say data oriented vs service oriented. But basically, the question comes down to where the DAO is. And what contracts are exposed Sounds to me like important questions, as a data engineer.
JohnHaugeland 5y ago
rest attempts to solve interface normalization between services graphql attempts to solve query normalization over a single api they're as related as a vcr and a broadcast system - the problems they solve are adjacent, but do not overlap, and whereas their default sensible use is together, they can both be used without the other, or with alternatives to the other
- hn_throwaway_99 5y ago
  > the problems they solve are adjacent, but do not overlap I think this is just factually wrong. I've experienced many situations where exposing a GraphQL API, even when just intended to be called by another service, provided a number of advantages over a "plain REST" service, so we went with GraphQL, and I have seen other companies do the same. GitHub, for example, has a set of FAQs of "migrating from our REST APIs to our GraphQL APIs".
- throw_m239339 5y ago
  I disagree. But it depends on your own definition of REST, which according to its "creator" is HATEOAS. GraphQL certainly is not HATOAS. REST is a philosophy while GraphQL is a spec. There is no "REST spec", HTTP isn't REST.
  - Zababa 5y ago
    By "REST" I meant the way it's mostly used, so "REST API" to mean "HTTP API with maybe a notion of resources", since REST is the term people use to talk about these things.
    - throw_m239339 5y ago
      REST is HATEOAS, as Roy Fielding said. "HTTP API" is something else, it's not REST. You can't just redefine words to suit your argument.
- handrous 5y ago
  In practice, what I've seen is GraphQL used where REST[0] would have been. I've not seen it used in any case where the solution wouldn't, previously, have been REST, or in a case for which there would otherwise have been no solution. They are, de facto, competing tech, from what I've seen. I expect there are some examples where that's not true, but I think as experienced by most people it's an alternative to REST. [0] The colloquial sense of REST, that is, which is RESTish. Yes, I know, no-one actually does REST, for practically any value of "actually".
- devit 5y ago
  GraphQL can be seen as a programming language to write API endpoints, which you can expose as HTTP endpoints in a RESTful way if you want (or use a single POST endpoint, or use WebSockets). In a traditional REST system you implement each API endpoint in a traditional programming language. With GraphQL you first create a single GraphQL model and then write each API endpoint as a GraphQL query/mutation; often the code is in the source of the client apps and is extracted by the build system to generate the endpoints on the server. It is also possible to let the client send arbitrary GraphQL at runtime to the server, although that's not recommended for security, performance and efficiency reasons. In practice this means that if you change the client frontend to include different details in views (e.g. you decide to change a GraphQL-enabled HN so that the bio of the comment author is shown below every comment) then you only need to change the frontend and the GraphQL query (to include the extra data you need) and not the server backend code.

Zababa 5y ago

You're right, but I proposed that to get an idea on how big is GraphQL compared to other things present in the same space. GraphQL doesn't replace REST and they can leave together, but still, if there are as many searches/results for GraphQL than for REST, or 10 times more, or 10 times less, it would say a bit more about its position. Edit: someone posted a comparative google trend in the thread: https://trends.google.com/trends/explore?date=all&q=REST,GraphQL,RPC https://trends.google.com/trends/explore?date=all&q=REST,Gra.... That's the type of info I expected.