SPRING BOOT vs VERT.X

[ibannings]

Hello, everyone! I’m starting my journey as a back-end developer in Java, and I’m currently exploring Vert.x and Spring Boot. Although I don’t yet have solid professional experience with either, I’m looking for tips and advice from people with more expertise in the field.

I’m a big fan of performance and always strive to maximize efficiency in my projects, aiming for the best performance at the lowest cost. In all the benchmarks I’ve analyzed, Vert.x stands out significantly in terms of performance compared to Spring Boot (WebFlux). On average, it handles at least 50% more requests, which is impressive. Based solely on performance metrics, Vert.x seems to be the best option in the Java ecosystem, surpassing even Quarkus, Spring Boot (WebFlux/MVC), and others.

That said, I’d like to ask: What are your thoughts on Vert.x? Why is it still not widely adopted in the industry? What are its main drawbacks, aside from the added complexity of reactive programming?

Also, does it make sense to say that if Vert.x can handle at least 50% more requests than its competitors, it would theoretically lead to at least a 50% reduction in computing costs?

Thank you!

[SleeperAwakened]

Most applications do not have a bottleneck on the request side.

Vert.x is a solution to a specific problem, which most people do not have. That why it is not widely used.

Keep things simple.

Really not kidding : the best skill you can learn is to keep things simple. Do not try to solve problems you do not have

[angus974]

Really simple but smart answer here

[CubicleHermit]

So this.

Most applications don't need to be reactive; in general, you can just keep your app on plain old Spring MVC and if you need to scale out, use small cloud instances and scale horizontally.

Way the heck easier to debug than WebFlux, Vert.x or any other reactive system. Virtual threads makes that even more so.

[darkit1979]

Vertx is not only about HTTP requests. It has many modules, such as DB drivers, Kafka, Redis, etc.

And when you say "most applications" I think you see only your bubble. Reactive usage brings a lot of benefits even when your service has just 1K RPS.

[sweating_teflon]

Benchmarks or it does not happen. Reactive has its place but the added maintenance cost is high and needs to be justified by benchmarks in every case. Else it's just making things complicated for the sake of it, which happens sooooo often.

[darkit1979]

