
GraphQL is the King, R-I-P Rest - gina650
https://medium.com/@scbarrus/graphql-is-the-king-long-live-the-king-r-i-p-rest-cf04ce38f6c#.y977heueu
======
niftich
I wrote about GraphQL on here before [1]. I don't share the author's
enthusiasm that it's "awesome" that "the schema is all backed by arbitrary
code" \-- I think this is a bad trade-off, because you still have to have some
custom data-munging layer between your GraphQL acceptor and your backend
datasources, just like you had to do to, but with different code, to implement
a REST service.

However, once canned ORMs or datastores that natively understand GraphQL (like
dgraph) become available, the ecosystem will definitely enable rapid
integration -- provided we keep in mind the lessons learned about user-
supplied queries from the early SQL-on-the-web days.

[1]
[https://hn.algolia.com/?query=niftich%20graphql&sort=byDate&...](https://hn.algolia.com/?query=niftich%20graphql&sort=byDate&type=comment)

~~~
segphault
>I don't share the author's enthusiasm that it's "awesome" that "the schema is
all backed by arbitrary code" \-- I think this is a bad trade-off

Yup, and it also forces you to sacrifice programming language portability.
Kind of important in a microservice scenario where you might want to have
multiple distinct services written in different languages that support the
same set of GraphQL types.

People don't seem to realize that there is a whole separate dedicated schema
language for GraphQL that will eventually replace the mediocre embedded DSLs.
The only reason the current implementations all use the embedded DSLs is
because implementing a parser for the custom schema language is non-trivial.

There are a lot of things that I really like about GraphQL, but I think it
would have been saner if they had aimed for a way to express the schemas and
queries in something like JSON that everybody already speaks.

------
dzmitry_lahoda
Very similar. Typed. Get only requested properties. Request graph shape you
want.

[https://www.elastic.co/guide/en/elasticsearch/guide/current/...](https://www.elastic.co/guide/en/elasticsearch/guide/current/_buckets_inside_buckets.html)

[https://www.elastic.co/guide/en/elasticsearch/reference/curr...](https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping.html#_example_mapping)

[https://www.elastic.co/guide/en/elasticsearch/reference/curr...](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-
request-source-filtering.html)

And I thought ElasticSearch API is REST. And it is JSON.

------
gina650
As mentioned in the first talk at the GraphQL summit (350+ attendees)

Github dumped REST for GraphQL [http://thenewstack.io/github-dumps-rest-
graphql-api/](http://thenewstack.io/github-dumps-rest-graphql-api/)

Rise of GrapQL
[https://www.youtube.com/watch?v=bPlOGKPLtqM&list=PLpi1lPB6op...](https://www.youtube.com/watch?v=bPlOGKPLtqM&list=PLpi1lPB6opQzSSOQU8JQLExuP1JUXPtmA)

------
atmartins
What about permissions? What if the logged in user is only allowed to see
certain fields? Do I make a table that describes every possible field and
which roles can access it? How do I know what's available to query, without
reading docs? What about hypermedia? Do I have to gain knowledge about a large
system's data structure to query it?

~~~
rkv
>What about permissions? What if the logged in user is only allowed to see
certain fields? Do I make a table that describes every possible field and
which roles can access it?

GraphQL is permission agnostic which allows you to develop your own methods.
But there are a lot of nice implementations floating around [1].

>How do I know what's available to query, without reading docs?

Introspection[2].

1\. [https://github.com/joonhocho/graphql-
rule](https://github.com/joonhocho/graphql-rule)

2\.
[http://graphql.org/learn/introspection](http://graphql.org/learn/introspection)

~~~
atmartins
I appreciate the answer. It looks like I do want to create a rule for each
property. Why? Why not create meaningful objects and not micro-manage
individual properties? In case I want to update my front end query in the
future? Shouldn't I just make my objects more granular, rather than this
extreme of managing individual properties? I'm genuinely interested from an
architectural standpoint what the real gain is here, it really seems like
there are major portions of a useful api that are not discussed when I've
looked in to GraphQL.

