Building Netflix Playback with Self-Assembling Components (2014) | Hacker News Reader

Building Netflix Playback with Self-Assembling Components (2014)

techblog.netflix.com

38 pointscoffeedan16 comments

So, getters? We need X, so we call getX(). getX needs A and B, so it calls getA() and getB(). And so on, until getSomething() just reads input. Please correct me if I'm reading this wrong.

This is the Inversion of Control pattern, where you inject A and B into X via some external mechanism (such as Dependency Injection). The advantage you gain is that you can swap out A and B for objects with different behavior (such as mocks) without needing to change the implementation of X. This leads to an architecture with a high degree of composability and a low degree of coupling, which is great for large systems.

But getters and setters aren't inherently associated with IoC nor vice versa.

Sure they are. Instead of the hosting object determining which dependency to return, some external mechanism is determining such. IoC doesn't necessarily apply only to initialization.

When besides mocking would you want to swap out a dependency using an overarching dependency provider rather than an intermediary processor/getter with conditional delegation?

Test/dev environments are something else I can think of. For example, you might want a different dependency in a dev environment, but you don't want to write tedious "if (env == dev) return foo else return bar" code in your getter, which also couples the hosting class to the environment in which it's running.

AWS SimpleWorkflow (SWF) replay mechanism seems close to this. http://docs.aws.amazon.com/amazonswf/latest/awsflowguide/aws...

Our whole platform is built from self-assembling components.

But sometimes they have to know about each other :)

I don't understand what problem is being solved here. Is this just an overly convoluted way to describe load balancing?

My understanding from briefly skimming the article was that they have forced a "composition" of service orchestration to get from an input to a particular output. From a product standpoint, a particular "experience" could be broken down into a set orchestration of services (depicted as input/output functions). This lets you "tweak" your experience/product by mixing up the flavor of orchestrations by "stitching" different services (much like assembling lego blocks) via some rule engine. Kinda like "dependency-injection" but from a system architecture point of view as opposed to just an application code architecture.

No. It solves the problem of having to reason about data dependencies between functions at scale, typically in the service of doing the minimum amount of work required to get a certain result. As "Steve Wampler" points out in the comments, it's a bit like Inversion of Control/ Dependency injection, except for transient data between functions as opposed to services, connection pools, etc.

Other systems that solve similar problems, whose explanations might make more sense to you: Prismatic's Graph (http://blog.getprismatic.com/prismatics-graph-at-strange-loo...), Jane Street's Incremental (https://blogs.janestreet.com/introducing-incremental/)—and, though it doesn't nicely cover IO—the general concept of laziness in programming languages (https://www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.p...).

I don't think you can expect to gain that understanding from this piece. It's part of a series, and presumably forthcoming posts will explain how the rules engine drives which components are selected to process specific content requests.

Can someone recommend a resource for researching scalability solutions like these? Book(s), or video series?

So... Netflix solved SAT?

This is a far simpler problem than SAT. There aren't enough details in this post, but one would expect that 'processors' would not impede one another. Then it's dependency resolution, of the sort that package managers do every day.

I'm too old for this.

Reply on news.ycombinator.com