9 ms·

You Might Not Need GraphQL

98 points by johns 9y ago

013a 9y ago
You might not need REST either. Or SOAP. Or gRPC. Or a formal API at all. You might not need any of these things. But you do need something. If any of them are as easy as any other to implement, then why not choose the most capable one? GraphQL isn't as easy as the others to implement. But its not that much harder with the help of Apollo or something similar in other languages. And its much more capable. Great article, though.
sorenbs 9y ago
As pointed out in the comments, this section is spot on: "That said, I do of course think having all of these concepts implemented and documented in one single “package” like GraphQL is super handy. GraphQL removes the arguing or confusion about what is “the most RESTful way to do something”, as it has a spec and example implementations." Most reasonably complex rest apis have some version of GraphQL build into them. So in a way GraphQL is just standardising existing practices.
- aryes 9y ago
  No the article is right OData offers most of what graphQL has now since 2012. Honestly aside of the HATEOAS principle (see ion). But the key difference is the community engagement and corporate sponsorship, OData had only a lukewarm support from Microsoft and others like SAP. And aside Apache Olingo there isn't much left in library support. (Trust me I'm sad to have to write this). GraphQL on the other hand is drawing both community and corporate support including full support from FB. Time will tell if this will diminish, but the support seems to mimick the success with golang.
  - int_19h 9y ago
    Microsoft essentially created OData; what do you mean by "lukewarm support"?
    - aryes 9y ago
      Lukewarm relative to the support FB is giving to graphQL. To me opendata felt like a second class project (vs the efforts MS has put around .Net and other code that was open sourced recently). But it may just my perception.
  - int_19h 9y ago
    And speaking of OData, is there any good side by side comparison of OData and GraphQL?
    - aryes 9y ago
      I saw this slide deck https://www.slideshare.net/mobile/SumitSarkar10/rest-api-debate-odata-vs-graphql-vs-ords https://www.slideshare.net/mobile/SumitSarkar10/rest-api-deb...
  - techniq 9y ago
    I've created a lightweight odata query builder based somewhat on MongoDB and js-data's query object syntax you might find helpful: https://github.com/techniq/odata-query https://github.com/techniq/odata-query I also built a React component that builds upon this as well, if you're into that - https://github.com/techniq/react-odata https://github.com/techniq/react-odata
- ewrcoffee 9y ago
  Exactly, that paragraph is a very strong argument in favor of GraphQL.
southpolesteve 9y ago
Reading the article, I come to the opposite conclusion. Of course I need GraphQL! I want these problems solved out of the box. I want to build on the shoulders of smart people who already solved them. APIs are contracts. As a method of expressing those contracts, REST just doesn't have enough vocabulary and it is too simple. You have to make too many decisions on your own. That is where the "ful" comes from in RESTful :) Plenty of effort has been put into fixing this, but those tools never really received enough traction. They also fail to solve all the problems outlined in a single cohesive way. JSON-API is maybe the closest thing that currently exits. Contrast that with GraphQL's explicit typed vocabulary. A more rigid and explicit language for API contracts. It is a godsend for writing complex APIs. Everything works out of the box. The developer friendliness also is fantastic (GraphiQL is the killer app). GraphQL places a high priority on developer and consumer UX which is something that previous iterations like SOAP and WSDL were lacking. TLDR: GraphQL makes building complex JSON APIs easy. Sure you might not need it. But you probably want it.
- drdaeman 9y ago
  Bleeding edge may look really charming, but it's really easy to get a cut. It has a lot of niceties and advantages over traditional REST-like APIs, but... Last time I've looked (just a few months ago), the libraries weren't exactly mature-looking, e.g. prone to n+1 queries issue. Good thing is, there are a lot of people who can experiment and improve things. Sad thing is, if you aren't such lucky, GraphQL may be not exactly something you'd want today.
  - ricardobeat 9y ago
    Your argument is basically fear, uncertainty and doubt. Any concrete points?
    - vertex-four 9y ago
      > Last time I've looked (just a few months ago), the libraries weren't exactly mature-looking, e.g. prone to n+1 queries issue. This point seems perfectly concrete.