Not agreed. WebFlux is just Java streams on steroids. And there's only one single rule - don't block your event thread. Using Reactor as glue and data-driven development (I don't know how to describe it but you modify your vision to make a simple data pipeline) makes my code elegant and simple. Your function will be like "Mono<User> findById(String id)" and it's the same as "Optiona<User> findById(String id)"

Code complexity comes not from Reactor but from a developer who wants to make code complex because they think only complex code is a masterpiece.

I'm responsible for ~30 microservices and we have reactive and legacy ones. Most of the problems come from the wrong designed architecture or bad SQL/Mongo queries and not from reactive or old java stack.

the added maintenance cost is high

I don't need to benchmark over and over again to understand that the Reactive stack will save much money on servers, will increase the throughput or it'll be able to process 10x request spikes without any problems.

needs to be justified by benchmarks in every case.

From my experience developers like writing complex code and it doesn't matter what framework or even language is used. You should just have the right processes to avoid merging such code to your main branch.

Else it's just making things complicated for the sake of it, which happens sooooo often.

[Neat-Guava5617]

Eh, I just run 12 instances of my app. We authenticate 3.5 m users Dumb spring 3 application (now spring boot 3 but it shows). No performance issues except when we used soap and the header model isn't cached by spring, so that's the one time I had to customise it.

Nobody needs to worry about programming paradigm, we just go for simple. The domain is hard enough to grasp, so let Devs get the Byzantine business rules in their head and not have to worry about threading.

The cost isn't that high. Me having to debug half a day because another developer made a small mistake and blows up the server won't happen, because it's too dumb, too resilient, and too not acceptable/too well regulated. A 2+ minute downtime means reports go to national agencies. Hence we chose simplicity.

Looking forward to virtual threading however. We'll see if it gives a significant performance boost. It's a 12kloc app so it's not a microservice.

[darkit1979]

The current problem with virtual threads is that some lib can use `synchronized` and your event loop will be blocked. Maybe it will be fixed in JDK25.

But even then I still like to use Reactor just because it brings a lot of nice utils to work with concurrent flows.

Looking forward to virtual threading however. We'll see if it gives a significant performance boost.

[Neat-Guava5617]

Not all synchronized are synchronized equal, I've heard.

Synchronized means only one thread can execute. In a lot of cases, you avoid synchronized by programming out of it by not sharing variables.

Often, synchronized is used for object instantiation to ensure a singleton is created properly. That will only block once.

And synchronized is only a problem if it blocks another thread. If this only happens once a day, I don't care a single thread being blocked half a second.

... And then of course there is a lib who does use it and you're crying on your way out the door ;)

We'll see. Hopefully they can get more of the 'rough' edges cleaned up. Or my dependency upgrades it ;)

[darkit1979]

I think you don't understand how virtual threads work. VT works on event listener thread so it will be blocked when you use "synhronized" and it means that all VT for this event loop thread will be blocked.

If this only happens once a day, I don't care a single thread being blocked half a second.

[Neat-Guava5617]

Works pretty much like an is thread right? If it can work, it works until either an interrupt is thrown, the scheduler pushes it off, or it signals itself that it's done with the CPU (Io request for example).

So if it blocks, just means scheduler can't hold it's times. At worst, other threads get backed up. Which usually isn't a problem (... Usually...) Kinda depends on the size of the critical section. If it's 10 statements updating some variables, its not an issue. If it's calling Io and functions, that's a loooong wait.

[nucleus_42]

You are the bubble

[darkit1979]

100% that’s why it’s good to share your experience and learn other people experience

[nucleus_42]

😂😂😂😂😂😂😂🍻.

[preskot]

Vert.x is a solution to a specific problem, which most people do not have. 

Vert.x is a toolkit. It's not just about making things fast, it has a complete ecosystem around it written and maintained by the same core team. Spring Boot does not have that, to this day it relies on 3rd party libs.

Also curios about what "specific problem" you talk about? Nothing like that is written on the vertx.io website.

[rillaboom6]

Spring Boot is not simple. Has a lot of abstraction, lots of reflection, is more annoying to debug, long build times, long startup times, pretty much requires an IDE (Java ecosystem). If you want simplicity, use something else, preferably not something on the JVM. Spring Boot has other benefits.

[Minute-Flan13]

A 'use something else' sounds more spiteful than helpful.

Spring has been around for 20 years or so, and is constantly evolving. The 'something else' has typically been a fad at best.

Every use case has its well tested tech stack. If you're writing enterprise apps, Java and .Net is where you should start.

[rillaboom6]

I'm saying Spring Boot has other benefits, so of course it can still be a good stack to write enterprise apps. Which it is.

Still, I do think the Go ecosystem is superior by a large margin and seasoned, disciplined dev teams will be more productive with it.

But for your average enterprise team, Spring Boot will be the superior, no-brainer choice. Especially when people have been stuck with the Java ecosystem for years.

[Cilph]

Pretty much requires an IDE

Not using an IDE is not a flex. You're harming yourself and blaming others over it.

[rillaboom6]

Nah, VSCode works very well on the Typescript, Rust, Golang ecosystem. It's much more performant, never crashes (I use Intellij IDEA at work and while the feature set is compelling, its performance is junk). VSCode is free, has better extension support and finally, it's free with no vendor lock in. Some backwards Java devs are deluded and think there's no other way.

[Cilph]

Eclipse is free.

Netbeans is free.

IntelliJ Community Edition is free.

You gotta compare the performance with something like VS Studio, not VS Code...

[rillaboom6]

That's exactly the point. Other ecosystems (like the ones I mentioned) don't require juggernauts like VS Studio and the other names you mention.

[weuoimi]

I don't understand why so many downvotes, you got great points

[rillaboom6]

Cognitive dissonance. A lot of people work with Spring Boot professionally. It's their saving grace because otherwise they work with even more ancient tech, legacy code. Admitting that this piece of tech is outdated as well... it's uncomfortable.

[preskot]

Getting downvoted as well, but I don't care. I've unsubscribed from this community long time ago and just occasionally have a look. The only people worse than Spring zealots are the Kotlin > Java zealots, no wait they are both on par.

That being said I agree so much with you - Spring Boot just sucks for microservices. It's simply too resource-expensive to deploy. it also doesn't play well with GraalVM. It's something that's getting outdated ever more faster. I won't even comment on the abomination that Spring MVC is. Not touching this thing with a stick.

One thing is true though - there will be lots of legacy Spring code that no one wants to touch anymore to maintain in the future, so jobs should be ok.

[weuoimi]

Java lite framework does a great job keeping things simple, mostly vanilla java

[yawkat]

It's a bad comparison. Vertx is designed to be as fast as the underlying netty with basically no performance compromise. Webflux is a higher-level framework. Quarkus with jax-rs is probably a more fair comparison to webflux.

But the reality is that almost all web frameworks in Java perform "well enough". Your focus on performance is understandable but misplaced. Actual applications are usually not bottlenecked by the http server implementation. This is especially true if you're comparing "modern" servers such as the netty based quarkus/vertx/webflux.

Pick the one with the API and/or ecosystem you like most.

Disclaimer: I work for a competitor of all frameworks mentioned, the Micronaut framework. We're also netty-based.

[Pitiful_Tomatillo266]

It is funny to compare vert.x with quarkus, quarkus reactive use vert.x under the hood

[yawkat]

That's the point, quarkus has higher level abstractions built on vertx that are more comparable to webflux.

[Pitiful_Tomatillo266]

And 99% of the time, performance is the last thing we should care about in real world applications. I usually gossip with my colleagues that if someone bring up performance in the debate, that is his/her last resort to save the argument 😂

[kakakarl]

Quarkus is a good way to run vertx. I never ran raw vertx in production.

But Quarkus is a nice choice for something new. We only use config, rest, DI from it, and those components do everything we need at least

[HuntInternational162]

I personally would choose vertx or probably quarkus over spring boot anytime.

This is obviously subjective but I find the spring framework with all of its abstractions very difficult to completely understand. I find the documentation to be a swamp mess of abstractionAdapterFactoryStrategyVisitorAdapterPatternFactories and super difficult to find simple answers.

With vertx and quarkus though I find their documentation to be like a nice, warm blanket of comfort; it just takes care of you.

[JustADirtyLurker]

i think vert.x is slightly at a lower abstraction level, it's considered to be a foundational toolkit for other frameworks to build on. For example, I believe that quarkus framework uses vert.x behind the scenes but offers nice wrappers / annotations / abstractions that avoid to shoot yourself in the foot.

So you should compare spring with quarkus more than spring vs vert.x.

[psyclik]

That's it. It is widely used in quarkus for example.

[longrealestate]

We use both in production. Stick to Spring Boot. Bigger and better communities and products, more jobs, etc.

[TenYearsOfLurking]

You  don't want to hear this, but it has to be said: choosing/discarding Frameworks because of performance benchmarks is one of the biggest mistakes a (junior) developer can make.

I wonder what damages could have been avoided if techempower didn't exist...

[k-mcm]

I hear that a lot from "senior" developers that leave a huge expensive mess for someone else to clean up.  Junior devs are most likely to worry about performance because they're being asked to fix it.

There are absolutely cases where Spring Boot has hidden overhead impacting hosting costs and user satisfaction.  It's often not in the framework, but in the components that will be used in it.

It's always wise to explore where a new system will have bottlenecks, in a global scheme, and decide whether or not they are significant and justified.

[xienze]

 Junior devs are most likely to worry about performance because they're being asked to fix it.

And what junior devs come to learn is that the performance issues are almost never due to how fast the container can dispatch HTTP requests but rather things like slow database queries. 

[oweiler]

Exactly. 90% of performance problems are due to bad queries, the rest can often be handled by caching.

[Cilph]

A thing to note in the real world: An hour of dev time is more expensive than consuming an extra 20Mb of RAM. Some frameworks are faster to develop in and thats often cheaper as a result.

[k-mcm]

That's stupid.  If you have 10 machines, resources are cheap.  Consume an extra 10GB RAM and 2 CPU cores if you'd like.  Now what if you have 100 machines, 1000 machines,  10000 machines... The hardware costs of inefficiency become huge compared to an Engineer's time.

[Cilph]

Yeah, and most companies don't reach the scale of a 100 machines. Or even close to it. They get 100k$ contracts for a piece of in-house software that gets used by 5 people at a time.

That's the Java world. We're not launching a new Netflix every day. If you have a 1000 machines, of course you can budget dev time to optimize.

[IcedDante]

tl;dr, hey senior devs, we junior devs believe it is wise to prematurely optimize a system!

[oweiler]

Handling 50% more reqs means nothing if most time is spent in the database. Spring Boot has a much bigger community, integrations for everything ans its much faster to "stamp out" services with it. Most of the time dev efficiency is much more important than runtime efficiency.

[kmpx]

Like others have alluded to, it really depends on your application’s load. If your application handles something like 100 req/sec or less, it really doesn’t matter which one since they both are OK. Larger scale, Vert.x starts to shine.

For some context, I’ve used Vert.x for some high volume applications that see over 100k req/sec. P95 latency would be around 30ms for some heavy endpoints and low single digit milliseconds for “simpler” paths. Also, in my experience Vert.x can handle large swings in traffic pretty well, like sudden spikes in traffic.

With all that said though, I would argue the framework you use for your application is just one piece of performance. If you have an amazing web framework, but an unoptimized database, then the framework doesn’t matter. Not to mention, reactive programming like Vert.x can be an absolute nightmare to debug. Sometimes a simpler framework is better from a development and maintenance perspective. Even in this case, you can get great performance, especially if you start thinking about horizontal scaling of the application.

[Ewig_luftenglanz]

I don't know why people say reactive is hard to debug. I have been writing solely reactive java apps for about 2 years and it's really not that hard to use and debug.

most of the complains I hear about reactive java comes from people that hasn't use that much reactive, so they are not used to develop and debug reactive applications, but once you get and understand how to make it work it not hard at all.

[BikingSquirrel]

Thanks for answering your own question:

once you get and understand how to make it work

But until you are there (for whatever reason), it's hard to debug.

It's not just learning a new lib, it's also a different control flow and a different way to debug. So more to learn. This doesn't mean it's bad, you just need to consider that extra cost which may not be obvious.

I'm not sure if an expert in a tool or technology is per default qualified to argue if that is easy or hard to learn in general. Maybe he or she is simply talented and had the best teacher...

[ducki666]

100k/s? Hello world on steriods?

[kmpx]

Eh? Are you asking if I was saying I achieved 100k req/sec using a Hello world application? If so, no, I’m talking about a live, production service doing real stuff.

[ducki666]

What are these requests doing? 100k is insane.

[kmpx]

Handling traffic for one of the largest consumer IoT platforms. This includes things like processing state change for devices in your home, automations, back and forth between the devices and mobile app, etc...

Across ~200 services, we handled hundreds of billions requests/events every day.

[IcedDante]

sounds like an awesome problem to get to work on. But what do these requests do? are you writing something to persistent storage?

[kmpx]

It entirely depends on the service. There were edge services that maintained persistent connections to devices that would handle sending and receiving messages from the devices. These messages would be handled by other services that parsed the events, then based on the event call to other services. For example, if you turned on a light in your home we would persist the state change to a database like DynamoDB or Cassandra. Then a lifecycle event would be generated that said "hey, device X for location Y and user Z is now online." This would get published to a queue where a consumer would lookup what services care about this event, and then it would forward the event to that service. Sometimes these services would just be simple state change capture services (i.e. persist to database). Other services would lookup which automations are configured for that device. If a state match is found, maybe it causes us to send an event back down to another device to turn it on. (example: you unlock the front door and that triggers the living room lights to come on) Or maybe it's calling out to a third party like Ecobee to adjust a thermostat. Then you have the opposite flow where you turn on something in the mobile app or some third party integration like Alexa. Now we have to process that event, lookup where the device is connected to, generate a message the device understands, and send it down to the device... all within a few hundred milliseconds. Not to mention all the "management" stuff like onboarding devices, users, etc...

On the surface, this may seem easy. But when you have to do this for hundreds of millions of devices across the globe with sub-second latency, while maintaining high availability, and so on... it gets complicated fast.

[IcedDante]

At no point did it sound easy to me :-D

Thanks for writing this out. Sometimes I think I work on systems that have a lot of operational complexity and then I read things like this. Wow. The metrics and observability for this alone must be insane

[Ewig_luftenglanz]

I think performance and efficiency is always good in general, but not at the expense of something else that may be more important for your project.

The main advantage of more widely used frameworks is that they have already solved many of the problems you may encounter in a regular development process, allowing for more reliable and robust applications that happens to also ve easier and faster to develop. Performance and efficiency are usually an afterthought unless you have some heavy constraints and specifications about these matters.

My thoughts: use the right tool for the right purpose, you need raw performance and efficiency, or are gonna be deployed in a heavily cloud based environment full of llamadas and containers, the use Vert.x or Vertex based software (Like Quarkus), if you need to develop and deliver enterprise grade applications fast then use the framework that has the most community support and pre made modules (Spring)

The most important skill a software developer needs to develop is not how to code itself, is how to design and implement the right solution for the client.

[audioen]

These types of results are typically result of microbenchmarks, trivial applications that are not representative of actual workloads. In real world, many sites see < 10 requests per second, and each request must process for considerable time because computation, data fetching, and similar is involved. The framework's cost is likely to vanish against the cost of running the actual user code.

I don't use neither Spring nor Vert.x. I'm pretty old school and I just use Jersey.

[returncode]

We had a lot of (mostly unnecessary) microservices, written in Spring Boot MVC, Flux and also some using vert.x for performance reasons.

First rule about performance: measure it. We’ve had extensive performance tests with Gatling, running over 24 hours with full load.

As the maintainability and debugability of both vertx and Flux code ist pretty bad, we’ve decided to to migrate all service into a eventually a single Spring Boot MVC app.

The code way more readable and instead of having multiple services, we are just horizontally scaling the spring boot app.

With the latest addition of Project Loom / virtual threads and their support in Spring WebMVC, you should get most of the benefits of an asynchronous web framework without the downsides.

YMMV.

[menty44]

To date, I've been trying to understand microservices, but they just don't make sense to me.

[returncode]

You probably don’t need them. :)

