4 ms·

I've been building GraphQL APIs @ Shopify for almost 2 years now so I'm a little biased but I mostly agree with this post. Here's a few random thoughts from my

I've been building GraphQL APIs @ Shopify for almost 2 years now so I'm a little biased but I mostly agree with this post. Here's a few random thoughts from my experience with GraphQL: * GraphQL definitely seems to be more popular in the context of the client. A lot of the conversation is around client-side libraries like Apollo and Relay and how to consume APIs. * Because of this, the actual GraphQL servers get less attention and there's less resources on building them. * GraphQL on the client is a huge win in my opinion and I've never really heard anyone who's used it disagree with that. * BUT, GraphQL on the server is absolutely much harder to write than a REST API. I've found two main reasons for this though: 1. GraphQL is more powerful and you don't get all that for free. 2. You end up paying more attention to designing a good GraphQL schema/API because of the type system. Yes you can absolutely design great RESTful APIs with many of the same features as GraphQL. Even at Shopify we offer a `fields` query param in REST to only select a subset of fields. Guess what? Barely anyone uses this which shouldn't be surprising. JSON API and companies like Stripe with their `expand` feature offer equivalents to GraphQL but it's non-standard and way harder to do since you're inventing it each time. There's also no standard universal clients for these. Greenspun's rule applies here in my opinion (slightly exaggerated): > Any sufficiently complicated RESTful API contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of GraphQL. I don't know where this will all end up. I do know that GraphQL isn't perfect and it's still early. Public APIs are tough right now because developers are so used to RESTful APIs, but at least at Shopify, we believe that will shift over time.

adamkl 8y ago
1. GraphQL is more powerful and you don't get all that for free. Personally, one of the things I think is most powerful, and missed in every discussion about GraphQL, is that it’s more than just an alternative to a REST API (understandably so, given that is it’s primary use case). At its heart, it’s a query language specification with no mention of transport protocols. I can’t speak to other implementations, but graphql-js gives you the tools to parse queries and schemes into abstract syntax trees, and once you have that, there’s a lot you can do. Take a look at Apollo’s work on merging schemas together for a good example.[1] Personally, I’m working on a proxy layer that will sit in front of a GraphQL API and act as a sort of business rule engine. It analyses the incoming queries to figure out which sets of rules need to be run, and then actually alters the incoming query to add in any additional data points required before forwarding the request to the backend API. Once the combined result comes back, it executes the appropriate rules and filters the output before sending back to the client. These sorts of solutions don’t have anything to do with APIs. Heck, you could create a GraphQL schema to act as a classic data access layer, and call it internally from your own code. 2. You end up paying more attention to designing a good GraphQL schema/API because of the type system. Yes indeed. We have been working hand-in-hand with our business SMEs to build out a schema that is essentially our business object model. It has made communication between technology and business much smoother when we can point to a visualization of our API [2] and have our business partners understand exactly what they are seeing. I’m not sure where GraphQL will end up either, but I can see a place for it just about anywhere. (I suppose I’m a bit of a kool-aid drinker.. I wasn’t when I first started using GraphQL, but it has grown on me) [1] https://www.apollographql.com/docs/graphql-tools/schema-stitching.html https://www.apollographql.com/docs/graphql-tools/schema-stit... [2] https://apis.guru/graphql-voyager/ https://apis.guru/graphql-voyager/
ako 8y ago
Seems that oData offers all the benefits of graphql in a standardized way, for restful APIs. With the added benefit that it's supported in many tools like ms-excel, tableau, etc.
ljm 8y ago
I've felt similar from working with GraphQL in Rails, but it's not entirely fair to blame the graphql gem for this because Rails has been an MVC-style RESTful web framework for as long as it's lived. Naturally there'll be a lot more exposed wires as you're building up a server that has different requirements for an application architecture. It's easier said than done but I just think that there needs to be something for GraphQL that Rails was to REST, and for those options to exist outside of Node-land. I don't know what's out there for that, but I have heard a bit about absinthe: https://hexdocs.pm/absinthe/overview.html https://hexdocs.pm/absinthe/overview.html. Having gone back to a project using REST and Redux, I miss working with graphql.
masklinn 8y ago
> * Because of this, the actual GraphQL servers get less attention and there's less resources on building them. By graphql servers do you mean graphql clients on the server? I'd think there's not much resources on building them because the basics are so trivial, the composition features are rarely necessary so all you need is the ability to POST a query, and parse the resulting JSON document. My experience of interacting with the Github v4 API was understanding how to make queries: requests.post('https://api.github.com/graphql', json={ 'query': query_string, 'variables': my_vars, }) and then spending some time with the graphql explorer to know what "query_string" should actually be. And then some code afterwards to check for errors and pull out the bits into "native" objects, but that would be no different in an other API style.

