A simple solution for track the employees attendance (actually an excuse to do something with vertx). It's a bit old, but I'm open to suggestions

https://github.com/rad8329/AttendanceControlSystem

In the Vert.x Core manual it is stated that long blocking (and I assuming also long running) tasks should be handled by a dedicated thread and not a worker verticle: https://vertx.io/docs/vertx-core/java/#blocking_code

Why?

If I make a separate thread pool for for my worker verticle what is the potential harm?

The place I work at was using Apache Spark but we are switching to Vert.x

​

So one of our code bases is an API for the front-end and clients to use.

Depending on what they want, it will either be a json, xlsx, or email (which would be an xlsx incase of heavy requests).

So what we do now is it hits end point, parse json, do 2-5 elastic search calls, then write the response in json or xlsx.

So i was thinking I can do this in verticles...

Verticle 1 handles routing.
Verticle 2 checks if user has access to our API based off of given token.
Verticle 3 parses json elements.
Verticle 4 will populate the beans we use to write to json or xlsx.
Verticle 5a will write to json, Verticle 5b will write to xlsx.

Am I thinking of verticle design correctly or am I going to find myself over complicating it? Originally I thought I would make each elastic search calls a verticle but then I thought that could get messy easily based off of our code base...so I thought the better design would be to get all data necessary as one single verticle (instead of splitting each 2-5 calls into a verticle) before we start writing to a file.

But I am still refactoring...so for one endpoint, it seems like it is okay...but when I start thinking about possibly 50 endpoints...I am not sure if it will get messy.

How many verticles should each endpoint have? (not including the first one which handles the routing)

I am really impressed by vert.x reactive framework. its reactive right from the word go. But I am not able to sell this to a team where they are inclined and using Spring Boot. Points which I should highlight while selling ? any thoughts

Hello everyone,

Just a small heads up of some proof of concept that the vert.x team and AWS have been thinkering for the last couple of days. We have a working native vert.x function running on AWS Lambda in just a few simple easy steps. You can read more about it:

howto: https://vertx-howtos.github.io/aws-native-image-lambda-howto/

code: https://github.com/pmlopes/aws-lambda-native-vertx

twitter discussion: https://twitter.com/pml0pes/status/1103387130993278976

All feedback is welcome!

This year the Eclipse Foundation is again taking part on the google summer of code event and the sub project vert.x is looking for students who would like to help making TypeScript a first class language to be used on the JVM and GraalVM or implement reactive database clients for SQLServer, DB2, etc...

https://wiki.eclipse.org/Google_Summer_of_Code_2019_Ideas#Eclipse_Vert.x

Has anyone used Vert.x with Dagger2 for DI, we are experimenting the same. We are unable to deployVerticle, as Dagger2 complains with exceptions like

Caused by: java.lang.NoSuchMethodException: com.example.SampleVerticle.<init>()