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

How Netflix uses Java

infoq.com

Post reply on HN
Print view View original

91–100 of 205 posts

Re: How Netflix uses Java

#91

Post by RamblingCTO »

StevePerkins wrote: post #67
Tainnor wrote: post #62

Earlier quoted context omitted.

I've never used any other webstack (and I've used several, in several languages) where it was so hard to figure out why different tests pollute each other, causing subtle failures depending on the order of test execution. Sure, you could say that it's all a matter of learning the right way, but there are just a terrible amount of footguns. Debugging why something doesn't work in Spring can also be a nightmare. And th…

> "...failures depending on the order of test execution." Every time I've seen issues where the order of test execution matters, it's either been: (1) someone one writing integration tests and calling them unit tests, or (2) transaction management issues with H2 or some other embedded test database. For #1, you're going to have a bad time with any stack. For #2, transaction management with Spring Data JPA is admitted…

> Every time I've seen issues where the order of test execution matters, it's either been: (1) someone one writing integration tests and calling them unit tests, or (2) transaction management issues with H2 or some other embedded test database.

Yeah, h2 is a very very bad idea. Hibernate and jpa are also garbage (proxies, lazy loading and transactions are just a big footgun). Have fun trying to use Sprint security and proxied hibernate objects. Somehow you have no guarantee that the class you receive and are checking and is guaranteed by code is what you expect it to be because of proxies. Absolute nightmare. We're using testcontainers, which has their issues on its own.

> I don't know what could make Spring more challenging to troubleshoot than any other Java framework > "@Profile" or "@ConditionalOnXXX"

We have one configuration with @Profile to prevent it from configuring stuff in tests. Our biggest issue is that code that compiles is not guaranteed to run or even crash when running (@Lazy anyone?). I hate this. It caused us so much pain. A bigger issue really is the automagic I was quoting. They just configure shit together because they think it's nice. Also causes a lot of headache. You have to enable/disable a random bunch of shit until it somehow works. And after they released a version fixing vulns that were open for > 1 year because of old dependencies this vodoo breaks. (Especially the garbage that is spring security. Still no migration guide for ACl in v6 huh?)

Fun fact: not a fan of Rust. It's totally overblown for web backends. I love me some Go, but having the ability to use gradle multi-modules in a ports and adpaters architecture is just plain awesome. Not sure where the journey will take us, but Kotlin (which we use exclusively) is a lot of fun. I'd love to have native Kotlin at one point exclusively. No more failing builds because of a wrong jdk or anything.

Just everything about this ecosystem is fragile af. Not sure how we got to a point where shipping a simple Go bin is easier than shipping java. Don't get me started on the resource usage and performance.

Re: How Netflix uses Java

#92

Post by Capricorn2481 »

oldnet wrote: post #51
0x6c6f6c wrote: post #48

Earlier quoted context omitted.

Java and JavaScript have no relation at all.

How you will send request to FE and back if you have java in BE?

What did you mean when you wrote this? You can send a request to any backend server, regardless of language.

Re: How Netflix uses Java

#93

Post by geodel »

This seems entirely unsurprising/standard Java setup. Perhaps it is proximity to Hollywood that some glamor is rubbed off on bog standard enterprise tech stack of Netflix.

Re: How Netflix uses Java

#95

Post by paulbakker »

jarym wrote: post #3

Interesting the article jumps straight from REST to GraphQL and forgets Falcor[0] - Netflix's alternative vision for federated services. For a while it looked like it might be a contender to GraphQL but it never really seemed to take off despite being simpler to adopt. [0] https://netflix.github.io/falcor/

Falcor is actually part of the "old" architecture described in the talk. Because it's mostly unknown and no longer used I didn't go into the details of it.

Falcor was developed at the time Facebook was developing GraphQL in-house. It has similar concepts, but never took off the way GraphQL did.

Re: How Netflix uses Java

#96

Post by RamblingCTO »

