Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Netflix really uses Java

infoq.com

Post reply on HN
Print view View original

31–40 of 100 posts

Re: How Netflix really uses Java

#31

Post by rco8786 »

kagakuninja wrote: post #12
iammiles wrote: post #4

…let's say, your TV, or your iOS device will just do 10 network calls to these different microservices. It will just not scale at all. You would have a very bad customer experience. It would feel like using the Disney app. It's just not ideal. That’s some shade.

I'm interviewing at Disney Streaming, lol

There is a bug in the Roku app where if you close it and then re-open quickly it will hang on the profile login screen every, single time. Have to go back to Home again and re-open the app.

Seems dumb, but I have 2 little kids and they both like to "pause" whatever show when it's time to turn the tv off. So after the first one does it, I have to do this dumb little dance to get the app to load again so the second one can do it.

Re: How Netflix really uses Java

#32

Post by paulddraper »

iammiles wrote: post #4

…let's say, your TV, or your iOS device will just do 10 network calls to these different microservices. It will just not scale at all. You would have a very bad customer experience. It would feel like using the Disney app. It's just not ideal. That’s some shade.

Disney app works really well for me (Android).

But now I'm gonna hear the comment every time I wait for it to load :P

Re: How Netflix really uses Java

#33

Post by CharlieDigital »

Nican wrote: post #27

I have been out of the loop with Java. Is Virtual Threads the answer to asynchronous I/O? (Much like Go/C# async/node.js?) That looks like an interesting solution to support asynchronous I/O without breaking all the APIs, and having the async/await mess that C# created.

    > ...the async/await mess that C# created
What do you find messy about it? Seems fairly straight forward, IME.

Re: How Netflix really uses Java

#34

Post by brabel »

doctorpangloss wrote: post #26
John23832 wrote: post #20

Earlier quoted context omitted.

Even at Netflix RxJava is not fully accepted. When I was there I wrote a service which called many downstreams. It orchestrated test user creation. I used RxJava because it was being pushed by the platform team, and coupled well with our internal GRPC api handlers. I shared with the team and people complained about the complexity… so I ended up ripping it out. What people wanted was a test user creation service that…

Adopting RxJava means fixing all the bugs in everything up front. That is why it feels complex. In my opinion and in the opinion of other adopters, it is a more expressive way to define correct behavior. This is essentially the same tension between static and dynamic typing. No matter what, all bug free code is complex. Correct code can be written in any paradigm. But productful code ships with bugs. Does test user c…

I tried using an API based on RxJava to implement some async code... It was buggy as hell, as using the API correctly was nearly impossible for me - that's the opposite of a good API which makes it very hard to use wrong. I am in the process of replacing all that shitty code with Virtual Threads, and all bugs just immediately disappear as the code is so much more straightforward to analyse.

Re: How Netflix really uses Java

#35

Post by John23832 »

doctorpangloss wrote: post #26
John23832 wrote: post #20

Earlier quoted context omitted.

Even at Netflix RxJava is not fully accepted. When I was there I wrote a service which called many downstreams. It orchestrated test user creation. I used RxJava because it was being pushed by the platform team, and coupled well with our internal GRPC api handlers. I shared with the team and people complained about the complexity… so I ended up ripping it out. What people wanted was a test user creation service that…

Adopting RxJava means fixing all the bugs in everything up front. That is why it feels complex. In my opinion and in the opinion of other adopters, it is a more expressive way to define correct behavior. This is essentially the same tension between static and dynamic typing. No matter what, all bug free code is complex. Correct code can be written in any paradigm. But productful code ships with bugs. Does test user c…

> Adopting RxJava means fixing all the bugs in everything up front. That is why it feels complex.

I disagree with this. It mentally changes the thought processes when debugging, which was the biggest issue that was brought up.

> Does test user creation need to be bug free? I don’t know. It feels like something where productful test user creation can ship with bugs, even if in reality your test code harnesses should not be buggy.

It should be bug free at Netflix scale. My service created more customers daily than Netflix signed up monthly. It also sat in the middle of Growth. People use it to gate deployments. It needs to work flawlessly (or at least consistently).

Re: How Netflix really uses Java

#36

Post by shp0ngle »

iammiles wrote: post #4

…let's say, your TV, or your iOS device will just do 10 network calls to these different microservices. It will just not scale at all. You would have a very bad customer experience. It would feel like using the Disney app. It's just not ideal. That’s some shade.

I don't think the experience is that much different between the different services, honestly. I vaguely have some recollection of Max being a bit bad, but don't remember the details. They are all fine.

Except for YouTube, that's just leagues ahead of everything else.

Re: How Netflix really uses Java

#37

Post by John23832 »

criddell wrote: post #23
John23832 wrote: post #20

Earlier quoted context omitted.

Even at Netflix RxJava is not fully accepted. When I was there I wrote a service which called many downstreams. It orchestrated test user creation. I used RxJava because it was being pushed by the platform team, and coupled well with our internal GRPC api handlers. I shared with the team and people complained about the complexity… so I ended up ripping it out. What people wanted was a test user creation service that…

Looking back, do you think choosing practical reasons over efficiency was the right call?

Yes. Code is read (and debugged) way more than it is written.

I was using RxJava initially because it was being pushed by the platform team and coupled pretty well with the GRPC interfaces we used internally. However, the rest of my team couldn't/didn't want to wrap their minds around the concurrently functional tasking that it brought (which was understandable).

I didn't want the code to have a bus factor of 1 (me).

Re: How Netflix really uses Java

#38

Post by the_other »

throwitaway222 wrote: post #9

I bought into the "RX Java/JS/etc.." years back. Everyone I showed the code couldn't handle it, and we just backed off to other methods, and things worked just fine. RX has some interesting ideas, but from a practical standpoint, at companies not netflix, it just doesn't work

We use RxJS in two of our video streaming products. In one of them we have a spaghetti bowl of streams. You can follow most of what’s going on, but not 100%. And it hurts. Architecture, patterns and naming conventions hamper readability and understanding a lot.

In the second codebase, things are a bit simpler. The architecture allows for more readable code and far fewer cases where multiple streams might introduce loops or race conditions due to being in separate files and initialised at different times. We felt the benefits of a v2 build ;-)