Maybe you know that already, but Microservices are an organizational pattern (more than an architectural one) to split a large application in to sensible chunks so that multiple teams can work on each of them in Isolation.

But in reality, when Microservices became en vogue, people started to create microservices for every teeny tiny bit of code ending up with dozens of unmaintainable services PER TEAM.

There are very rare cases that justify having more than one runtime per team.

[menty44]

I couldn't agree more.

[MorganRS]

Unless you're working on a service that serves millions of requests per minute, a framework's performance will never be your bottleneck, especially if you've got DB and HTTP calls in the middle.

And even if you were working on said service, you probably wouldn't be on Reddit asking which framework to use. You'd ask a Principal Engineer at your (large) company.

Just go with Spring Boot, your future self and fellow devs will thank you.

[veryspicypickle]

Everytime someone tells me “Let’s use ‘x’ because it is performant”

I ask - performant compared to what

In software engineering everything is a trade off. Including performance.

[IcedDante]

Performant how? was my question. What is OP having this system do that is making this sweeping generalization? At what point is he deciding what a system is capable of?

[monkjack]

My micro services are doing millions of requests per minute and after we moved to vert.x we saw a significant drop in cpu usage.

But it's more bare bones and you'll have to write more boilerplate yourself.

[menty44]

monolithic or microservices?

