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...

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.

If you're generating the vertx route handlers from the spec then I guess that's fine.

I gave Vertx a chance a few years back and while it worked, it's not great for building services on, unless your needs are extreme scale. And in the latter case, you might be better off with a language like Go. It's very async/reactive and a bit of magic hides behind those nice builder patterns.

My advice: If you are just building a regular service that doesn't need to scale (and 90% of apps do not need Twitter scale), just stick with sync.

>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,

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