MR4D 9y ago
Dumb question, because I haven't spent enough time to figure it out, but how do you do writes in GraphQL ? I know how to do those in REST, but trying to Google it for GraphQL is darn near impossible.
- southpolesteve 9y ago
  In graphQL they are called mutations http://graphql.org/graphql-js/mutations-and-input-types/ http://graphql.org/graphql-js/mutations-and-input-types/
dirkg 9y ago
Issues with GraphQL - - the GQL server in practice is still going to have fixed contracts/endpoints, because arbitrary queries are a risk. This is what FB recommends as well - there is no help in actually implementing the server end to end, since its just really a wrapper over the actual calls that need to be made. Apollo seems to be the new standard way to do this. - Mutations/subscriptions are still a work in progress
- maktouch 9y ago
  I agree that subscriptions are a work in progress, but how is mutations is a work in progress? Pretty sure it's defined and it works pretty well.
- marktani 9y ago
  Even though subscriptions are very much in progress from a specification point of view, the community came up with different approaches that are already employed in practice. Here are some additional resources: - RFC for GraphQL subscriptions: https://github.com/facebook/graphql/pull/267 https://github.com/facebook/graphql/pull/267 - How to use Subscriptions in GraphiQL: https://dev-blog.apollodata.com/how-to-use-subscriptions-in-graphiql-1d6ab8dbd74b https://dev-blog.apollodata.com/how-to-use-subscriptions-in-... - Using GraphQL Subscriptions with Apollo: https://www.youtube.com/watch?v=wo9XFmW0W2c https://www.youtube.com/watch?v=wo9XFmW0W2c If you want to use GraphQL subscriptions right now, I encourage you to try out our demo over at https://demo.graph.cool/worldchat/ https://demo.graph.cool/worldchat/. I work at Graphcool :)
sssilver 9y ago
I still don't understand why protocol buffers never quite "took off".
krystiangw 9y ago
GraphQL might not be the new standard for web, but for sure it has great influence on how we are seeing future of client-server communication.

98 points by johns 9y ago

013a 9y ago

You might not need REST either. Or SOAP. Or gRPC. Or a formal API at all. You might not need any of these things. But you do need something. If any of them are as easy as any other to implement, then why not choose the most capable one? GraphQL isn't as easy as the others to implement. But its not that much harder with the help of Apollo or something similar in other languages. And its much more capable. Great article, though.

sorenbs 9y ago

As pointed out in the comments, this section is spot on: "That said, I do of course think having all of these concepts implemented and documented in one single “package” like GraphQL is super handy. GraphQL removes the arguing or confusion about what is “the most RESTful way to do something”, as it has a spec and example implementations." Most reasonably complex rest apis have some version of GraphQL build into them. So in a way GraphQL is just standardising existing practices.

aryes 9y ago
No the article is right OData offers most of what graphQL has now since 2012. Honestly aside of the HATEOAS principle (see ion). But the key difference is the community engagement and corporate sponsorship, OData had only a lukewarm support from Microsoft and others like SAP. And aside Apache Olingo there isn't much left in library support. (Trust me I'm sad to have to write this). GraphQL on the other hand is drawing both community and corporate support including full support from FB. Time will tell if this will diminish, but the support seems to mimick the success with golang.
- int_19h 9y ago
  Microsoft essentially created OData; what do you mean by "lukewarm support"?
  - aryes 9y ago
    Lukewarm relative to the support FB is giving to graphQL. To me opendata felt like a second class project (vs the efforts MS has put around .Net and other code that was open sourced recently). But it may just my perception.
- int_19h 9y ago
  And speaking of OData, is there any good side by side comparison of OData and GraphQL?
  - aryes 9y ago
    I saw this slide deck https://www.slideshare.net/mobile/SumitSarkar10/rest-api-debate-odata-vs-graphql-vs-ords https://www.slideshare.net/mobile/SumitSarkar10/rest-api-deb...
