6 ms·

I don't think there's any surprise that GraphQL reduces the size of the responses compared to typical REST (excluding things like JSON:API). If that's the measu

by rocmcd 7y ago

I don't think there's any surprise that GraphQL reduces the size of the responses compared to typical REST (excluding things like JSON:API). If that's the measurement that's most important, then it seems GraphQL is the obvious choice. For myself, the 'practicality' of GraphQL would be more on complexity of the implementation, training of engineers, potential re-implementation of client logic, ease and depth of debugging, performance, etc. It seems these days that the size of the response is not typically a limiting factor in most applications I've interfaced with (though maybe I've never been exposed to that world before). Can anyone speak to how a migration from REST to a GraphQL went? My biggest concern is around the complexity of the thing. It just seems so much more complex than REST, but maybe I haven't spent enough time with it.

dmitryminkovsky 7y ago
What’s the complexity you’re thinking of? In my experience, GraphQL is so much simpler than REST. There’s a whole category of thinking you don’t have to engage in (is this POST? PUT?). And to start I wouldn’t migrate from REST. I’d wrap a REST service with GraphQL and take it from there.
- adamscybot 7y ago
  That essentially means you are still overfetching underneath the hood but yeh -- for me the benefits are in its ergonomics anyway. The whole under/overfetch thing is overstated.
  - dmitryminkovsky 7y ago
    Locally, yes. But that’s not a big deal unless your network is that saturated. Also, with wrapping we’re just talking first steps. Anyway the overfetching thing is less about bandwidth and more about maintaining compatibility with older clients and knowing which clients require which fields. Since each GraphQL client explicitly states the fields it needs, it’s much easier to retire old fields.
- dmitriid 7y ago
  > There’s a whole category of thinking you don’t have to engage in (is this POST? PUT?) There’s a reason that category of thinking exists. But since GraphQL libs are now busy implementing caching in top of non-cacheable POST requests, this argument is lost on them.
  - dmitryminkovsky 7y ago
    > There’s a reason that category of thinking exists. What's the reason? > But since GraphQL libs are now busy implementing caching What are you referring to? You mean like https://github.com/graphql/dataloader https://github.com/graphql/dataloader ? > in top of non-cacheable POST requests, this argument is lost on them. I think caching/serving HTTP results is a bad paradigm. It makes sense if you're serving HTML for a content site or something like that, but doesn't make sense when you're serving an API.
adamscybot 7y ago
I've found it reduces complexity in your app code (at least on the front end). You basically have no or extremely minimal data fetching logic where as with REST you often find yourself making more requests in response to other requests. I.e to traverse relations. GQL Gives you that for free. Also the tooling is next level . GraphIql alone is miles ahead of any REST tooling offerings. Also, typescript generation. Truly improved my workflow.
- tepidandroid 7y ago
  I find the lack of tooling the annoying part actually... the necessity for 3rd party frameworks like Apollo, tac-on modules like Dataloader... the lack of up-to-date, feature-parity server implementations besides the canonical Javascript version... etc.
glacials 7y ago
It depends on your backend architecture. We migrated a microservices (Go) architecture to GraphQL and it gets very complex with a lot of boilerplate. Perhaps part of that is GraphQL's and its supporting libraries' infancy, but supporting the ability to ~infinitely nest objects in a microservices architecture at scale makes every field addition feel like building a gigafactory. On the plus side GraphQL is very simple and adaptable for frontends. It just comes at the cost of moving so much complexity to the backend.
- dmitryminkovsky 7y ago
  You can’t infinitely nest objects in GraphQL from the perspective of the query (a query can’t have self referring fragment, for example).
- munk-a 7y ago
  That was our assessment, some gained front-end speed at the cost of a loss of back-end performance and simplicity - we ended up staying with bespoke REST endpoints because they're cheap and do the job.
