4 ms·

I believe graphql can be added on top of your backend, even more - it can layer on top of multiple microservices backends to provide single api endpoint

by hippich 11y ago

fernandotakai 11y ago
the only problem is that, right now, there's no good lib that you can put on top of your existing infrastructure (for example, django's orm) that can translate graphql -> your-thing. i've been trying to write something like that, but it's kind of awkward, specially because the whole relay stack is not 100% feature stable.
- hippich 11y ago
  this is official reference lib - https://github.com/graphql/graphql-js https://github.com/graphql/graphql-js you need to implement resolve method to map properties to your backend(s) yes, it is not drop in, but using any node.js http request library should do the trick. also, both can co-exist if you have application which already uses existing rest api layer.
aikah 11y ago
> I believe graphql can be added on top of your backend, even more - it can layer on top of multiple microservices backends to provide single api endpoint It is exactly what I'm saying. It's yet another layer on the server, it doesn't solve caching issues, and it will certainly not make your average app faster, especially when http2 support is here. GraphQL is an ORM for rest apis. I thought rest apis were supposed to be universal, why need another layer on top of it? How many ORMs do developers need ? how much more complex does it have to get? The goal of REST is first and foremost readability and simplicity. The purpose of fat clients are to push complexity on the client. With graphQL simplicity is gone since everything is POST thus no http caching, and the server now gets another layer of complexity instead of being client agnostic. Again, it might make sense at Facebook scale, but many articles promoting GraphQL are not talking about the fact that, it might not make sense for the majority of applications out there, even worse, it actually might make apps slower because of that extra layer.
- j_s 11y ago
  GraphQL is an ORM for REST APIs. If accurate, this might be the key take-away from this discussion.
  - estefan 11y ago
    It's not REST
    - j_s 11y ago
      I think the point was that GraphQL can slice & dice REST interfaces like an ORM, not that GraphQL is REST. I believe this is a part of the story - GraphQL can sit in front of any datasource, not just REST-based ones.
- hippich 11y ago
  it all depends. with graphql your backend can become really stupid and just handle saving and retrieving data, making it super easy to deploy, scale, archive, etc. on the other hand having super dump backend makes it expensive to query data, since we have light speed limit for roundtrip between request and response at best. what graphql does - it shifts point which does all these multiple requests closer to the storage layer and return you processed results based on query you asked. if you application already returns rich data structures - graphql is probably do not belong here (right now). if you develop true microservices architecture - graphql sitting on top of it certainly might make sense. as usual - it depends :)
- lobster_johnson 11y ago
  > GraphQL is an ORM for rest apis No, GraphQL is a protocol that replaces REST. Its closest analogue is the unholy beast that is SOAP + WSDL, except without the insanity of XML. With SOAP/WSDL you declare a schema for your API, which then accepts API calls containing parameters. SOAP/WSDL follows a classical RPC paradigm where you execute functions that take positional arguments. GraphQL dispenses with that terminology, but is still very much RPCish. A key difference is that "arguments" are keyword-based. Where SOAP/WSDL would have you pass a "complex type" (ie., a struct) with optional fields, in GraphQL everything is built out of structs. Another key difference is that the output follows the structure of the input. GraphQL remaps REST's paths to nested keys. For example, given the routes: /books /books/:id /books/:id/authors This becomes: query { book(id: ...) { authors } } Where REST doesn't help you is when you want to be able to filter on a lot of things — either your API becomes an explosion of all permutations of relationships, or you do (as many do) create a "query API" that takes all sorts of criteria as inputs. For example: When you get a books' authors you might want to filter by editors only. Or you want to find all books written by an author that were published in the 1950s. REST also doesn't help the client pick which fields to include, or which relationships to follow. Sure, you can implement it on top of REST, but any such solution becomes ad-hoc and app-specific. Part of that is, firstly, because REST is a set of rules, not a complete protocol, and secondly, REST wants to deal with resources, not queries. Queries (ie., POST to some collection) are left as an exercise for the reader. Coincidentally, there is no reason why you can't encode GraphQL queries as GET URLs via paths: /books/id=1/year=1950..1959/authors/name=~John This probably violates the tenets of REST, which says that resource URLs should uniquely identify a resource. I forget what REST says, if anything, about "views" into resources.

