Keynote - JSON Graph: Reactive REST at Netflix

I'm also excited to see Jafar Husain's Falcor: [VIDEO] It's a different implementation of the same concept.

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] [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: [VIDEO]

It hasn't seen much outside adoption, you might enjoy the ideas behind Netflix's Falcor: [LINK] You can think of it as larger-than-what's-downloaded dynamically-generated JSON object with internal pointers where you can ask to access wanted paths. (Sort of like GraphQL is a larger-than-what's-downloaded dynamically-generated non-JSON object.) One trick they use is that the path segments can also be objects, so ` {from: 100, to: 200}` is a valid path segment, and this is how you build fancier query logic with in. [VIDEO]