
Do We Need GraphQL? - brakmic
http://kellysutton.com/2017/01/02/do-we-need-graphql.html
======
moxious
> In the world of GraphQL, HTTP is an unfortunate transport mechanism rather
> than something to be embraced. Rather than using the standard semantics, we
> ignore them completely by treating HTTP like a dumb pipe.

Yep, this seems to be the nub of it. Whether this is good or bad depends on
your perspective. On one side, REST is about transferring representations of
particular objects. If you're in the graph query world, you're not looking at
things an object at a time. So maybe side-stepping what HTTP provides in order
to build a higher-level abstraction is good, and HTTP should just be a dumb
pipe.

On the other hand, HTTP has this entire world of primitives you can use, and
treating it like a dumb pipe throws away many years of software and
architecture advances, in order for HTTP to provide something that really any
transport could probably just as easily.

If graph query really catches on, we'll have to deal with the mismatch between
__what graph query is trying to do, and what HTTP was built to do __.

Personally as far as graph query goes, I'm partial to the Cypher query
language ([https://neo4j.com/developer/cypher-query-
language/);](https://neo4j.com/developer/cypher-query-language/\);) I'd like a
true declarative query language rather than a way of shoe-horning similar
ideas into a JSON format. But if the web goes in a direction of making any
kind of graph query more easy and available, that's not going to be a loss as
far as I'm concerned.