StevePerkins wrote: post #52
RamblingCTO wrote: post #40

Earlier quoted context omitted.

No, just no. Performance and debugging are just plain horrible. The spring team loves to force you into their automagic shit and this bean stuff is so annoying. You almost got no compile time safety in this stack. It's the bane of my existence. I'd like to know that a compiled program will run. That seems virtually impossible with java/spring boot.

I'm not sure what "no compile time safety in this stack" even means in the context of a strongly-typed compiled language. If you are referring to the dependency injection container making use of reflection, then Spring Native graduated from experimental add-on to part of the core framework some years ago. You can now opt for Quarkus/Micronaut-style static build-time dependency injection, and even AOT compilation to G…

> I'm not sure what "no compile time safety in this stack" even means in the context of a strongly-typed compiled language.

Easy: as I said down below, you can actually get wildly different classes because of things like Hibernate proxies. Also, you guessed it, the dependency injection part. I just hate it. Nothing works together. We have so many hacks and weird work-arounds because something doesn't work. (Websockets not working with tomcat for example, or the many funky troubles with using two modes of authentication at once).

> Honestly, I've never run into anyone who considers Spring to be "the bane of their existence", where the real issue wasn't simply that the bulk of their experience was in something else. Where they weren't thrown into someone else's project, and resent working with decisions made by other people, but don't want to either dig in and learn the tech or else search for a new job where they get to make the choices on a greenfield project.

In my previous startup, we used python and flask. Something I don't deem scalable for bigger teams/apps. We love Kotlin and Gradle (especially multi-modules). But there are so many drawbacks that just suck time. I have a bunch of private projects, all in Go. Fast and efficient as heck. Nothing I'd like to scale beyond maybe 5 people or 20k loc tho (no idea if bazel or something could help with that, no experience). You get a lot of good stuff, but you gain in fragility with Java/Kotlin.

Another point that just comes to mind is: how unsecure is this thing even? Dependencies are ages old, requiring you to litter your gradle build files with work arounds and overwrites so you're secure from some (often critica) vulns.

Re: How Netflix uses Java

#97

Post by yafetn »

Netflix’s DGS framework for GraphQL is nice to work with but we’ve been frustrated with some prioritization choices by the team. For instance, if you’re using Kotlin, it’s impossible to define and pass scalars to the latest version of the client. There’s a year-old issue highlighting this problem that’s been ignored it seems.

https://github.com/Netflix/dgs-codegen/issues/455

Re: How Netflix uses Java

#98

Post by ppseafield »

dustingetz wrote: post #33
jarym wrote: post #3

Interesting the article jumps straight from REST to GraphQL and forgets Falcor[0] - Netflix's alternative vision for federated services. For a while it looked like it might be a contender to GraphQL but it never really seemed to take off despite being simpler to adopt. [0] https://netflix.github.io/falcor/

iirc falcor predated graphql

I was at the React Rally conference where Falcon was publcly announced in August of 2015. I recall that Facebook gave a GraphQL presentation right before.

It seems GraphQL was first announced publicly in February 2015.

Re: How Netflix uses Java

#100

Post by wiseowise »

RamblingCTO wrote: post #90
Tainnor wrote: post #62

Earlier quoted context omitted.

I've never used any other webstack (and I've used several, in several languages) where it was so hard to figure out why different tests pollute each other, causing subtle failures depending on the order of test execution. Sure, you could say that it's all a matter of learning the right way, but there are just a terrible amount of footguns. Debugging why something doesn't work in Spring can also be a nightmare. And th…

> I've never used any other webstack (and I've used several, in several languages) where it was so hard to figure out why different tests pollute each other, causing subtle failures depending on the order of test execution. Sure, you could say that it's all a matter of learning the right way, but there are just a terrible amount of footguns. > Debugging why something doesn't work in Spring can also be a nightmare. Ma…

Where are you migrating?
Post reply on HN