I believe graphql can be added on top of your backend, even more - it can layer on top of multiple microservices backends to provide single api endpoint

by hippich 11y ago

I believe graphql can be added on top of your backend, even more - it can layer on top of multiple microservices backends to provide single api endpoint

fernandotakai 11y ago

the only problem is that, right now, there's no good lib that you can put on top of your existing infrastructure (for example, django's orm) that can translate graphql -> your-thing. i've been trying to write something like that, but it's kind of awkward, specially because the whole relay stack is not 100% feature stable.

hippich 11y ago
this is official reference lib - https://github.com/graphql/graphql-js https://github.com/graphql/graphql-js you need to implement resolve method to map properties to your backend(s) yes, it is not drop in, but using any node.js http request library should do the trick. also, both can co-exist if you have application which already uses existing rest api layer.

aikah 11y ago

> I believe graphql can be added on top of your backend, even more - it can layer on top of multiple microservices backends to provide single api endpoint It is exactly what I'm saying. It's yet another layer on the server, it doesn't solve caching issues, and it will certainly not make your average app faster, especially when http2 support is here. GraphQL is an ORM for rest apis. I thought rest apis were supposed to be universal, why need another layer on top of it? How many ORMs do developers need ? how much more complex does it have to get? The goal of REST is first and foremost readability and simplicity. The purpose of fat clients are to push complexity on the client. With graphQL simplicity is gone since everything is POST thus no http caching, and the server now gets another layer of complexity instead of being client agnostic. Again, it might make sense at Facebook scale, but many articles promoting GraphQL are not talking about the fact that, it might not make sense for the majority of applications out there, even worse, it actually might make apps slower because of that extra layer.

j_s 11y ago
GraphQL is an ORM for REST APIs. If accurate, this might be the key take-away from this discussion.
- estefan 11y ago
  It's not REST
  - j_s 11y ago
    I think the point was that GraphQL can slice & dice REST interfaces like an ORM, not that GraphQL is REST. I believe this is a part of the story - GraphQL can sit in front of any datasource, not just REST-based ones.
hippich 11y ago
it all depends. with graphql your backend can become really stupid and just handle saving and retrieving data, making it super easy to deploy, scale, archive, etc. on the other hand having super dump backend makes it expensive to query data, since we have light speed limit for roundtrip between request and response at best. what graphql does - it shifts point which does all these multiple requests closer to the storage layer and return you processed results based on query you asked. if you application already returns rich data structures - graphql is probably do not belong here (right now). if you develop true microservices architecture - graphql sitting on top of it certainly might make sense. as usual - it depends :)
lobster_johnson 11y ago
> GraphQL is an ORM for rest apis No, GraphQL is a protocol that replaces REST. Its closest analogue is the unholy beast that is SOAP + WSDL, except without the insanity of XML. With SOAP/WSDL you declare a schema for your API, which then accepts API calls containing parameters. SOAP/WSDL follows a classical RPC paradigm where you execute functions that take positional arguments. GraphQL dispenses with that terminology, but is still very much RPCish. A key difference is that "arguments" are keyword-based. Where SOAP/WSDL would have you pass a "complex type" (ie., a struct) with optional fields, in GraphQL everything is built out of structs. Another key difference is that the output follows the structure of the input. GraphQL remaps REST's paths to nested keys. For example, given the routes: /books /books/:id /books/:id/authors This becomes: query { book(id: ...) { authors } } Where REST doesn't help you is when you want to be able to filter on a lot of things — either your API becomes an explosion of all permutations of relationships, or you do (as many do) create a "query API" that takes all sorts of criteria as inputs. For example: When you get a books' authors you might want to filter by editors only. Or you want to find all books written by an author that were published in the 1950s. REST also doesn't help the client pick which fields to include, or which relationships to follow. Sure, you can implement it on top of REST, but any such solution becomes ad-hoc and app-specific. Part of that is, firstly, because REST is a set of rules, not a complete protocol, and secondly, REST wants to deal with resources, not queries. Queries (ie., POST to some collection) are left as an exercise for the reader. Coincidentally, there is no reason why you can't encode GraphQL queries as GET URLs via paths: /books/id=1/year=1950..1959/authors/name=~John This probably violates the tenets of REST, which says that resource URLs should uniquely identify a resource. I forget what REST says, if anything, about "views" into resources.