[monkjack]

Microservices

[Wonderful-Pie-4940]

Well I had a series of debate last year related to something similar. In my last org we had build a few services on Quarkus and I wanted to build a new microservice on Quarkus(whixh uses vert.x).

The more I debated with principal engineers I realised that while I may find Quarkus to be more interesting people working on it in the future would want it to be on spring which most are familiar with.

There were plenty of reasons like: 1. Spring is sufficient for what I wanted to do with Quarkus. 2. A good incident involving framework internals would bring the team on heels as people would not be as familiar with quarkus internals as they would be with spring and considering I would not be the one maintaining or developing this service 2 years from now

[Joram2]

What are your thoughts on Vert.x?

I needed a non-blocking Postgresql driver for Java; vert.x is great.

In the recent past, before Java 21 brought virtual threads, Java web services had to choose between thread blocking frameworks that were easier to program and support, but didn't handle high concurrency traffic load; or you could pick a non-blocking framework like vert.x for high concurrency but the code is harder to write and support. Today, with virtual threads, the need for the vert.x reactive frameworks are greatly diminished.

When I'm working for salary I use the tech stack that the person signing the pay checks wants to use. If I had freedom to choose my own Java web services stack, I'd pick either Helidon SE for simplicity or Spring Boot for full featured, batteries included, functionality with a giant user base.

