
You Might Not Need GraphQL - johns
https://blog.runscope.com/posts/you-might-not-need-graphql#hn
======
southpolesteve
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
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
Your argument is basically fear, uncertainty and doubt. Any concrete points?

~~~
vertex-four
> 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.

~~~
ruslan_talpa
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.

~~~
vertex-four
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.

~~~
andrewingram
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-request-
waterfalls-7c3f3360b051?source=linkShare-913ef66da585-1492188730)

------
013a
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
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
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
And speaking of OData, is there any good side by side comparison of OData and
GraphQL?

~~~
aryes
I saw this slide deck [https://www.slideshare.net/mobile/SumitSarkar10/rest-
api-deb...](https://www.slideshare.net/mobile/SumitSarkar10/rest-api-debate-
odata-vs-graphql-vs-ords)

------
krystiangw
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.

------
dirkg
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

~~~
marktani
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-...](https://dev-blog.apollodata.com/how-to-use-
subscriptions-in-graphiql-1d6ab8dbd74b)

\- 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
I still don't understand why protocol buffers never quite "took off".

------
MR4D
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
In graphQL they are called mutations [http://graphql.org/graphql-js/mutations-
and-input-types/](http://graphql.org/graphql-js/mutations-and-input-types/)

