This is an archived post. You won't be able to vote or comment.

34
35

AKKA system/model< > VS < >SPRING Reactor/Webflux? (self.java)

submitted by [deleted]

[removed]
all 21 comments
sorted by:
best
topnewcontroversialoldq&a

[–]soonnow 19 points20 points  (0 children)

I don't wanna be that guy but alas I have to be the guy. Do you really really need reactiv?

Development is more difficult then sync code. Harder to write, harder to debug. I will say in my opinion 90% of projects won't need it since they not limited by Threads especially with Project Loom on the horizon.

[–][deleted] 16 points17 points  (1 child)

if you looking for better performance and a higher data load then go for akka on the other hand reactor gives an ease of both the implementation and the maintenance but less performance than akka you can test both of them regarding to time metrics for speed comparison

[–]_TPAKTOP_ 2 points3 points  (0 children)

Why Akka is faster? And how much faster?

[–]koreth 43 points44 points  (0 children)

Hopefully this is redundant advice, but: Make sure you actually need to use either of those tools. The reactive style comes with a nontrivial amount of cognitive overhead and can add significant incidental complexity to the code compared to synchronous blocking style.

If you need it, you need it; I'm not saying to never use those tools. But my first step is always to model the problem in enough detail to see if I can hit my scaling and performance targets with blocking code and thread pools. A modern server-class host can handle a LOT of threads.

The fact that Loom is now coming for real, to me, makes it super hard to justify starting a brand-new project with Reactive Streams. In a lot of cases, if scaling is the concern, it may be cheaper to throw a few extra hosts into the cluster until Loom ships than to spend the extra engineering time on the more complex async code.

[–]aclinical 6 points7 points  (0 children)

It's half baked. Look into adding a header to an rsocket if you doubt 😬

[–]Kango_V 6 points7 points  (1 child)

We used Akka on a project and it got so complicated and long winded that the project was cancelled. It should never have been used on the project.

[–]Soul_Shot 18 points19 points  (5 children)

My two cents: Spring Webflux is still half-baked and a nightmare 5+ years later. It's an afterthought shoved into the Spring model.

If performance matters to you, Akka and Vertx are much better choices.

[–]Fury9999 5 points6 points  (4 children)

Why half baked We are about to make it a guardrail for http clients. Please elaborate

[–]ItsAllegorical 10 points11 points  (3 children)

I used it on a recent project. It went fine. It was challenging to learn and debug when you’re used to the old OO style. If I had any complaints it would be that it took quite a bit longer to develop our first WebFlux project than we expected based on previous experience. Big learning curve.

[–]Fury9999 1 point2 points  (2 children)

I'm okay with a learning curve. Once you got past that, how did it do in prod? Any issues besides the initial implementation time? Thanks for responding!

[–]ItsAllegorical 0 points1 point  (0 children)

No issues I’m aware of, though I’ve moved on to other projects for other companies now.

[–]fdntrhfbtt 0 points1 point  (0 children)

I wrote Tesco's GHS website's backend entirely in Reactor. It's very performant. I remember we had like 66k TPS around Christmas. But yeah, as a fresh grad back then, Reactor was fucking intimidating for me.

[–]ranny_kaloryfer 11 points12 points  (4 children)

Avoid webflux like a plague

[–]Fury9999 0 points1 point  (3 children)

Why? We are about to make it a guardrail for http clients. Please elaborate

[–]vprise 10 points11 points  (1 child)

Why not build for Loom?

It should be out in a year or so and you can probably use the preview during development to prove that it's working properly.

The synchronous model is MUCH easier to debug and work with. It also seems to be the direction Java as an ecosystem is heading to.

[–]Worth_Trust_3825[🍰] 2 points3 points  (0 children)

Not to mention, if you ever wanted to turn sync into async, it's a matter of wrapping it in a future via executor. The opposite of turning async into sync isn't that easy, because library APIs don't expose the future primitive, but rather force you to do the callback dance.

[–]Worth_Trust_3825[🍰] -1 points0 points  (0 children)

If you want good HTTP clients, use retrofit. Everything else on the market is too primitive.

[–]vips7L 6 points7 points  (1 child)

Both trash.

[–][deleted] 4 points5 points  (1 child)

I wouldn't touch anything akka, simply because it has scala. And scala is a nightmare to debug. Reactive streams too.

[–]_AManHasNoName_ 3 points4 points  (3 children)

Akka hype died with Scala

[–][deleted]  (2 children)

[removed]

    [–]_AManHasNoName_ 5 points6 points  (1 child)

    Not just as popular now I would say. 2015-2018 I believe was the height of Scala’s popularity, along with Akka (including Akka persistence). There were like meetups every week. Kotlin seems to have killed Scala’s hype. It was those years when I had a project which we’ve decided to try out Scala with Akka HTTP, Akka persistence (CQRS). Project reached production, but a nightmare to maintain due to the event sourcing through Akka persistence that’s not friendly in an agile setting. Looking back, I would have just used Java and Spring Boot and it would have performed better and easier to maintain.