HackerTube

Keynote - JSON Graph: Reactive REST at Netflix

Association for Computing Machinery (ACM)4 HN recommenders · 2015–2023
41K views · talk · dated · Uploaded 2015-04-01

Jafar Husain's ACM keynote presents Netflix's JSON Graph and Falcor, which let web developers treat all cloud data as one virtual JSON model. It combines reactive programming with REST principles.

HN commenters point to it as an alternative take on the data-fetching problem GraphQL addresses, and as a clear argument for when RPC or graph models beat plain REST.

Web developmentSoftware architecture & design

Watch on YouTube

4 comments from Hacker News

@bsimpson2015 · in “GraphQL Introduction”

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

RecommendsView on HN
@ignoramous2016 · in “RestCommander: Fast Parallel Async HTTP Client as a Service”

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]

RecommendsView on HN
@e12e2020 · in “Application Load Balancers enables gRPC workloads with end to end HTTP/2 support”

> 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]

RecommendsView on HN
@yencabulator2023 · in “GraphQL vs. REST APIs: a complete guide”

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]

RecommendsView on HN