You Might Not Need GraphQL(blog.runscope.com)
blog.runscope.com
You Might Not Need GraphQL
https://blog.runscope.com/posts/you-might-not-need-graphql#hn
27 comments
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.
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.
In a typical client-server application, regular ol' REST is also vulnerable to the N+1 problem. Only difference: it's N+1 network requests, which introduces a worse user experience than N+1 database queries (or whatever you use to define your GraphQL resolvers).
Your argument is basically fear, uncertainty and doubt. Any concrete points?
> 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.
This point seems perfectly concrete.
the n+1 comes from the execution module of the reference implementation if you use the "default/simple" logic.
But this is just a reference/general purpose implementation.
No one said you can not create smarter resolvers that inspect the AST or even create your own execution module. It's possible :) and it works.
Indeed - but there's very little in the way of good examples on how to do that effectively and in a resilient manner, last time I checked.
I find this strange, because this has been a solved problem with graphql-js for about 18 months now, and provided as a core feature in other implementations such as Sangria in Scala. I've written about this particular problem, calling out solutions that exist in different languages:
https://dev-blog.apollodata.com/optimizing-your-graphql-requ...
https://dev-blog.apollodata.com/optimizing-your-graphql-requ...
The ecosystem is rather new, but the folks from Apollo have been doing amazing work. Between graphql-tools, graphql-server and Apollo Client most of the big chunks are done for you. (including very bleeding edge stuff like subscriptions)
The one big unsolved issue right now is Authorization, i.e. how do you handle permissions? (everything else, like authentication, you can handle with the server itself or there's tooling for it)
I'm collaborating with the Apollo folks on some possible solutions, if you're interested read this issue and chime in: https://github.com/apollographql/graphql-tools/issues/313
The one big unsolved issue right now is Authorization, i.e. how do you handle permissions? (everything else, like authentication, you can handle with the server itself or there's tooling for it)
I'm collaborating with the Apollo folks on some possible solutions, if you're interested read this issue and chime in: https://github.com/apollographql/graphql-tools/issues/313
So, been thinking about this one for a couple of years and think it's probably a mistake to make GraphQL responsible for permissioning for anything other than a quick MVP. It's a concern that should pervade your stack rather than being "decloaked" at the outer edges. It's the responsible for your underlying data layer to determine what a user permitting user is allowed to do. Additionally, there are many approaches to permissioning that exist for good reasons, and appearing to bless one approach would feel short-sighted.
I agree that there are reasons you may want GraphQL to handle permissions initially, but much like libraries that map your types to database table, it'll be a solution you walk away from quite early on. It'd feel strange for it to be built into graphql-tools itself, which is concerned with building an executable schema, but I could see it being a relatively useful library that's essentially just a bunch of resolver decorators.
I agree that there are reasons you may want GraphQL to handle permissions initially, but much like libraries that map your types to database table, it'll be a solution you walk away from quite early on. It'd feel strange for it to be built into graphql-tools itself, which is concerned with building an executable schema, but I could see it being a relatively useful library that's essentially just a bunch of resolver decorators.
You are definitely not wrong. In our case the benefits have far outweighed the harshness from the bleeding edge. But for sure we have had to do a thing or two that I would rather not. Adding auth into graphQL, extending built in type classes are examples.
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.
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.
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.
"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.
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.
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.
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
I also built a React component that builds upon this as well, if you're into that - https://github.com/techniq/react-odata
I also built a React component that builds upon this as well, if you're into that - https://github.com/techniq/react-odata
And speaking of OData, is there any good side by side comparison of OData and GraphQL?
I saw this slide deck https://www.slideshare.net/mobile/SumitSarkar10/rest-api-deb...
Microsoft essentially created OData; what do you mean by "lukewarm support"?
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.
Exactly, that paragraph is a very strong argument in favor of GraphQL.
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.
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
- 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
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
- How to use Subscriptions in GraphiQL: https://dev-blog.apollodata.com/how-to-use-subscriptions-in-...
- Using GraphQL Subscriptions with Apollo: 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/. I work at Graphcool :)
Here are some additional resources:
- RFC for GraphQL subscriptions: https://github.com/facebook/graphql/pull/267
- How to use Subscriptions in GraphiQL: https://dev-blog.apollodata.com/how-to-use-subscriptions-in-...
- Using GraphQL Subscriptions with Apollo: 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/. I work at Graphcool :)
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.
I still don't understand why protocol buffers never quite "took off".
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.
I know how to do those in REST, but trying to Google it for GraphQL is darn near impossible.
In graphQL they are called mutations http://graphql.org/graphql-js/mutations-and-input-types/
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.