Whenever GraphQL uses HTTP, it is just as cache-able as any other bit of data over HTTP. Whether HTTP is the right choice is a decision each developer needs to make, based on the requirements of their project.
> processing GraphQL might take a toll on the server
I can not figure out what you mean. I denormalize my data to MongoDB or Riak or ElasticSearch. Then I send a response for each request, and the response has already been "pre-digested" and tailored to the queries I'm ready to answer. How does it matter whether it is REST or GraphQL? They should have the same performance cost. I'm not allowing anyone to hit my canonical data sources, whether its with REST or GraphQL. Perhaps your question is about real time data and mutations?
> Not sure what you mean by node.js "lacking backpressure"?
You should read "Backpressure and Unbounded Concurrency in Node.js":
http://engineering.voxer.com/2013/09/16/backpressure-in-node...
If the client queries get too complex, processing GraphQL might take a toll on the server [0]. GraphQL completely makes sense for a client with limited processing power and battery life, but doesn't offer a great deal in terms of server-to-server communication. JSON Graph by Netflix [1] is worth a look-in for a different take on the problem.
Not sure what you mean by node.js "lacking backpressure"? Node.js is a very well suited solution to GraphQL, since GraphQL implies that the workload is going to to be IO bound.
[0] https://news.ycombinator.com/item?id=11300656
[0] https://news.ycombinator.com/item?id=10365555
[1] https://www.youtube.com/watch?v=hOE6nVVr14c