Quarkus is just a little too much like magic for me. Too many annotations hides what's going on underneath, which makes me feel a bit uncomfortable. But I'll accept that's probably just me.

Vertx on the other hand, which it is built on and which itself builds on Netty, is excellent, and very performant for typical backend services. It now has support for virtual threads too.

▲

winrid a day ago | parent | next [-]

Please DO NOT build a large application on raw Vertx. Quarkus gives you things like auto generated openapi specs etc.

Quarkus is just compile time stuff around vertx, and you write simple synchronous code. Again, DO NOT use vertx directly for building APIs. It'd be like using just expressjs and writing your api specs manually... in 2025...

	▲	kitd 13 hours ago \| parent [-]
		No capitals needed. I have written many backend services around raw Vertx very successfully. It's simple, well documented and predictable, mainly because everything is done in code. Deviating from Quarkus's standard behaviour was comparatively difficult, either tracking down the correct configuration properties and what to change them to, or which api to implement and override and what it needs to do. I prefer to develop OpenAPI specs separately from the code too, mainly because it's a joint effort with other teams. Vertx can incorporate them easily.

▲

vram22 a day ago | parent | prev [-]

>Vertx on the other hand, which it is built on and which itself builds on Netty

What does the highlighted part above mean?

I know what Netty is, but did not understand that phrase above,

	▲	kitd a day ago \| parent [-]
		Vertx uses Netty as the event loop handler for concurrent IO. Vertx adds a simplified asynchronous API on top of Netty (whose API can be pretty complicated), making backend services that need to handle large numbers of concurrent connections easy to implement. HTH