4 ms·

This looks nice. > GraphQL turns the REST paradigm as it's usually implemented on its head: instead of providing a fixed structure of all types and relations i

This looks nice. > GraphQL turns the REST paradigm as it's usually implemented on its head: instead of providing a fixed structure of all types and relations in the system, GraphQL defines a schema which your users can query. I have no idea what that means.

paulddraper 9y ago
It doesn't mean anything, at least not anything correct. REST defines media formats, and the relationships are described by hyperlinks in the media. GraphQL is much the same in that it has a relational schema. The difference is that GraphQL has filter and join capabilities. Vanilla REST is usually all-or-nothing for a resource.
- derefr 9y ago
  The writer "meant it to mean" that, given a static REST-backend codebase, there will essentially be a static set of message schemas that will flow over the wire. (In "really dedicated to HTTP principles" REST, these are each indicated with their own application/vnd.org.example.barapp.v1.foo-message+json media type.) You could write C client with a `struct` definition for a given message type, and said code would never break, because a message of a given type always has that schema. GraphQL, meanwhile, allows the user to specify the "shape" of the result they want, by specifying what fields or associations they want to be included in the result—but these can also be parameterized, and the accessor-function that receives the arguments is free to do anything it likes with them, instead of just using them to select an association or field to pass back. It's effectively equivalent to the ability, in SQL, to do "SELECT arbitrary_function(field) AS column". There's no way to create a compile-time static type, especially on the backend, which could hold the response to an arbitrary GraphQL query. (Or, equivalently, you can think of a GraphQL response as being a tree of widely-product-typed fields, similar to modelling a decoded JSON object in a statically-typed language.)
  - paulddraper 9y ago
    > There's no way to create a compile-time static type Aren't you just saying that one GraphQL query corresponds to several REST requests? There is the same level of typedness between an arbitrary GraphQL query and an arbitrary set of REST requests.
    - derefr 9y ago
      It's somewhat hard to communicate my exact thought here... in REST, a given verb applies an operation to one resource, and a given resource has a known-at-compile-time representation, where the schema of the returned representation should have a domain that depends only on the referred-to resource itself—i.e. the request path—where the client picks from that domain using the Accept header. A GraphQL query, meanwhile, can include parameterize associations—essentially function calls—and these calls can have non-deterministic return types. I.e., you can't create a static set of types to describe the shapes a GraphQL response might take, because there is a non-finite (push-down automata number of states rather than FSM number of states) number of possible types to the value that the function might spit out. Or, to put that another other way: there's no way to receive a GraphQL response without the ability to dynamically allocate memory. You can't say "I want a response of exactly this shape" and then stream the decoded response into e.g. a protobuf. Because the client has no way of saying to the GraphQL parser, "don't vary your schema here." For GraphQL to be a proper "kind of" thing to use with HTTP, each association in the request would have to be able to take its own Accept-header-alike attribute, so that the client could ensure that if a response is produced, it is of a defined shape.
      - paulddraper 9y ago
        > there's no way to receive a GraphQL response without the ability to dynamically allocate memory You can allocate a fixed amount of memory for a particular GraphQL response. You can allocate a fixed amount of memory for a particular REST resource. You cannot allocate a fixed amount of memory for an arbitrary GraphQL query. You cannot allocate a fixed amount of memory for an arbitrary set of REST resources. So...I agree with what you are saying. At the the level of a single HTTP request, there is more dynamism in GraphQL. But that's not a deep distinction; REST just presents that dynamism at a level above a single HTTP request. --- Note: it is common for people to define sets of REST requests with function calls, but write GraphQL queries in a string. If you defined your set of REST requests in a string and wrote your GraphQL queries with function calls, you'd see many observations reversed.
  - dragonwriter 9y ago
    > The writer "meant it to mean" that, given a static REST-backend codebase, there will essentially be a static set of message schemas that will flow over the wire. (In "really dedicated to HTTP principles" REST, these are each indicated with their own [...] media type.) Which might, more to the point, include "application/graphql". In real REST, semantics are determined by media types of resource representations supported by endpoints. REST is not limited to mapping CRUD operations on a crude data model to HTTP verbs.
sametmax 9y ago
People usually implements web API by defining in advance a REST architecture with all the queries you can do when they expose their list of endpoints. Basically, it's a schema that doesn't say it's name, it's scatered and the user is stuck with it. With graphql, you have a smaller number of endpoints, but you have one big schema definition. You can then choose who to query it the way you want. This means not only that a graphql API is more flexible and easier have a entire view of, but also that GRAPHQL is a nicer generic data interface. You can use it not just for HTTP requests, but also between components. You can use it as a source of truth. You can allow joins without having to design them, and even easily implement several data sources for them, including caching. Graphql kinda have the benefit of SQL and a Web API.

