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.
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.
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).
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.
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:
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)
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.
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.
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.
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.
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
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.
- 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.
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 :)
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.