10 ms·

The Netflix.com site and webapp runs on Node (and talks to a number of services written in mostly JVM based languages). While we encounter challenges just as we

by tylerlh 10y ago

The Netflix.com site and webapp runs on Node (and talks to a number of services written in mostly JVM based languages). While we encounter challenges just as we would with any other language -- it works for us and I would argue that it's a pretty big application. There's always a multitude of ways to get something done, and it's up to you to decide what tool will do it best. Don't treat any one language as an end-all-be-all and you might find yourself much happier and more productive. Of course, YMMV.

ChrisAntaki 10y ago
> There's always a multitude of ways to get something done, and it's up to you to decide what tool will do it best Well said. By the way, what is Netflix's take on Promises vs RxJS?
- ZoeZoeBee 10y ago
  I'm pretty sure Netflix is in the Observables camp, as Ben Lesh over at Netflix is RxJs
  - Akkuma 10y ago
    I watched one of the recent Netflix engineering videos where they moved to a customized version of React and I could have sworn in that talk they actually moved away from Observables[1]. What was confusing is that the other talked released at the same time they talk about enhancing RxJS. [1]: https://youtu.be/5sETJs2_jwo?t=5m32s https://youtu.be/5sETJs2_jwo?t=5m32s
    - mikeryan 10y ago
      A friend of mine runs some UI engineering at Netflix from talking to him reactive JavaScript is still heavily used.
      - Akkuma 10y ago
        I'm sure it is still heavily used, but it looks like there are two very opposing views with one going so far as completely removing it.
- tylerlh 10y ago
  One of the core tenets of the Netflix culture is "Freedom & Responsibility". In this context it means that each team is free to make calls like that as they see fit. Promises, Observables, Generators, Callbacks -- it's up to your team to determine what makes the most sense. That said, we do make heavy use of Rx on the API layer (RxJava/RxGroovy). My team isn't currently using RxJs, but I expect that to change in the future. There are a lot of Observable fans here :)
- zamalek 10y ago
  > By the way, what is Netflix's take on Promises vs RxJS? We've been doing tons of research into the Netflix methodology and teams are highly compartmentalized (albeit communicate richly). This means that when you ask "What do you do at Netflix?" you should really be asking "What does team X do at Netflix?" or "Does any team at Netflix do X?" For instance, unless things have changed or I have the story wrong, JVM is used for the streaming because that's the tool which that team chose. The other teams merely communicate with it over an API (regardless of client language).
pedalpete 10y ago
I think the 'big application' bit is what challenges many people. From what I understand, Netflix is essential a huge group of micro-services, and I 'think' this is where Node.js shines. What are your thoughts on that? When you're developing a service at Netflix, does it feel like you're building a single large application? Does the mentality of micro-services change how you approach code and therefore the validity of the original posts arguments?
- Scarbutt 10y ago
  He said they write services with the JVM, nodejs just for the frontend, at their scale I doubt they will change from the JVM to nodejs for services.
