What do you consider as verticle design guideline in Vert.x?

user_12469208 0
Viewed 115

While the core manual (and other documentation) of Vert.x shows several use cases and gives good explanations of Vert.x in general, I am curious what are do and donts when designing verticle classes.

Preword: I am aware of that the design of Vert.x is in general AGAINST giving strict design guidelines. So, no need to mention this in answers.

An example that led me to this question is as following. I created a verticle named ServiceDiscoveryVerticle.java which has the following responsibilities:

  • read in a configuration file of services and then publish them via the Vert.x ServiceDiscovery
  • manage services additionaly in lists(published/unpublished) to keep track of unpublished ones
  • receive messages via the event bus, for either publishing or unpublishing a certain service

All this is code is manifested in the overriden start method.

So the core questions I ask in this questions are:

  1. What are do and donts when designing verticle classes ? (by your personal prefence/opinion)
  2. Are there any general guidelines of what belong to a verticle and what not ? (officialy or community-wise)
  3. Is it recommandable to split the start method up into private methods (if so, should it be in the same class or better put in a seperate one like OwnServiceDiscovery.java) ?
  4. Any other ideas/remarks on my given example(ServiceDiscoveryVerticle.java) ?
vert.x api-design concurrency java
2 Answers

One can do a lot of philosophy here, but I will try to keep it simple.

The fact is that a verticle and its start() is and will be the main way that you init your system, mount handlers, trigger things like loading config and co. So don't be too hard on yourself, this part is correct.

If you are using Web Service API or Service Proxy then handlers are mounted automatically for you. The actual code of these handlers are in external classes that you can decide on how to structure them.

If you are mounting your handlers on your own, then you can use a lot of inline code, or you can decide to extract them into classes. In a lager application however you will probably split and extract code as much as you can.

I personally extract code out of verticle as much as I can and make it a rather coordination and setup place. Also my start() method (or rather rxStart()) is a bunch of calls to other methods who's names give me an overview of what is going on in the start of system rather than having a lot of code that I can't read. But these are all personal preferences as you said. Vert.x does not imply any of it on you!

user_4387270
  1. Don't block the Event Loop
  2. Don't call verticle from another verticle, use EventBus
  3. If you're using executeBlocking, you're probably doing something wrong
  4. If you're constantly deploying/undeploying verticles, you're probably doing something wrong
  5. Don't share state using verticles
  6. Keep your verticles small, but not too small
user_59858530
Related