GraphQL is the King, R-I-P Rest | Hacker News Reader

GraphQL is the King, R-I-P Rest

medium.com

16 pointsgina6507 comments

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

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

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/reference/curr...

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

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/

Rise of GrapQL https://www.youtube.com/watch?v=bPlOGKPLtqM&list=PLpi1lPB6op...

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?

>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

2. http://graphql.org/learn/introspection

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.

Reply on news.ycombinator.com