undefined | Better HN

0 pointsdelluminatus10y ago0 comments

GraphQL is a query language. It's protocol-independent. It just so happens that HTTP POST is a convenient way to deliver queries. Instead of using an HTTP endpoint, you could just as correctly implement GraphQL directly over TCP, or messaging queues, or whatever you want.

0 comments

srigi10y ago

True, but when implementing GraphQL on top of webserver (like Express.js in article), correct HTTP methods should be adopted - GET for querying, POST for mutations. I don't see any harm in doing that.

Touche10y ago

Sure, but the manor it is going to be used in real life is HTTP POST, 99% of the time. This is the use-case it is trying to solve, after all.

schrockn10y ago

I think given the current state of the spec that's pretty accurate. However we really view GraphQL as the way that front-ends/client specify their data requirements. One way of fulfilling that is to dispatch the queries to the server as is. However if you view this as an API to data, which can include client software, this can get a lot more interesting, and allows you to use different transports, messaging protocols, etc

For example on iOS we used GraphQL to transition our persistence from Core Data to a propriety (client) storage engine.

j / k navigate · click thread line to collapse