- fhennig 7y ago
  I think it heavily depends on the server library for you language of choice. I've tried sangria for scala, graphql-java and graphene for python and all of them are quite different, and mostly badly documented, but I found the java implementation to be the easiest one to get started with. Graphene seems like a nightmare but the documentation is improving and once you get used to the design it's actually not so bad and more feature complete than the others. I think moving complexity to the backend is actually not such a bad idea, so the frontend can focus more on actually just displaying the information.
  - git-pull 7y ago
    Using graphene at work. Absolutely love graphql as a technology. The pagination and ability to structure a query to pull a lot of data is nice. As for some of the other comments - it's true you can't just write any query: but you can always add new fields, lists, connections (basically a pagination-friendly list), etc against arbitrary things on the backend. It's your backend, you control what data you serve. The graphql-python stack is layered like an onion (graphene on top, graphql-core inside). You will probably be doing something like flask-graphql or graphene-django on top of that. There is a huge negative for python <-> graphql for us, and it's the error system and promises. Perhaps this is what graphql servers in JS are like, but graphql-core hijacks python's error system by wrapping fields in promises. So graphql-core is acting very very true to graphql's implementation in node: to the point it creating a mountain of breadcrumbs in sentry. It also overrides the "next" built-in and tries to emulate express-style callbacks. Another thing ported from node into python that doesn't translate well imo. Aside from that though: graphene has been really speedy, fast to work with. Documentation is getting nicer. The developers on the issue tracker are very nice. And as a general graphql thing: https://github.com/graphql/graphiql https://github.com/graphql/graphiql is really nice! And one more graphql thing: It's typed. In a big API, being able to lay out stuff like that goes a long way. We're generating typescript types via schema.graphql output, and response types via relay. In a real big frontend project, it pays off a lot. I recommend giving graphql a shot.
mdaniel 7y ago
> It seems these days that the size of the response is not typically a limiting factor in most applications I've interfaced with As a "for your consideration," optimizing for the _client's_ concerns might not the true win, but if the server-side were able to side-step some joins, it could be a win for the whole community since it could -- in theory -- make everyone's experience better. The ability to push conditionals on the server side _could_ side-step multiple round-trips, too: https://graphql.github.io/learn/queries/#directives https://graphql.github.io/learn/queries/#directives Just this morning I tried out GitHub's GraphQL interface, and it for sure requires some thinking to reframe the question in terms of the GraphQL surface-area they expose, but GraphQL also has built-in schema discovery, which is something one would typically have to read the docs to access. It's tremendously annoying that one must package a GraphQL query _inside_ a JSON field named `query` versus the much more sane `curl --data-binary 'query MyQuery { some fields }' https://example.com/graphql` https://example.com/graphql` but it seems that packaging is required for separating variables from the actual query itself: https://graphql.github.io/learn/queries/#variables https://graphql.github.io/learn/queries/#variables (although having two endpoints, `/graphql` and `/graphql.variables`, or switching behavior based on content-type, would be amazing and, at least in theory, very little server-side work) Speaking of switching endpoints, the GraphQL community claims that the api is a lot more versioned, too, getting one out of the business of `/v1/customer` and `/v2/customer` etc but I don't have experience to know how much of that is "in theory."
- pm90 7y ago
  Increasing the endpoints queried from 1 to greater than one would probably be a breaking change which is not allowed in graphql.
lwansbrough 7y ago
We migrated from RESTful HTTP to GraphQL and then back to RESTful HTTP. GraphQL is cool, but actually maintaining it is a nightmare and I think it would be rare for the end product to turn out better. Here's a few of the cons for us: - GraphQL parsing and interpretation is considerably slower than RESTful JSON. I'm talking an order of magnitude difference in .NET Core. - The required POSTs cannot easily be (if at all?) cached by caching services such as Cloudflare - It's more work to have to define what data you want than to just spit out the data that's available. Having to continually update your client side queries in order to fetch all the available data is tedious as hell. The whole over/underfetching argument is not worth the incurred performance hit nor the bandwidth improvements. - GraphQL promotes laziness about documentation because it's "self-documenting" -- turns out most API users still struggle to understand how it works and need better API guides anyway, so the reflection is largely useless (it's about as good as those auto-generated Java docs you find on Oracle's website.) - Users get RESTful. They know it, it's not a toy, and it just works. I'll repeat this again because Silicon Valley doesn't seem to get it: GraphQL is not user friendly.
- atombender 7y ago
  > The required POSTs cannot be easily (if at all?) cached GraphQL allows queries to be performed with GET: http://example.com/graphql?query=query{user{id}} You want to use POST for mutations, but read queries can be run through GET and cached just like REST. There's literally no difference -- it's HTTP, after all.
  - lwansbrough 7y ago
    There is a difference. When "everybody" has a unique query, there's no cache.
    - alexchamberlain 7y ago
      In practice, doesn't everyone run the same query in Production? If variables are being used, they're the same degrees of freedom that rest had anyway, right?
