Benefit of using vertx if you cannot use event bus due to lack of persistence...

[jeff.ba...@gamesys.co.uk]

Hi,

I have been experimenting with vert.x over the last week or so and just trying to get my around around the various concepts. I want to create a system comprised of a set of event-driven microservices (maybe HTTP or not HTTP based) that together process a series of user generated events. Each microservice is responsible for performing some form of action on the event e.g. tracking/update some state about what the member has done, sending outbound communications e.g. email, onsite etc. running various calculations. It's important that events sent from each microservice (e.g. maybe a tracking threshold has been reached ) are persisted and when a microservice is restarted in can recovery by receiving messages that is missed whilst the service was down. I cannot see how this is possible using the event bus as there are no guarantees or persistence of the messages. Therefore I would like to use another form of message queue e.g Kafka, AMQ etc. If I did this and had a series of verticles all consuming from topics / queues on an external message broker then I would not need to use the event bus at all. Therefore if makes me question what I would get from using using vertx at all in this scenario. Would it be the benefit of the non-blocking event handlers, but again couldn't I just achieve using other libs like rxjava and create fat jars using spring boot etc.?

Any help would greatly be appreciated, maybe vertx isn't suitable for my needs, but I wonder if I'm misaligned conceptually. How can you create a system of event driven microservices where messages have delivery guarantees / persistence using vertx, does using vertx without the event bus still make sense? is there still value in sticking with vertx over just using spring boot/rxjava etc?

Regards,

Jeff.

[Julien Viet]

Hi,

as you said if you need persistent messaging, you should use Kafka or a message system (RabbitMQ, AMQP) which can be a good fit for message driven microservices (keep in mind that the latency and throughput will be impacted though).

The EventBus of Vert.x is just a small part of Vert.x and you don't have to use it.

The Vert.x stack provides the aforementioned components to form a reactive and coherent ecosystem.

Our mission is to make sure that Vert.x has excellent performance (Vert.x ranked #1 in latest TFB single query benchmark which is very competitive), small memory footprint and remains very lightweight (as less dependency as possible).

now concerning your needs and the relevancy of Vert.x, I let up to others to chime in :-)

Julien

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/7ba91701-f20a-4e6d-8268-f38808c6e7e5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[jeff.ba...@gamesys.co.uk]

Thanks for taking the time to reply Julien.

Maybe I could ask this question the other way around. How would I implement reliable messaging between microservices using the event bus? I'm guessing I would need much smarter microservices e.g. they should implement retry, check for replies (like an ACK), use local storage to persist unsent/failed domain events etc.

[Julien Viet]

yes you would need to do that on your own.

perhaps one could create an EventBus interface wrapping the KafkaClient ?

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/7b5d5ee6-9dc5-4322-9682-21b5b6d0ec5f%40googlegroups.com.

[Thomas SEGISMONT]

Hi Jeff,

The EventBus is a lightweight messaging system. As you said it does not guarantee delivery nor persists messages. In this regard, it is no different from HTTP.
Consequently, the same practices should be applied in case of failure: retry and if issue persists propagate the failure to the caller.

Many systems are designed like this and work well.

Now if in your architecture you really need a reliable messaging system, I suggest to take a look at the existing integrations first (RabbitMQ client, AMQP1.0 client, ...etc)

Implementing your own reliable messaging system on top of the event bus should be, imho, a very last resort.

As for the benefits of using Vert.x with an external messaging system, they are the same as, for example, implementing HTTP services: high performance with a simple concurrency model.

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/7b5d5ee6-9dc5-4322-9682-21b5b6d0ec5f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "vert.x" group.

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/C92FCA35-4885-4AC5-ADD1-7AB0B3F18509%40julienviet.com.

[Darrin West]

For others coming to this conversation through Google...There are several benefits of Vert.x without relying on the built in event bus:

- You get the serialized scheduler. When remote events are turned into local vert.x events, these local events will be consumed by the verticles. And vert.x will manage that concurrency.

- If you run vert.x as a cluster, the system will restart verticles that have died. Perhaps you will rely on Kubernetes to do this for you, however.

- The built in data grid is still useful. If you don't use vert.x, you'll need to integrate to Hazelcast yourself.

Obviously, any of these and other features of vert.x can be implemented using other systems, or by yourself, manually. But why?

[Ronoel Júnior]

Hey,

Could you please show an example or reference about this item "- You get the serialized scheduler. When remote events are turned into local vert.x events, these local events will be consumed by the verticles. And vert.x will manage that concurrency."?

Thank you!

--

You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/6db4b096-0946-4bb1-9584-c3f8aff5eebc%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Ronoel Júnior

[Marcius Tan]

Hi sir, so could this be a relevant repository for the referred EventBus wrapping KafkaClient:
https://github.com/hubrick/vertx-kafka-service

I hope your respond.

Regards,

On Wednesday, March 21, 2018 at 4:43:58 PM UTC+7, Julien Viet wrote:

yes you would need to do that on your own.

perhaps one could create an EventBus interface wrapping the KafkaClient ?

To unsubscribe from this group and stop receiving emails from it, send an email to ve...@googlegroups.com.

[Konstantyn Smirnov]

My 5 cents

Recently I made a head to head comparison between VertX, Micronaut and Ratpack.

My application is comprised of a "core" project containing GORM domain models and a couple of utilities/resources, and 3 projects using the "core" for each aforementioned tech.

As soon as the application is rather small, no performance diffs can be measured, each app starts within 3 seconds.

Here I must mention, that EventBus was not used, so there was no bias of using VertX at all and I used vertx core / groovy / web combo.

My impressions

Vertx's web package gets the job done, but not too fancy compared to Micronaut or Ratpack as the later provide a higher abstraction level in terms of HTTP request processing (which is not really surprising).

Grails beats them all single-handedly in terms of abstraction.

For example to get the GET, POST parameters or path variables in a controller action, you simply grab them from `params` field which is injected to each controller class.

The killer argument for me to use VertX is really the inter-service communication over some fabric like EventBus. EB resolves a ton of problems, which would occur if the micro-services would communicate via HTTP with each other.

At the end of the day, it's not about figuring out what framework is better, but rather how can we use advantages of all of them together. In this regard, I made a very pleasant experience to integrate VertX as a service in a Grails app. This can be done with any other frameworks as well fairly easy.

[Vincent Free]

I went from spring boot applications to Vert.x for a few reasons. First is the performance and concurrency model. Second is the development model, although it takes some practice it's actually very pleasant to use with most operators aligning over modules. There are a lot of modules that you can use to build applications using most popular technologies.

Furthermore I'm building applications that mostly use kafka for persistent messaging because at the company I work for we need to meet regulations and keep all data to recover at a later point in time.

Our distributed system handles load of 100k rps and up using just vertx applications so the performance is quite good.

An other reason to consider vertx over something like spring could be that if you would want to create native applications in the future with vertx you can. Due to springs reflection heavy model it's far less easy to get this done using the framework.

For me this is important in the fear future for you it could just be a neat gimmick though but worth keeping in mind.

Eventbus is very nice to use but like in my case it's not required to work with message driven microservices.

The last thing I really like about working with vertx is the community which isn't as large as others but support is actually very good and quick.