paulddraper 9y ago

It doesn't mean anything, at least not anything correct. REST defines media formats, and the relationships are described by hyperlinks in the media. GraphQL is much the same in that it has a relational schema. The difference is that GraphQL has filter and join capabilities. Vanilla REST is usually all-or-nothing for a resource.

derefr 9y ago
The writer "meant it to mean" that, given a static REST-backend codebase, there will essentially be a static set of message schemas that will flow over the wire. (In "really dedicated to HTTP principles" REST, these are each indicated with their own application/vnd.org.example.barapp.v1.foo-message+json media type.) You could write C client with a `struct` definition for a given message type, and said code would never break, because a message of a given type always has that schema. GraphQL, meanwhile, allows the user to specify the "shape" of the result they want, by specifying what fields or associations they want to be included in the result—but these can also be parameterized, and the accessor-function that receives the arguments is free to do anything it likes with them, instead of just using them to select an association or field to pass back. It's effectively equivalent to the ability, in SQL, to do "SELECT arbitrary_function(field) AS column". There's no way to create a compile-time static type, especially on the backend, which could hold the response to an arbitrary GraphQL query. (Or, equivalently, you can think of a GraphQL response as being a tree of widely-product-typed fields, similar to modelling a decoded JSON object in a statically-typed language.)
- paulddraper 9y ago
  > There's no way to create a compile-time static type Aren't you just saying that one GraphQL query corresponds to several REST requests? There is the same level of typedness between an arbitrary GraphQL query and an arbitrary set of REST requests.
  - derefr 9y ago
    It's somewhat hard to communicate my exact thought here... in REST, a given verb applies an operation to one resource, and a given resource has a known-at-compile-time representation, where the schema of the returned representation should have a domain that depends only on the referred-to resource itself—i.e. the request path—where the client picks from that domain using the Accept header. A GraphQL query, meanwhile, can include parameterize associations—essentially function calls—and these calls can have non-deterministic return types. I.e., you can't create a static set of types to describe the shapes a GraphQL response might take, because there is a non-finite (push-down automata number of states rather than FSM number of states) number of possible types to the value that the function might spit out. Or, to put that another other way: there's no way to receive a GraphQL response without the ability to dynamically allocate memory. You can't say "I want a response of exactly this shape" and then stream the decoded response into e.g. a protobuf. Because the client has no way of saying to the GraphQL parser, "don't vary your schema here." For GraphQL to be a proper "kind of" thing to use with HTTP, each association in the request would have to be able to take its own Accept-header-alike attribute, so that the client could ensure that if a response is produced, it is of a defined shape.
    - paulddraper 9y ago
      > there's no way to receive a GraphQL response without the ability to dynamically allocate memory You can allocate a fixed amount of memory for a particular GraphQL response. You can allocate a fixed amount of memory for a particular REST resource. You cannot allocate a fixed amount of memory for an arbitrary GraphQL query. You cannot allocate a fixed amount of memory for an arbitrary set of REST resources. So...I agree with what you are saying. At the the level of a single HTTP request, there is more dynamism in GraphQL. But that's not a deep distinction; REST just presents that dynamism at a level above a single HTTP request. --- Note: it is common for people to define sets of REST requests with function calls, but write GraphQL queries in a string. If you defined your set of REST requests in a string and wrote your GraphQL queries with function calls, you'd see many observations reversed.
- dragonwriter 9y ago
  > The writer "meant it to mean" that, given a static REST-backend codebase, there will essentially be a static set of message schemas that will flow over the wire. (In "really dedicated to HTTP principles" REST, these are each indicated with their own [...] media type.) Which might, more to the point, include "application/graphql". In real REST, semantics are determined by media types of resource representations supported by endpoints. REST is not limited to mapping CRUD operations on a crude data model to HTTP verbs.

sametmax 9y ago

People usually implements web API by defining in advance a REST architecture with all the queries you can do when they expose their list of endpoints. Basically, it's a schema that doesn't say it's name, it's scatered and the user is stuck with it. With graphql, you have a smaller number of endpoints, but you have one big schema definition. You can then choose who to query it the way you want. This means not only that a graphql API is more flexible and easier have a entire view of, but also that GRAPHQL is a nicer generic data interface. You can use it not just for HTTP requests, but also between components. You can use it as a source of truth. You can allow joins without having to design them, and even easily implement several data sources for them, including caching. Graphql kinda have the benefit of SQL and a Web API.