Best practice on verticles

[CK]

Hello,

Just starting with Vert.x so please bare with me.

In most of the examples in documentation database interaction is done on a verticle that also implements the http server.

In real life applications should we decouple the database interaction on a separate Verticle?

I was considering something like:

public class MainVerticle extends AbstractVerticle {

  @Override
  public void start() {
    Vertx vertx = Vertx.vertx();
    vertx.deployVerticle(new MongoDBClient(), this::ganericHandler);
    vertx.deployVerticle(new HTTPServerVerticle(), this::ganericHandler);
  }

  private void ganericHandler(AsyncResult<String> ar) {
    if (ar.succeeded()) {
      System.out.println("Verticle deployment complete: "+ar.result());
    } else {
      System.out.println("Verticle deployment failed, Error:"+ar.cause());
    }
  }

} 

Is this the Vert.x way? If so, how do I chain Verticles to make sure db is available before loading the server?

Thanks

[Gadi Eichhorn]

Hi CK

not really, the DB client is a thin client, can be used in the same verticle and make sure you are using Async to not block the HTTP server inbound calls.

Your other option is to communicate between your verticles with the event bus, you can use request response to return your query results. This will involve network and parsing back and forth to JSON (the bus). It is less recommended solution in my opinion.

Regards,

Gadi. 

[ad...@cs.miami.edu]

Hi CK,

No hard necessity to separate your DB from your server in an additional verticle.  That being said, there is no reason you can't have a dedicated DB verticle, this would work fine.  Just keep the event loop non-blocking and you should be good no matter where you put your DB. 

One disadvantage of a second verticle is that event-bus communication will require some seralization (likely JSON) which may cause a small performance hit.

One advantage to putting the DB on a second verticle is that you can in the future easily put that DB verticle on a separate JVM on a separate server if you want, with little code change.

-Adam

[CK]

Hello,

Thank you both for your replies.

I've decided to keep the database client on the same verticle and inject the Vertx and MongoClient dependency. Is this a good practice? 

public class HTTPServerVerticle extends AbstractVerticle {

  @Override
  public void start(Future<Void> startFuture) {

    MongoClient mongo = MongoClient.createShared(vertx, config());
    MongoDBClient mongoDBClient = new MongoDBClient(vertx, mongo);

    Router router = Router.router(vertx);
    router.post("/api/job").handler(mongoDBClient::createJob);

[Manikanta G]

Having separate verticle will allow us to individually scale only that verticle by deploying multiple instances of it. I've similar scenario, where I've Poller verticle which polls Kafka and processor verticle. Major work will be done in processor verticle. So I've deployed 1 poller verticle, 4 processor verticles.

Thanks,

Manikanta G

[Gadi Eichhorn]

Yes, keep it simple! 

you can alsways go super complex later with the event bus over docker network, that will be a lot of fun ;)

p.s. the way to think of this is do you ever need to scale one without the other? 

you alwasy need a DB client for your web endpoint and you never need DB endpoint on its own.

[Grey Seal]

Agreed with Gadi.

It also depends on the use case that you are going to solve. I have a sample web application which creates a user and after successful creation sends an email. For this, I have multiple instances of HttpServer Verticle and single instance for Database Verticle (this is worker verticle) and a single instance of Messaging verticle. If I add more instances to Messaging Verticle, say 2, the message will be processed by both instances and will result in multiple emails being sent. Though this can be resolved by maintaining state in the database, I choose to keep it simple.

The code can be found here:

https://github.com/greyseal/vertx-realworld-app