7 ms·

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

64 points by cfontes 11y ago

mmastrac 11y ago
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.
- jinst8gmi 11y ago
  Isn't vert.x basically modeled on Node.js?
  - mmastrac 11y ago
    It was originally IIRC, but I think it diverged pretty quickly.
  - eropple 11y ago
    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.
- pbh101 11y ago
  Did you end up using an external promisese library or roll your own?
  - mmastrac 11y ago
    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.
- fredliu 11y ago
  Can't argue with the synchronous Java lib part, but for the callback hell, I believe RxJava is the answer.
- merb 11y ago
  http://vertx.io/docs/ 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.
  - yid 11y ago
    > 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?
    - merb 11y ago
      Sorry you are right. Too much emotions .
  - mmastrac 11y ago
    > 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.
fredliu 11y ago
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?
- rdtsc 11y ago
  > 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.
  - fredliu 11y ago
    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....
    - oldmanjay 11y ago
      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.
      - fredliu 11y ago
        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?
      - kpil 11y ago
        Reactive is "things happen, I don't need to know, async". Right?
randomThoughts9 11y ago
How is the ceylon integration going? I've been waiting for that before diving into vert.x 3.
vorg 11y ago
> 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.
hhimanshu 11y ago
I enjoy working with Akka to build reactive applications. Clean, Readable, Testable

64 points by cfontes 11y ago

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.

jinst8gmi 11y ago
Isn't vert.x basically modeled on Node.js?
- mmastrac 11y ago
  It was originally IIRC, but I think it diverged pretty quickly.
- eropple 11y ago
  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.
pbh101 11y ago
Did you end up using an external promisese library or roll your own?
- mmastrac 11y ago
  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.
fredliu 11y ago
Can't argue with the synchronous Java lib part, but for the callback hell, I believe RxJava is the answer.
merb 11y ago
http://vertx.io/docs/ 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.
- yid 11y ago
  > 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?
  - merb 11y ago
    Sorry you are right. Too much emotions .
- mmastrac 11y ago
  > 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.

fredliu 11y ago

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?

rdtsc 11y ago
> 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.
- fredliu 11y ago
  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....
  - oldmanjay 11y ago
    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.
    - fredliu 11y ago
      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?
    - kpil 11y ago
      Reactive is "things happen, I don't need to know, async". Right?

randomThoughts9 11y ago

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

vorg 11y ago

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

hhimanshu 11y ago

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