Regarding my former post, Vert.x Boot, I was told that there is actually a similar project rising:
Vertx Zero https://t.co/0ngUlTowm6
— Jose (@JARP80) August 10, 2018
Vert.x Zero Up is apparently flying mostly under the radar, at least I have not heard anything about it yet. So it is time to check it out, I don’t really have time to play with it right now, but maybe I can see from the docs if it is going into the direction that I want to go.
import io.vertx.up.VertxApplication;
import io.vertx.up.annotations.Up;
@Up
public class Driver {
public static void main(final String[] args) {
VertxApplication.run(Driver.class);
}
}
That seems close enough to what Spring Boot is doing. I’m just wondering where the @Up annotation is needed for. Also using the io.vertx package namespace is a bold choice.
In my imagination that would be more like:
public class Application {
public static void main(final String... args) {
VertxBoot.application(args)
.withResources(UserResource.class, AvatarResource.class)
.withModules(SqlDatabaseModule.class, RedisModule.class)
.withModules(BusinessLayerModule.class, DaoLayerModule.class)
.bind(8080);
}
}
A clear entry point for the application, that shows you what kind of features are used and what the structure of the application is.
I definitely don’t understand everything that Vert.x Zero Up does, apparently there are multiple modes to run an application, they all look the same code wise but require differnt YAML configuration files. It comes with JSR 311 support, which seems to be a custom implementation, something that would come for free when using Vert.x Jersey. There are some nice additions though, it allows @StreamParam with Vert.x own Buffer class, it requires some custom annotations though, and does classpath scanning, something that I’d really love to avoid due to startup performance reasons, we want to have micro services after all.
There is an interesting concept in there about offloading event loop work to worker threads with annotations (@Address) via the Vert.x event bus. I’m not a huge fan of this implicit coupling, that might get out of hand quite quick. On the other hand we are talking about micro services, so there should only be some of those bridges in any given service. I’m wondering if someone could achieve something similar that is transparent but still uses one given rx2 flow that would be easier to follow.
In general I’m pretty amazed of the amount of documentation there is, that is pretty good. Though a lot of it feels somehow generated or auto-translated but it is pretty excessive.
JSR 303 is supported, but only inside the system and not for request objects as far as I understand the documentation. I think that would be an essential part.
I still need to check if all the JSR 311 and JSR 330 support is custom, because I strongly believe that one should use existing libraries for that, otherwise maintenance will be a hell. From what I see from the docs it looks like that, because there are given limitations e.g. for JSR 330 as everything is a singleton.
I will play with it for an afternoon, but from what I’ve seen so far I want to go in a different direction and thus it may be still worth to spend some time to build a prototype of the framework I imagine.
BTW, I’m still looking for a good name for Vert.x Boot that does not collide with Vert.x and Spring Boot.
blog.thiesen.org 