uptownJimmy 10y ago
Speaking only for myself, a middle-weight .NET dev who was, not too long ago, working desperately to find my footing in all this: 1. I think the learning curve to doing good work with Node is really shallow at first, and then it quickly gets almost vertical. 2. I think that ALL of the other server-side language/framework combos (Ruby/Rails, Python/Django, C#/.NET, PHP/Symfony, etc.) make it significantly easier for a "merely-good" dev to make really good Web applications. 3. I think the kinds of devs that work at, say, Netflix are often the kinds of devs that can do amazing things with almost any dev stack, but that leads directly to my last point: 4. I think that most junior devs are making a tactical mistake with their growth, and with their careers, when they choose Node for their first forays into Web app development. The relative chaos and churn, and questionable suitability of Node for many-maybe-most use cases, make Node more trouble than it is worth for someone still struggling to make sense of the basics.
- kansface 10y ago
  > 2. I think that ALL of the other server-side language/framework combos (Ruby/Rails, Python/Django, C#/.NET, PHP/Symfony, etc.) make it significantly easier for a "merely-good" dev to make really good Web applications. All of those frameworks are threaded/synchronous - they are maybe 10 times easier to use and potentially 100x slower (less concurrent) than Node. The ruby equivalent isn't rails, its eventmachine. Moving from django to twisted is probably just as hard as django to Node. 9/10s of the python ecosystem assume synchronous code so you end up with threads, processes, and callbacks.
  - paulddraper 10y ago
    Yeah, but is that really necessary? GitHub runs Rails and they have load.
    - beders 10y ago
      It's all about cost. If they would switch to more efficient languages, they could probably run on half of their current servers. But there's the huge cost of rewriting something you already have. Will that affect your total cost significantly, if you can run on less servers. I.e. it's too late to switch now. There needs to be a significant business reason to switch. "Stuff-that-kinda-works but needs more hardware thrown at it" is probably not a good reason.
MichaelGG 10y ago
How big is the Netflix webapp, though? There's what, 5 or 6 main content "views", then around 20 user-editable forms? Plus the help site. Am I viewing this incorrectly? It doesn't just doesn't feel like Netflix is a large app from the UI perspective - maybe that's just good design. Hope this doesn't come off as "I could do this in a weekend", just questioning how big the actual webapp is.
- tylerlh 10y ago
  I believe you would be surprised were you to look under the hood. There are a number of different "UI areas" in Netflix.com -- homepage, titles, signup (multiple flavors of this, depending on how you're signing up), onboarding, member browsing/viewing experiences, account management, numerous partner integrations, etc... not to mention all the work that goes into per-user customization, AB testing, and internationalization. No offense taken on the question. IMO, if you look at the site and view it as simple then we've done our job correctly. :)
lenkite 10y ago
If I am not wrong, Netflix folks make heavy use of 'stream based programming' using RxJs. This greatly simplifies a lot of the standard problems faced in JS - like callback hell and error handling, if one adopts it consistently across the stack. Not many folks have discovered this as yet.

by tylerlh 10y ago

ChrisAntaki 10y ago

> There's always a multitude of ways to get something done, and it's up to you to decide what tool will do it best Well said. By the way, what is Netflix's take on Promises vs RxJS?

ZoeZoeBee 10y ago
I'm pretty sure Netflix is in the Observables camp, as Ben Lesh over at Netflix is RxJs
- Akkuma 10y ago
  I watched one of the recent Netflix engineering videos where they moved to a customized version of React and I could have sworn in that talk they actually moved away from Observables[1]. What was confusing is that the other talked released at the same time they talk about enhancing RxJS. [1]: https://youtu.be/5sETJs2_jwo?t=5m32s https://youtu.be/5sETJs2_jwo?t=5m32s
  - mikeryan 10y ago
    A friend of mine runs some UI engineering at Netflix from talking to him reactive JavaScript is still heavily used.
    - Akkuma 10y ago
      I'm sure it is still heavily used, but it looks like there are two very opposing views with one going so far as completely removing it.
tylerlh 10y ago
One of the core tenets of the Netflix culture is "Freedom & Responsibility". In this context it means that each team is free to make calls like that as they see fit. Promises, Observables, Generators, Callbacks -- it's up to your team to determine what makes the most sense. That said, we do make heavy use of Rx on the API layer (RxJava/RxGroovy). My team isn't currently using RxJs, but I expect that to change in the future. There are a lot of Observable fans here :)
zamalek 10y ago
> By the way, what is Netflix's take on Promises vs RxJS? We've been doing tons of research into the Netflix methodology and teams are highly compartmentalized (albeit communicate richly). This means that when you ask "What do you do at Netflix?" you should really be asking "What does team X do at Netflix?" or "Does any team at Netflix do X?" For instance, unless things have changed or I have the story wrong, JVM is used for the streaming because that's the tool which that team chose. The other teams merely communicate with it over an API (regardless of client language).

pedalpete 10y ago

I think the 'big application' bit is what challenges many people. From what I understand, Netflix is essential a huge group of micro-services, and I 'think' this is where Node.js shines. What are your thoughts on that? When you're developing a service at Netflix, does it feel like you're building a single large application? Does the mentality of micro-services change how you approach code and therefore the validity of the original posts arguments?

Scarbutt 10y ago
He said they write services with the JVM, nodejs just for the frontend, at their scale I doubt they will change from the JVM to nodejs for services.

uptownJimmy 10y ago

Speaking only for myself, a middle-weight .NET dev who was, not too long ago, working desperately to find my footing in all this: 1. I think the learning curve to doing good work with Node is really shallow at first, and then it quickly gets almost vertical. 2. I think that ALL of the other server-side language/framework combos (Ruby/Rails, Python/Django, C#/.NET, PHP/Symfony, etc.) make it significantly easier for a "merely-good" dev to make really good Web applications. 3. I think the kinds of devs that work at, say, Netflix are often the kinds of devs that can do amazing things with almost any dev stack, but that leads directly to my last point: 4. I think that most junior devs are making a tactical mistake with their growth, and with their careers, when they choose Node for their first forays into Web app development. The relative chaos and churn, and questionable suitability of Node for many-maybe-most use cases, make Node more trouble than it is worth for someone still struggling to make sense of the basics.

kansface 10y ago
> 2. I think that ALL of the other server-side language/framework combos (Ruby/Rails, Python/Django, C#/.NET, PHP/Symfony, etc.) make it significantly easier for a "merely-good" dev to make really good Web applications. All of those frameworks are threaded/synchronous - they are maybe 10 times easier to use and potentially 100x slower (less concurrent) than Node. The ruby equivalent isn't rails, its eventmachine. Moving from django to twisted is probably just as hard as django to Node. 9/10s of the python ecosystem assume synchronous code so you end up with threads, processes, and callbacks.
- paulddraper 10y ago
  Yeah, but is that really necessary? GitHub runs Rails and they have load.
  - beders 10y ago
    It's all about cost. If they would switch to more efficient languages, they could probably run on half of their current servers. But there's the huge cost of rewriting something you already have. Will that affect your total cost significantly, if you can run on less servers. I.e. it's too late to switch now. There needs to be a significant business reason to switch. "Stuff-that-kinda-works but needs more hardware thrown at it" is probably not a good reason.

MichaelGG 10y ago

How big is the Netflix webapp, though? There's what, 5 or 6 main content "views", then around 20 user-editable forms? Plus the help site. Am I viewing this incorrectly? It doesn't just doesn't feel like Netflix is a large app from the UI perspective - maybe that's just good design. Hope this doesn't come off as "I could do this in a weekend", just questioning how big the actual webapp is.

tylerlh 10y ago
I believe you would be surprised were you to look under the hood. There are a number of different "UI areas" in Netflix.com -- homepage, titles, signup (multiple flavors of this, depending on how you're signing up), onboarding, member browsing/viewing experiences, account management, numerous partner integrations, etc... not to mention all the work that goes into per-user customization, AB testing, and internationalization. No offense taken on the question. IMO, if you look at the site and view it as simple then we've done our job correctly. :)

lenkite 10y ago

If I am not wrong, Netflix folks make heavy use of 'stream based programming' using RxJs. This greatly simplifies a lot of the standard problems faced in JS - like callback hell and error handling, if one adopts it consistently across the stack. Not many folks have discovered this as yet.