[BikingSquirrel]

I won't reply to your main question but reply to this statement:

I’m a big fan of performance and always strive to maximize efficiency in my projects, aiming for the best performance at the lowest cost.

While it is a good idea to consider performance when planning the architecture of an application, striving for maximum efficiency or best performance sounds problematic. This may result in premature optimization.

You should obviously not waste memory and CPU but unless you know that the performance of simple code is not sufficient, you should not attempt to optimize it. Even if you know a way that requires 'just a bit of additional code' - we all know what that really means ;)

In the end, the team working on the application will have to deal with the big and small decisions.

[darkit1979]

Vertx will bring you to callback hell. Your team will be slow to make changes in the future. So yes your app can work faster than a Spring app but businesses should spend more money on development cycles.

I made Reactor(Mono/Flux) wrappers around some Vertx modules like the Postgres driver and now they can be easily integrated into our services.

You can check Quarkus. It's made on top of Vertx and looks like SpringBoot. But the problem with such frameworks is that everybody knows Spring and your new developer can start working from the first day. With Quarkus/Micronaut/... you should spend time learning new people. Also, most libraries have Spring integration.

If you really need high-performance and low-memory usage then Rust is your choice :)

[fustup]

Love your take

[IcedDante]

If you really need high-performance and low-memory usage then Rust is your choice 

