7 ms·

Another reason to use GraphQL. No more endless discussion about which HTTP codes to use, which HTTP action to use, how to send in data, how to format your respo

Another reason to use GraphQL. No more endless discussion about which HTTP codes to use, which HTTP action to use, how to send in data, how to format your response, ...

brailsafe 6y ago
How does GraphQL allow you to not worry about those things?
- RedShift1 6y ago
  GraphQL only uses two HTTP methods (GET and POST). But they actually don't differentiate in their function: you can do any type of reading/writing kind of queries in both GET and POST requests[1]. POST requests are used because they allow for larger bodies. GraphQL defines the format of the reponse in case of errors[1] GraphQL doesn't use HTTP status codes to communicate out-of-the-ordinary conditions. You can expect to always get HTTP status 200[1] The data response is a mirror of the query you sent in with the data present[2] How to query for data is explicitely laid out[3] How to send in parameters is explicitely laid out[4] [1] https://graphql.org/learn/serving-over-http/ https://graphql.org/learn/serving-over-http/ [2] https://graphql.org/learn/ https://graphql.org/learn/ [3] https://graphql.org/learn/queries/#fields https://graphql.org/learn/queries/#fields [4] https://graphql.org/learn/queries/#variables https://graphql.org/learn/queries/#variables
  - davidbanham 6y ago
    And when intermediate proxies happily retry your small “delete the most recent record” request because it was a GET which is, in the rest of reality, guaranteed not to alter state on the receiving server except in the corner of the internet you’ve defined as your own it’s destructive?
    - RedShift1 6y ago
      You can use GET for read queries and POST for write queries. Edit: actually you made me think a little bit more about this, if you can make your mutations idempotent, spurious retried POST requests shouldn't be a problem at all. However "delete the last record" is not an idempotent operation by definition but also one you wouldn't use in the real world - usually you delete by ID. Edit 2: it's easy to make the server reject mutations sent via GET.
    - masklinn 6y ago
      RPC over HTTP pretty much always goes through POST, sometimes with the option of using GET for querying as an optimisation. For graphql specifically, if you allow GET-ing the GraphQL endpoint (which usually isn't the case by default), it's trivial to ensure only queries go through that method.
  - nojvek 6y ago
    AFAIK graphql does have response error codes. You should always have response error codes no matter the form of api. They are semantic info.
    - RedShift1 6y ago
      GraphQL does not have response error codes. It only dictates that any response that has errors, should have an "error" field. It is not defined what this error field should contain, it can be a string or an object with a code and text, etc...
      - nojvek 6y ago
        I could be wrong. Some of the graphql servers I have interacted with have given me useful error codes. E.g GitHub. We do have nice wrappers around the request to raise a proper named exception regardless so it doesn’t matter.
dmitriid 6y ago
And adds a bunch of other endless discussions: how to cache data (POST is not cacheable), how to auth data (anyone has access to everything), how to...
- RedShift1 6y ago
  I don't feel like this is added by GraphQL because you'll have these questions regardless of using GraphQL. how to cache data (POST is not cacheable) -> You can use GET requests and GET requests are cacheable. how to auth data (anyone has access to everything) -> Authentication or authorization? What do you mean with anyone has access to everything? how to... -> yes?
  - dmitriid 6y ago
    > You can use GET requests and GET requests are cacheable. GET requests are a crutch added to GraphQL precisely because of limitation of POST requests. And the backend still has to normalise the GET request, and possibly peek inside it to make sure that it is the same as some previous request. > how to auth data (anyone has access to everything) -> Authentication or authorization? What do you mean with anyone has access to everything? Your schema is a single endpoint with all the fields you need exposed. Oh, but a person X with access Y might not have access to fields A, B, C, and D. Too bad, these fields can appear at any level of the hierarchy in the request, deal with it. > how to... -> yes? A GraphQL query is ad-hoc. It can have unbounded complexity and unbounded recursion. Ooops, now you have to build complexity analysers and things to figure out recursion levels. A GraphQL service usually collects data from several external services and/or a database (or even several databases). But remember, a GraphQL query is both ad-hoc and with potential unbounded complexity. Oh, suddenly we have to think how much data and at what time to we retrieve, how do we get the data without retrieving too much, and without hammering the external services and the database with thousands of extra requests. That's just from the top of my head. Ans so you end up with piles of additional solutions of various quality and availability on top of GraphQL servers and clients: caching, persisted queries etc. etc.
    - RedShift1 6y ago

Another reason to use GraphQL. No more endless discussion about which HTTP codes to use, which HTTP action to use, how to send in data, how to format your response, ...

brailsafe 6y ago

How does GraphQL allow you to not worry about those things?

RedShift1 6y ago
GraphQL only uses two HTTP methods (GET and POST). But they actually don't differentiate in their function: you can do any type of reading/writing kind of queries in both GET and POST requests[1]. POST requests are used because they allow for larger bodies. GraphQL defines the format of the reponse in case of errors[1] GraphQL doesn't use HTTP status codes to communicate out-of-the-ordinary conditions. You can expect to always get HTTP status 200[1] The data response is a mirror of the query you sent in with the data present[2] How to query for data is explicitely laid out[3] How to send in parameters is explicitely laid out[4] [1] https://graphql.org/learn/serving-over-http/ https://graphql.org/learn/serving-over-http/ [2] https://graphql.org/learn/ https://graphql.org/learn/ [3] https://graphql.org/learn/queries/#fields https://graphql.org/learn/queries/#fields [4] https://graphql.org/learn/queries/#variables https://graphql.org/learn/queries/#variables
- davidbanham 6y ago
  And when intermediate proxies happily retry your small “delete the most recent record” request because it was a GET which is, in the rest of reality, guaranteed not to alter state on the receiving server except in the corner of the internet you’ve defined as your own it’s destructive?
  - RedShift1 6y ago
    You can use GET for read queries and POST for write queries. Edit: actually you made me think a little bit more about this, if you can make your mutations idempotent, spurious retried POST requests shouldn't be a problem at all. However "delete the last record" is not an idempotent operation by definition but also one you wouldn't use in the real world - usually you delete by ID. Edit 2: it's easy to make the server reject mutations sent via GET.
  - masklinn 6y ago
    RPC over HTTP pretty much always goes through POST, sometimes with the option of using GET for querying as an optimisation. For graphql specifically, if you allow GET-ing the GraphQL endpoint (which usually isn't the case by default), it's trivial to ensure only queries go through that method.
- nojvek 6y ago
  AFAIK graphql does have response error codes. You should always have response error codes no matter the form of api. They are semantic info.
  - RedShift1 6y ago
    GraphQL does not have response error codes. It only dictates that any response that has errors, should have an "error" field. It is not defined what this error field should contain, it can be a string or an object with a code and text, etc...
    - nojvek 6y ago
      I could be wrong. Some of the graphql servers I have interacted with have given me useful error codes. E.g GitHub. We do have nice wrappers around the request to raise a proper named exception regardless so it doesn’t matter.

dmitriid 6y ago

And adds a bunch of other endless discussions: how to cache data (POST is not cacheable), how to auth data (anyone has access to everything), how to...

RedShift1 6y ago
I don't feel like this is added by GraphQL because you'll have these questions regardless of using GraphQL. how to cache data (POST is not cacheable) -> You can use GET requests and GET requests are cacheable. how to auth data (anyone has access to everything) -> Authentication or authorization? What do you mean with anyone has access to everything? how to... -> yes?
- dmitriid 6y ago
  > You can use GET requests and GET requests are cacheable. GET requests are a crutch added to GraphQL precisely because of limitation of POST requests. And the backend still has to normalise the GET request, and possibly peek inside it to make sure that it is the same as some previous request. > how to auth data (anyone has access to everything) -> Authentication or authorization? What do you mean with anyone has access to everything? Your schema is a single endpoint with all the fields you need exposed. Oh, but a person X with access Y might not have access to fields A, B, C, and D. Too bad, these fields can appear at any level of the hierarchy in the request, deal with it. > how to... -> yes? A GraphQL query is ad-hoc. It can have unbounded complexity and unbounded recursion. Ooops, now you have to build complexity analysers and things to figure out recursion levels. A GraphQL service usually collects data from several external services and/or a database (or even several databases). But remember, a GraphQL query is both ad-hoc and with potential unbounded complexity. Oh, suddenly we have to think how much data and at what time to we retrieve, how do we get the data without retrieving too much, and without hammering the external services and the database with thousands of extra requests. That's just from the top of my head. Ans so you end up with piles of additional solutions of various quality and availability on top of GraphQL servers and clients: caching, persisted queries etc. etc.
  - RedShift1 6y ago