Best practice to create new Verticals in Vertx

Question

Could anyone give me the best practice when I need to create new Verticals in Vertx. I know that each vertical can be deployed remotely and put into cluster. However, I still have a question how to design my application. Well, my questions are:

1. Is it okay to have a lot of verticals?
2. E.g I create a HttpServer, where a lot of endpoints for services. I would like to make different subroutes and set up them depending on enabled features (services). Some of them will initiate a long-term processes and will use the event bus to generate new events in the system. What is the best approach here?

For example, I can pass vertx into each endpoint as an argument and use it to create Router:

getVertx().createHttpServer() .requestHandler(router::accept) .listen(Config.GetEVotePort(), startedEvent -> {..}); ... router.mountSubRouter("/api",HttpEndpoint.createHttpRoutes( getVertx(), in.getType()));

Or I can create each new Endpoint for service as a Vertical instead of passing Vertx. My question is mostly about is it okay to pass vertx as an argument or when I need to do it I should implement new Vertical?

Answer 1

My 10 cents:

1. Yes, the point is that there can be thousands of verticles, because as I understand it the name comes from the word "particle" and the whole idea is a kind of UNIX philosophy bet on the JVM. So write each particle / verticle to do 1 thing and do it well. Use text streams to communicate between particles because that's a universal interface.

Then the answer to your question is about how many servers you have? How many JVM's are you going to fire up per server? What memory do you expect each JVM to use? How many verticles can you run per JVM within memory limits? How big are your message sizes? What's the network bandwidth limit? How many messages are going through your system? And, can the event bus handle this traffic?

2. Then it's all about how verticles work together, which is basically the event bus. What I think you want is your HttpServer to route messages to an event bus where different verticles are configured to listen to different "topics" (different text streams). If 1 verticle initiates a long term process it's triggered by an event on the bus then it puts the output back onto a topic for the next verticle / response verticle.

Again, that depends how many servers / JVM's you have and whether you've a clustered event bus or not.

So 1 verticle ought to serve multiple endpoints, for example using the Router, yeah, to match a given request from HttpServer to a Route, which then selects a Handler, and that Handler is in a given Verticle.

Answer 2

It's best to have a lot of verticles. That way your application is loosely coupled and can be easily load balanced. For example you may want 1-3 routing verticles, but a lot more worker verticles, if your load is high. And that way you can increase only the number of workers, without altering number of routing verticles.

I wouldn't suggest to pass vertx as an argument. Use EventBus instead, as @rupweb already suggested. Pass messages between your routing verticles to workers and back. That's the best practice you're looking for: http://vertx.io/docs/vertx-core/java/#event_bus