Vert.x: A tool-kit for building reactive applications on the JVM | Hacker News Reader

Vert.x: A tool-kit for building reactive applications on the JVM

vertx.io

64 pointscfontes30 comments

I built a fairly complex app in vert.x a few years back. If you don't start with a promises library off the bat, you end up in a callback hell not unlike node.js.

You also realize very quickly how synchronous many of the Java libraries for things like databases, redis, etc are. The ecosystem just isn't built to work like that, but that's not the fault of the vert.x guys.

Isn't vert.x basically modeled on Node.js?

It was originally IIRC, but I think it diverged pretty quickly.

In some ways. Verticles can sort-of be analogized to individual node.js processes. The underlying service bus, however, is tremendously helpful and well-designed and, IMO, the real reason to use it.

The choices for me for my current project were vert.x or Dropwizard; I went with Dropwizard for now for ease of early development, but I've structured it so that I could fairly easily convert my Jersey resources (structured themselves as completely separate modules inside a monolithic application) into vert.x verticles.

Did you end up using an external promisese library or roll your own?

It's been a while since I've seen that code, but we used an external promises library and wrote some utility functions to make it easier to work with vert.x code.

I also highly recommend using JDK8's closures to reduce the boilerplate.

Can't argue with the synchronous Java lib part, but for the callback hell, I believe RxJava is the answer.

http://vertx.io/docs/

Vert.x provides the things like databases, redis, too. And no I don't use Vert.x However in Java it isn't that hard anymore to make a Sync Library Async, especially JDBC. Thanks to CompletableFuture on Java8, the problem is, is that not lot's of companies are on Java8, however if you are using vert.x that shouldn't be the case.

Libraries in Java are mostly Synchronous cause people use Java4, Java5, Java6, Java7 and not Lambda's and Futures. I mean there are really libraries out there who providing Java4 support. They provided Java3 Support until the end of 2014.. Especially Libraries who are generating content are having backwards compability to the beginnings.

Edit: Oh and the Vert.x JDBC Client is a wrapper around JDBC with RxJava / Future's. Which is basically the best thing you could do. Edit2: Oh and what I dislike more than synchronous code is code that has getters and setters, since that makes it hard to wrap a library into a thread pool since mutable data isn't a nice thing to deal with inside a async fashion. However it was traditional to have getter and setter classes . But more and more this isn't the case for newer things.

> Are you drunk?

Your comment would have been upvote-worthy had you simply left this bit of snark out. How on earth do you think this is a decent thing to say to someone you do not know?

Sorry you are right. Too much emotions .

> However in Java it isn't that hard anymore to make a Sync Library Async

Not necessarily true. Sure you can create a set of worker threads that take requests, process them synchronously, and hand stuff back but that's going to inflate your thread count and it's nowhere as optimal as writing a library that is async-aware from the first line of code.

On top of that, lots of Java code assumes that you'll be making various sequenced calls from the same thread. You'll find that libraries will randomly corrupt data or return stale reads if they haven't been synchronized properly. Many protocols (ie: Redis) have built-in pipelining that isn't used in sync libraries.

> You'll find that libraries will randomly corrupt data or return stale reads if they haven't been synchronized properly

Yeah that's what I meant with my second edit. it's really really aweful if libraries use a too mutual style.

Vert.x indeed looks pretty cool. But I found it a little bit weird that they used the term "reactive" in the title, but I'm not sure what the "reactive" is referring to: maybe Reactive Extensions, or at least RxJava? which should be perfect with vert.x to solve the callback hell problem. Or they just use it as a generic term for async technology used in vert.x/node.js/tornado etc?

> But I found it a little bit weird that they used the term "reactive" in the title

"Reactive" is the new cool term that replaced "async" and "non-blocking" from a few years ago.

For maximum impact it is advised to combine it with microservices (or even unikernels) in the same sentence.

ah, thanks for the explanation... I guess we probably need a "new_cool_term" namespace for every new/re-purposed term. Simply use "reactive" to refer to "async" already caused a name collision for me here....

It's not a direct replacement for asynchronous, as reactive implies quite a different set of semantics. The collision is only in your misunderstanding of the pattern. The jargon is meaningful, not marketing.

Good to know. Then the "reactive" mentioned in the title is not exactly async, and not exactly as in "Reactive Extensions" either, so where can I find the intended meaning of "reactive" in that context?

Reactive is "things happen, I don't need to know, async".

Right?

And to completely blow everyone's mind, add 'dockerized'.

FWIW, "async" was called the "Reactor Pattern" in the Design Patterns world back in 2000:

https://en.wikipedia.org/wiki/Reactor_pattern

But "(a)ll reactor systems are single threaded by definition"...

So is what we know of as "async" and "non-blocking". The point is that instead of spinning up many blocking threads, a single select/poll/epoll() call triggers a set of callbacks.

I refuse to believe its a "Pattern" until I find a AsyncReactiveReactorFactoryFactory class.

Also add containers to the mix and have a promotion tomorrow

What's weirder is the fact that they used the name Vert.x, which sounds like "vertex" in my head, which doesn't seem to have anything to do with what this library is trying to accomplish.

"Vertex" is a synonym of "node" in graph theory, and the .x part emphasizes multi-language support (compare the .js "extension" in Node.js).

https://github.com/caniszczyk/vertx-proposal/blob/master/pro...

wow, now I understand why it's named like that: a polygot "node"!

> Polyglot. You can use Vert.x with multiple languages. Vert.x doesn't preach about what language is best

Gradle should learn this lesson and also offer multiple languages for its build scripts, and more people might adopt it.

How is the ceylon integration going? I've been waiting for that before diving into vert.x 3.

I enjoy working with Akka to build reactive applications. Clean, Readable, Testable

Reply on news.ycombinator.com