adamkl 8y ago

1. GraphQL is more powerful and you don't get all that for free. Personally, one of the things I think is most powerful, and missed in every discussion about GraphQL, is that it’s more than just an alternative to a REST API (understandably so, given that is it’s primary use case). At its heart, it’s a query language specification with no mention of transport protocols. I can’t speak to other implementations, but graphql-js gives you the tools to parse queries and schemes into abstract syntax trees, and once you have that, there’s a lot you can do. Take a look at Apollo’s work on merging schemas together for a good example.[1] Personally, I’m working on a proxy layer that will sit in front of a GraphQL API and act as a sort of business rule engine. It analyses the incoming queries to figure out which sets of rules need to be run, and then actually alters the incoming query to add in any additional data points required before forwarding the request to the backend API. Once the combined result comes back, it executes the appropriate rules and filters the output before sending back to the client. These sorts of solutions don’t have anything to do with APIs. Heck, you could create a GraphQL schema to act as a classic data access layer, and call it internally from your own code. 2. You end up paying more attention to designing a good GraphQL schema/API because of the type system. Yes indeed. We have been working hand-in-hand with our business SMEs to build out a schema that is essentially our business object model. It has made communication between technology and business much smoother when we can point to a visualization of our API [2] and have our business partners understand exactly what they are seeing. I’m not sure where GraphQL will end up either, but I can see a place for it just about anywhere. (I suppose I’m a bit of a kool-aid drinker.. I wasn’t when I first started using GraphQL, but it has grown on me) [1] https://www.apollographql.com/docs/graphql-tools/schema-stitching.html https://www.apollographql.com/docs/graphql-tools/schema-stit... [2] https://apis.guru/graphql-voyager/ https://apis.guru/graphql-voyager/

ako 8y ago

Seems that oData offers all the benefits of graphql in a standardized way, for restful APIs. With the added benefit that it's supported in many tools like ms-excel, tableau, etc.

ljm 8y ago

I've felt similar from working with GraphQL in Rails, but it's not entirely fair to blame the graphql gem for this because Rails has been an MVC-style RESTful web framework for as long as it's lived. Naturally there'll be a lot more exposed wires as you're building up a server that has different requirements for an application architecture. It's easier said than done but I just think that there needs to be something for GraphQL that Rails was to REST, and for those options to exist outside of Node-land. I don't know what's out there for that, but I have heard a bit about absinthe: https://hexdocs.pm/absinthe/overview.html https://hexdocs.pm/absinthe/overview.html. Having gone back to a project using REST and Redux, I miss working with graphql.

masklinn 8y ago

> * Because of this, the actual GraphQL servers get less attention and there's less resources on building them. By graphql servers do you mean graphql clients on the server? I'd think there's not much resources on building them because the basics are so trivial, the composition features are rarely necessary so all you need is the ability to POST a query, and parse the resulting JSON document. My experience of interacting with the Github v4 API was understanding how to make queries: requests.post('https://api.github.com/graphql', json={ 'query': query_string, 'variables': my_vars, }) and then spending some time with the graphql explorer to know what "query_string" should actually be. And then some code afterwards to check for errors and pull out the bits into "native" objects, but that would be no different in an other API style.