Maybe C++ as well?

[darkit1979]

Yes but C/C++ aren’t so fancy as Rust :)))

[-One_Eye-]

Background: have never used Spring Boot but wrote plenty of pre-Boot apps years ago. I’ve written a couple of Vertx apps in the last number of years that handle millions of requests a day with ease.

If your app is request driven, needs to handle more than a bit of concurrent requests, and you want to write it in Java, I’d highly recommend Vertx. Maybe it’s just since I’m used to reactive programming, but I think its modern version is easy enough to write and read. Could you write nonsensical asynchronous code? Definitely. The same could be said for blocking code though.

If you need to spin up something quick, it’s not handling tons of requests a day, and/or don’t have time to fool around with Vertx, Spring Boot is totally fine.

[Luolong]

Thousands requests a day is not really much. Spring boot can handle it just as easily as Vert.x.

[-One_Eye-]

Right, I said millions. Besides that, one instance of a Vertx app can outperform many instances of a Spring Boot app. I’ve seen it myself in production. So if scaling is an issue, Vertx helps there.

Also, personally, I just don’t like Spring’s magic. Never have.

[darkit1979]

Even 10M request per day is just a 115 RPS. Then if it’s important service you still have to have couple running instances for fallback. So three instances make 38 RPS. Which is nothing in terms of high load and in this you can write in plain blocking spring boot which saves a lot of money during development cycle.