jes5199 7y ago
I was at GitHub during their migration to GraphQL, and it was extremely expensive. But they had some weird ideas - there was a mandate to use GraphQL even to render server-side templates, which meant completely replacing the existing MVC architecture with a sort of fat-model DSL that implemented GraphQL resources. Of course, all of that DSL was developed in-house, so documentation was weak and it was impossible to debug...

by rocmcd 7y ago

dmitryminkovsky 7y ago

What’s the complexity you’re thinking of? In my experience, GraphQL is so much simpler than REST. There’s a whole category of thinking you don’t have to engage in (is this POST? PUT?). And to start I wouldn’t migrate from REST. I’d wrap a REST service with GraphQL and take it from there.

adamscybot 7y ago
That essentially means you are still overfetching underneath the hood but yeh -- for me the benefits are in its ergonomics anyway. The whole under/overfetch thing is overstated.
- dmitryminkovsky 7y ago
  Locally, yes. But that’s not a big deal unless your network is that saturated. Also, with wrapping we’re just talking first steps. Anyway the overfetching thing is less about bandwidth and more about maintaining compatibility with older clients and knowing which clients require which fields. Since each GraphQL client explicitly states the fields it needs, it’s much easier to retire old fields.
dmitriid 7y ago
> There’s a whole category of thinking you don’t have to engage in (is this POST? PUT?) There’s a reason that category of thinking exists. But since GraphQL libs are now busy implementing caching in top of non-cacheable POST requests, this argument is lost on them.
- dmitryminkovsky 7y ago
  > There’s a reason that category of thinking exists. What's the reason? > But since GraphQL libs are now busy implementing caching What are you referring to? You mean like https://github.com/graphql/dataloader https://github.com/graphql/dataloader ? > in top of non-cacheable POST requests, this argument is lost on them. I think caching/serving HTTP results is a bad paradigm. It makes sense if you're serving HTML for a content site or something like that, but doesn't make sense when you're serving an API.

adamscybot 7y ago

I've found it reduces complexity in your app code (at least on the front end). You basically have no or extremely minimal data fetching logic where as with REST you often find yourself making more requests in response to other requests. I.e to traverse relations. GQL Gives you that for free. Also the tooling is next level . GraphIql alone is miles ahead of any REST tooling offerings. Also, typescript generation. Truly improved my workflow.

tepidandroid 7y ago
I find the lack of tooling the annoying part actually... the necessity for 3rd party frameworks like Apollo, tac-on modules like Dataloader... the lack of up-to-date, feature-parity server implementations besides the canonical Javascript version... etc.

glacials 7y ago

It depends on your backend architecture. We migrated a microservices (Go) architecture to GraphQL and it gets very complex with a lot of boilerplate. Perhaps part of that is GraphQL's and its supporting libraries' infancy, but supporting the ability to ~infinitely nest objects in a microservices architecture at scale makes every field addition feel like building a gigafactory. On the plus side GraphQL is very simple and adaptable for frontends. It just comes at the cost of moving so much complexity to the backend.

dmitryminkovsky 7y ago
You can’t infinitely nest objects in GraphQL from the perspective of the query (a query can’t have self referring fragment, for example).
munk-a 7y ago
That was our assessment, some gained front-end speed at the cost of a loss of back-end performance and simplicity - we ended up staying with bespoke REST endpoints because they're cheap and do the job.
fhennig 7y ago
I think it heavily depends on the server library for you language of choice. I've tried sangria for scala, graphql-java and graphene for python and all of them are quite different, and mostly badly documented, but I found the java implementation to be the easiest one to get started with. Graphene seems like a nightmare but the documentation is improving and once you get used to the design it's actually not so bad and more feature complete than the others. I think moving complexity to the backend is actually not such a bad idea, so the frontend can focus more on actually just displaying the information.
- git-pull 7y ago
  Using graphene at work. Absolutely love graphql as a technology. The pagination and ability to structure a query to pull a lot of data is nice. As for some of the other comments - it's true you can't just write any query: but you can always add new fields, lists, connections (basically a pagination-friendly list), etc against arbitrary things on the backend. It's your backend, you control what data you serve. The graphql-python stack is layered like an onion (graphene on top, graphql-core inside). You will probably be doing something like flask-graphql or graphene-django on top of that. There is a huge negative for python <-> graphql for us, and it's the error system and promises. Perhaps this is what graphql servers in JS are like, but graphql-core hijacks python's error system by wrapping fields in promises. So graphql-core is acting very very true to graphql's implementation in node: to the point it creating a mountain of breadcrumbs in sentry. It also overrides the "next" built-in and tries to emulate express-style callbacks. Another thing ported from node into python that doesn't translate well imo. Aside from that though: graphene has been really speedy, fast to work with. Documentation is getting nicer. The developers on the issue tracker are very nice. And as a general graphql thing: https://github.com/graphql/graphiql https://github.com/graphql/graphiql is really nice! And one more graphql thing: It's typed. In a big API, being able to lay out stuff like that goes a long way. We're generating typescript types via schema.graphql output, and response types via relay. In a real big frontend project, it pays off a lot. I recommend giving graphql a shot.