- techniq 9y ago
  I've created a lightweight odata query builder based somewhat on MongoDB and js-data's query object syntax you might find helpful: https://github.com/techniq/odata-query https://github.com/techniq/odata-query I also built a React component that builds upon this as well, if you're into that - https://github.com/techniq/react-odata https://github.com/techniq/react-odata
ewrcoffee 9y ago
Exactly, that paragraph is a very strong argument in favor of GraphQL.

southpolesteve 9y ago

Reading the article, I come to the opposite conclusion. Of course I need GraphQL! I want these problems solved out of the box. I want to build on the shoulders of smart people who already solved them. APIs are contracts. As a method of expressing those contracts, REST just doesn't have enough vocabulary and it is too simple. You have to make too many decisions on your own. That is where the "ful" comes from in RESTful :) Plenty of effort has been put into fixing this, but those tools never really received enough traction. They also fail to solve all the problems outlined in a single cohesive way. JSON-API is maybe the closest thing that currently exits. Contrast that with GraphQL's explicit typed vocabulary. A more rigid and explicit language for API contracts. It is a godsend for writing complex APIs. Everything works out of the box. The developer friendliness also is fantastic (GraphiQL is the killer app). GraphQL places a high priority on developer and consumer UX which is something that previous iterations like SOAP and WSDL were lacking. TLDR: GraphQL makes building complex JSON APIs easy. Sure you might not need it. But you probably want it.

drdaeman 9y ago
Bleeding edge may look really charming, but it's really easy to get a cut. It has a lot of niceties and advantages over traditional REST-like APIs, but... Last time I've looked (just a few months ago), the libraries weren't exactly mature-looking, e.g. prone to n+1 queries issue. Good thing is, there are a lot of people who can experiment and improve things. Sad thing is, if you aren't such lucky, GraphQL may be not exactly something you'd want today.
- ricardobeat 9y ago
  Your argument is basically fear, uncertainty and doubt. Any concrete points?
  - vertex-four 9y ago
    > Last time I've looked (just a few months ago), the libraries weren't exactly mature-looking, e.g. prone to n+1 queries issue. This point seems perfectly concrete.

MR4D 9y ago

Dumb question, because I haven't spent enough time to figure it out, but how do you do writes in GraphQL ? I know how to do those in REST, but trying to Google it for GraphQL is darn near impossible.

southpolesteve 9y ago
In graphQL they are called mutations http://graphql.org/graphql-js/mutations-and-input-types/ http://graphql.org/graphql-js/mutations-and-input-types/

dirkg 9y ago

Issues with GraphQL - - the GQL server in practice is still going to have fixed contracts/endpoints, because arbitrary queries are a risk. This is what FB recommends as well - there is no help in actually implementing the server end to end, since its just really a wrapper over the actual calls that need to be made. Apollo seems to be the new standard way to do this. - Mutations/subscriptions are still a work in progress

maktouch 9y ago
I agree that subscriptions are a work in progress, but how is mutations is a work in progress? Pretty sure it's defined and it works pretty well.
marktani 9y ago
Even though subscriptions are very much in progress from a specification point of view, the community came up with different approaches that are already employed in practice. Here are some additional resources: - RFC for GraphQL subscriptions: https://github.com/facebook/graphql/pull/267 https://github.com/facebook/graphql/pull/267 - How to use Subscriptions in GraphiQL: https://dev-blog.apollodata.com/how-to-use-subscriptions-in-graphiql-1d6ab8dbd74b https://dev-blog.apollodata.com/how-to-use-subscriptions-in-... - Using GraphQL Subscriptions with Apollo: https://www.youtube.com/watch?v=wo9XFmW0W2c https://www.youtube.com/watch?v=wo9XFmW0W2c If you want to use GraphQL subscriptions right now, I encourage you to try out our demo over at https://demo.graph.cool/worldchat/ https://demo.graph.cool/worldchat/. I work at Graphcool :)

sssilver 9y ago

I still don't understand why protocol buffers never quite "took off".

krystiangw 9y ago

GraphQL might not be the new standard for web, but for sure it has great influence on how we are seeing future of client-server communication.