Keynote - JSON Graph: Reactive REST at Netflix

REST over HTTP is cache-able using CDNs like CloudFront. GraphQL isn't? 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] [link] [0] [link] [1] [this video]

> I had the impression RPC was seen as a mistake. For hypermedia/hypertext Fielding made a solid argument for preferring REST over RPC (mostly because of caching). I still recommend reading his very approachable thesis - these days not so much for the web/REST architecture, but for the other ones, which include modern SPAs (they're not great as hypermedia apps, but fine as networked applications): [link] Apart from caching (and cache invalidation) it's accepted that making the network invisible is a bad idea - it will lead to issues. So remote procedure calls aren't inherently bad, but blurring the distinction too much between local procedure calls and remote ones aren't a great idea. From hung nfs mounts to unpredictable application performance, it is unpleasant. This Netflix talk on their not-graphql framework gives a very nice summary of when and how you might prefer RPC to REST: [this video]