mdaniel 7y ago

> It seems these days that the size of the response is not typically a limiting factor in most applications I've interfaced with As a "for your consideration," optimizing for the _client's_ concerns might not the true win, but if the server-side were able to side-step some joins, it could be a win for the whole community since it could -- in theory -- make everyone's experience better. The ability to push conditionals on the server side _could_ side-step multiple round-trips, too: https://graphql.github.io/learn/queries/#directives https://graphql.github.io/learn/queries/#directives Just this morning I tried out GitHub's GraphQL interface, and it for sure requires some thinking to reframe the question in terms of the GraphQL surface-area they expose, but GraphQL also has built-in schema discovery, which is something one would typically have to read the docs to access. It's tremendously annoying that one must package a GraphQL query _inside_ a JSON field named `query` versus the much more sane `curl --data-binary 'query MyQuery { some fields }' https://example.com/graphql` https://example.com/graphql` but it seems that packaging is required for separating variables from the actual query itself: https://graphql.github.io/learn/queries/#variables https://graphql.github.io/learn/queries/#variables (although having two endpoints, `/graphql` and `/graphql.variables`, or switching behavior based on content-type, would be amazing and, at least in theory, very little server-side work) Speaking of switching endpoints, the GraphQL community claims that the api is a lot more versioned, too, getting one out of the business of `/v1/customer` and `/v2/customer` etc but I don't have experience to know how much of that is "in theory."

pm90 7y ago
Increasing the endpoints queried from 1 to greater than one would probably be a breaking change which is not allowed in graphql.

lwansbrough 7y ago

We migrated from RESTful HTTP to GraphQL and then back to RESTful HTTP. GraphQL is cool, but actually maintaining it is a nightmare and I think it would be rare for the end product to turn out better. Here's a few of the cons for us: - GraphQL parsing and interpretation is considerably slower than RESTful JSON. I'm talking an order of magnitude difference in .NET Core. - The required POSTs cannot easily be (if at all?) cached by caching services such as Cloudflare - It's more work to have to define what data you want than to just spit out the data that's available. Having to continually update your client side queries in order to fetch all the available data is tedious as hell. The whole over/underfetching argument is not worth the incurred performance hit nor the bandwidth improvements. - GraphQL promotes laziness about documentation because it's "self-documenting" -- turns out most API users still struggle to understand how it works and need better API guides anyway, so the reflection is largely useless (it's about as good as those auto-generated Java docs you find on Oracle's website.) - Users get RESTful. They know it, it's not a toy, and it just works. I'll repeat this again because Silicon Valley doesn't seem to get it: GraphQL is not user friendly.

atombender 7y ago
> The required POSTs cannot be easily (if at all?) cached GraphQL allows queries to be performed with GET: http://example.com/graphql?query=query{user{id}} You want to use POST for mutations, but read queries can be run through GET and cached just like REST. There's literally no difference -- it's HTTP, after all.
- lwansbrough 7y ago
  There is a difference. When "everybody" has a unique query, there's no cache.
  - alexchamberlain 7y ago
    In practice, doesn't everyone run the same query in Production? If variables are being used, they're the same degrees of freedom that rest had anyway, right?

jes5199 7y ago

I was at GitHub during their migration to GraphQL, and it was extremely expensive. But they had some weird ideas - there was a mandate to use GraphQL even to render server-side templates, which meant completely replacing the existing MVC architecture with a sort of fat-model DSL that implemented GraphQL resources. Of course, all of that DSL was developed in-house, so documentation was weak and it was impossible to debug...