Skip to content
HomeVideos
AllLongsCategoriesPlaylists
BooksBlogsPodcasts
HistoryListsWatch laterLiked videosFollowing

The videos, books, blogs and podcasts Hacker News keeps recommending, all in one place.

VideosBooksBlogsPodcastsAboutPrivacySettings

Data from Hacker News, HackerTube, HackerBooks, HackerBlogs and Open Library. Credits · Not affiliated with Y Combinator.

HomeVideosBooksBlogsPodcasts
Ctrl K

    Keynote - JSON Graph: Reactive REST at Netflix

    Association for Computing Machinery (ACM)

    4 HN recommenders · recommended in 4 months, 2015–2023

    YouTube

    54:58 · 41K views · Apr 1, 2015

    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.

    Software Engineering & LanguagesWeb developmentSoftware architecture & design
    1. 36:31
      Hey Underscore, You're Doing It Wrong!InfoQ141K views • 13 years ago
    2. 40:58
      Pete Hunt: React - Rethinking Best Practices (updated) - JSConf.Asia 2013JSConf58K views • 12 years ago
    3. 28:39
      Netflix JavaScript Talks - Async JavaScript with Reactive ExtensionsMatt Marenghi70K views • 12 years ago
    4. 44:36
      Hacker Way: Rethinking Web App Development at FacebookMeta Developers900K views • 12 years ago
    5. 39:15
      The Maximal Graph - Wilker SilvaClojureTV7.5K views • 6 years ago
    6. 46:18
      Om Next - David NolenClojureTV44K views • 11 years ago
    7. 35:32
      Cheng Lou - On the Spectrum of Abstraction at react-europe 2016ReactEurope63K views • 10 years ago
    8. 31:11
      React.js Conf 2015 - Immutable Data and ReactMeta Developers159K views • 11 years ago
    9. 36:18
      "Data Driven UIs, Incrementally" by Yaron MinskyStrange Loop Conference20K views • 8 years ago
    10. 36:45
      Rich Harris - Rethinking reactivityYou Gotta Love Frontend334K views • 7 years ago
    11. 33:25
      Dan Abramov: Beyond React 16 | JSConf IcelandJSConf139K views • 8 years ago
    12. 31:48
      Lin Clark - A Cartoon Intro to Fiber - React Conf 2017Meta Developers216K views • 9 years ago
    13. 40:55
      "Controlling Time and Space: understanding the many formulations of FRP" by Evan CzaplickiStrange Loop Conference69K views • 12 years ago
    14. 1:16:14
      Spec-ulation Keynote - Rich HickeyClojureTV136K views • 9 years ago
    15. 36:45
      Jordan Walke - React to the FutureReasonConf48K views • 6 years ago
    16. 18:55
      [JSConfUS 2013] Tom Occhino and Jordan Walke: JS Apps at FacebookJSConf45K views • 13 years ago
    17. 59:31
      ClojureScript in the Age of TypeScript — David NolenChariotSolutions29K views • 5 years ago
    18. 33:23
      ReactiveConf 2017 - Tom Dale: Secrets of the Glimmer VMReactiveConf2.9K views • 8 years ago
    19. 1:16:07
      React Helsinki February 2020Fraktio42K views • 6 years ago
    20. 4:57
      Rich Hickey rants about HttpServletRequest in 1080p: Death By Specificity from Clojure Made SimpleFred Overflow43K views • 6 years ago

    4 comments from Hacker News

    1. @e12eOct 2020· 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: this video

      RecommendsView on HN
    2. @ignoramousApr 2016· 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] this video

      RecommendsView on HN
    3. @yencabulatorMar 2023· 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. this video

      RecommendsView on HN
    4. @bsimpsonMay 2015· in “GraphQL Introduction”

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

      RecommendsView on HN