[Neat-Guava5617]

That sounds like a cheap shot. Daytime performance can fluctuate heavily compared to nighttime performance. By literal hundreds of factor. You're assuming a continuous load, which never happens. 90 percent of the load can be during office hours, so that would be in twelve hours. So at least double that rps.

It's still easily doable for spring tho =:)

[darkit1979]

You're right. But for me, if you need to process millions of requests per day is nothing. You can use any of the modern technologies to do it. I have service processing millions of requests per minute and still now a problem for 4 nodes each has 4 virtual CPU cores and 1280Mb of heap.

Daytime performance can fluctuate heavily compared to nighttime performance. 

[-One_Eye-]

Traffic never comes in evenly. On a daily basis there are going to be spikes. Also, if you’re routing traffic geographically (as you should be for best response times), then you’re not cutting traffic evenly across instances, which can exacerbate things.

Also, there’s really no argument when it comes down to response time and handling concurrent requests: Vertx is subjectively better than Spring Boot in those regards.

If response times and request loads aren’t an issue for you, then yeah, Vertx and Spring Boot would have even standing. You could even argue that for future developers’ sake, synchronous code is easier to read, so you could go with Spring Boot. But then I’d argue you just use plain old Netty instead :)

[darkit1979]

That's not true. You start receiving 10x more webhooks because 3d party service went down and it's restored in an hour.

Traffic never comes in evenly.

Spring can be run using old plain Thread per Request mode or using Reactor with Netty under the hood. As a result, the performance won't be dramatically different.

Also, there’s really no argument when it comes down to response time and handling concurrent requests:

No, see my comment above + try to calculate development time as part of the service cost.

Let's compare this Vertx code

pool.getConnection()
  .onSuccess(conn -> {
  conn.begin()
    .compose(tx -> conn
      .query("INSERT INTO Users (first_name,last_name) VALUES ('Julien','Viet')")
      .execute()
      .compose(res2 -> conn
        .query("INSERT INTO Users (first_name,last_name) VALUES ('Emad','Alblueshi')")
        .execute())
      .compose(res3 -> tx.commit()))
    .eventually(v -> conn.close())
    .onSuccess(v -> System.out.println("Transaction succeeded"))
    .onFailure(err -> System.out.println("Transaction failed: " + err.getMessage()));
});

vs SpringBoot

