You Might Not Need GraphQL

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.<p>APIs are contracts. As a method of expressing those contracts, REST just doesn&#x27;t have enough vocabulary and it is too simple. You have to make too many decisions on your own. That is where the &quot;ful&quot; 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.<p>Contrast that with GraphQL&#x27;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.<p>TLDR: GraphQL makes building complex JSON APIs easy. Sure you might not need it. But you probably want it.

You might not need REST either. Or SOAP. Or gRPC. Or a formal API at all.<p>You might not need any of these things. But you do need <i>something</i>. If any of them are as easy as any other to implement, then why not choose the most capable one?<p>GraphQL isn&#x27;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.<p>Great article, though.

As pointed out in the comments, this section is spot on:<p>&quot;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.&quot;<p>Most reasonably complex rest apis have some version of GraphQL build into them. So in a way GraphQL is just standardising existing practices.

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 -<p>- the GQL server in practice is still going to have fixed contracts&#x2F;endpoints, because arbitrary queries are a risk. This is what FB recommends as well<p>- 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.<p>- Mutations&#x2F;subscriptions are still a work in progress

I still don&#x27;t understand why protocol buffers never quite &quot;took off&quot;.

Dumb question, because I haven&#x27;t spent enough time to figure it out, but how do you do <i>writes</i> in GraphQL ?<p>I know how to do those in REST, but trying to Google it for GraphQL is darn near impossible.