I’d say RxJS is a great tool to help respond to multiple concurrent data streams (e.g. user interactions happening at the same time as video playback). If you’re not dealing with a lot of realtime behaviour, you probably don’t need it.

In my opinion the complexity ramps up massively if some consumers want a reactive streams pushing data to them and other consumers prefer to request a current static value of the same data. Watch for this and experiment to find comfortable solutions or acceptable compromises.

If you think you need RxJS, take a look at Redux + Sagas and consider a choice between the two. I prefer the rigour and dev tools for Redux + Sagas over the freedom to be hairy with Rx. But observable streams are a lovely abstraction.

Re: How Netflix really uses Java

#39

Post by jshen »

shp0ngle wrote: post #36
iammiles wrote: post #4

…let's say, your TV, or your iOS device will just do 10 network calls to these different microservices. It will just not scale at all. You would have a very bad customer experience. It would feel like using the Disney app. It's just not ideal. That’s some shade.

I don't think the experience is that much different between the different services, honestly. I vaguely have some recollection of Max being a bit bad, but don't remember the details. They are all fine. Except for YouTube, that's just leagues ahead of everything else.

the tvos app for youtube is pretty bad

Re: How Netflix really uses Java

#40

Post by breakfastduck »

shp0ngle wrote: post #36
iammiles wrote: post #4

…let's say, your TV, or your iOS device will just do 10 network calls to these different microservices. It will just not scale at all. You would have a very bad customer experience. It would feel like using the Disney app. It's just not ideal. That’s some shade.

I don't think the experience is that much different between the different services, honestly. I vaguely have some recollection of Max being a bit bad, but don't remember the details. They are all fine. Except for YouTube, that's just leagues ahead of everything else.

Nah the Disney app is really poor, it crashes / refuses to load way more than the other ones in my experience. On multiple different devices / networks.
Post reply on HN