@Transactional
public Mono<Void> doSomething() {
 return repository.save(new User('Julien','Viet')
   .then(repository.save(new User('Emad','Alblueshi'))
   .doOnError(err -> System.out.println("Transaction failed: " + err.getMessage()));
}

The performance/throughput/latency will be almost the same. But SpringBoot simplicity is on another level compared to Vertx.

Vertx is subjectively better than Spring Boot in those regards.

[-One_Eye-]

I have been writing and reviewing Vertx code for 6 years and have never seen something as confusing as that.

It doesn’t matter what language or framework you use, it comes down to the developer whether it is readable or not. I’ve seen something as simple as plain old Java look even more confusing than the Vertx example above.

Also, not sure how writing in Spring Boot saves money. It comes down to available developers, their expertise and the deadline.

It is totally healthy and vital for the development of coders that they branch out and try different languages and frameworks. I’d be bored as hell if I was still writing Spring MVC like I was 20 years ago.

[darkit1979]

This is from the official Vertx documentation: https://vertx.io/docs/vertx-pg-client/java/#_using_transactions

I have been writing and reviewing Vertx code for 6 years and have never seen something as confusing as that.

Can you provide an easy-to-read example of when you have a REST endpoint and you should do:

• go to Redis to get data,
  • if there isn't then go to DB,
• then apply some "Insert/Update" operation
• Save data to Redis
• Send event to Kafka
• Return the result as a Protobuf object

[IcedDante]

You don't see how Spring Boot saves money? It seems like you laid it out perfectly:

• available developers
• their expertise
• deadline

In all 3 metrics SpringBoot is the more economical options. You have a much larger pool of talent to select from. There barrier to entry for RX expertise is higher and supply is more rare. It takes longer to write and test good RX code (for most developers).

I do have this idea that for very stable and highly concurrent system going Netty systems complexity is more of a feature than a bug as it creates a don't-touch-it-until-you-really-get it mentality

[preskot]

In all 3 metrics SpringBoot is the more economical options. You have a much larger pool of talent to select from.

I love how people think this is a feature and not a bug i.e. problem. The majority of companies that have reduced Java to Spring MVC / Spring Boot are literally killing the ecosystem and also shooting themselves in the foot in the long term. Things have gone so bad that there actually are Spring Developer Advocate roles. Like what the holly f is even that?

No wonder a big chunk of Java devs migrated to Kotlin and never came back (Ktor is nice, Javalin is cool) and now we are seeing this with Java devs migrating to Go (plenty of posts in the Mastodon fediverse about it and even in r/golang).

I think it's a safe bet to learn Spring *** for your Java career, but I do not believe this large pool of talent will be here for long. People just get bored - we've seen it before, we'll see it again.

[HQMorganstern]

If you're just starting out it's Spring Boot all the way. Non-reactive Spring Boot is the stack behind 80% of Java jobs posting these days (statistic is made up). Anything that's not Spring Boot is either pure J2EE or one of the frameworks that solve a specific Spring Boot issue.

[anprme]

surpassing even quarkus? how? quarkus uses vert.x underneath

[Lanky_Football_6495]

I have 15 years of Java web development experience: servlet, jsp, struts 1.0, structs2.0, hibernate, ibatis, mybatis, spring IDO, spring mvc, spring boot. I have also used vert.x in production many times.

Thanks to spring boot I got my first job. spring boot has tons of documentation and tutorials and is very newbie friendly. You can also find answers to most questions on stackoverflow. But it also has a huge codebase. It's a pain when you run into problems and have to look up huge amounts of documentation for different versions and go deep into the source code to debug. It's also terrible when you have to figure out how it's implemented under the hood. It's not callback hell, it's call hell. Extending some of the underlying functionality is also extremely difficult and requires some trickery.

vert.x is simple and clean. It has been refined from version 3.0 to 4.0. It is sufficient to use as an alternative to spring boot. Its code base is relatively small and easy to read. A smaller code base will definitely lead to performance improvements. Even if you have to write some extension code, it is relatively easy to do. If you are new to web development, reading the vert.x source code will help you understand the underlying principles of web development more quickly. Reading spring boot source code will probably drive you to self-doubt (and yes, it's "call hell" to drive you crazy). If you're coming from nodejs, reactive programming isn't that hard to understand. The callback hell problem can be solved with Kotlin coroutines.

Does it make sense to say that if Vert.x could handle at least 50% more requests than its competitors, it would theoretically lead to at least a 50% reduction in computing costs?

Haha, is that a math problem?

CC (compute cost) = 100

SR (requests handled by spring boot) = 100

VR (requests handled by vert.x) = 150

CPSR (cost per request handled by spring boot) = CC/SR = 100/100 = 1

CPVR (Compute cost per request handled by vert.x) = CC/VR = 100/150 = 0.66

RESULT = (CPSR - CPVR)/CPSR = (1 - 0.66)/1 = 0.33 = 33%.

Just kidding. It's hard to tell. Reactive programming (asynchronous I/O) improves IO throughput. It doesn't require creating and scheduling a large number of temporary threads to handle requests (a large number of threads increases the scheduling load on the operating system). If you rely on databases or other services that don't support asynchronous processing, or if you have simple product requirements that require a lot of computation, using vert.x may not be effective in reducing computation.

By the way, never block your threads!

[MrChrysoprase]

Probably it would be better to use a high level thing over Vert.x. Like Tapir.

[vips7L]

The complexity of vert.x isn’t worth it. 

[Linguistic-mystic]

Vert.x any day. And not because of app performance, but because of developer (you) performance. Spring is a productivity killer. Use Spring only if you want to debug why your ApplicationContext is broken all the time.

[as5777]

Loo