HackerTube.dev

Keynote - JSON Graph: Reactive REST at Netflix

Association for Computing Machinery (ACM) · 40.9K views · 2015-04-01 · 54:58

Open on YouTube ↗

If playback is restricted in your region, try opening the original video. Use Mark watched to add it to your marked videos.

Overview

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.

On Hacker News

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.

Recommended by 4 HN people across 4 months · HN mentions 2015–2023

Topics

Web developmentSoftware architecture & design
Search by tags
falcorjson graphnetflixreactive programmingrestgraphql

What people said

yencabulator · 2023-03 · Recommendation

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]

Read the original HN comment ↗
e12e · 2020-10 · Recommendation

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

Read the original HN comment ↗
ignoramous · 2016-04 · Recommendation

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]

Read the original HN comment ↗

Sources

Video by Association for Computing Machinery (ACM), played through YouTube.

Data and selection notes

HN summaries and labels may contain AI errors. HN dates refer to discussions, not video publication.

HN Library: HackerTube export (2026-10-31) and open-index/hacker-news. Upstream summaries and classifications may contain AI errors.

Views, duration and playback status refresh separately from the published catalog. When an update fails, existing data remains visible.

Selection checks
  • SaaS & AI candidates: Topic keywords do not match
  • Editor-approved picks: Editorial review is required

Rule matches identify candidates. They do not guarantee video quality or financial results.

About the library and its sources