why a database verticle?

[Jonathan Willis]

I've seen a few examples of creating applications in vertx where there is an http verticle and a database verticle:

The event bus allows the HTTP verticle to send a request to the database verticle that performs a SQL query, and responds back to the HTTP verticle - http://vertx.io/docs/guide-for-java-devs/ 

https://www.youtube.com/watch?v=3_CRKfs4Zzo&t=1174s also does the same thing where a database verticle is setup.

Why use a database verticle? Why not just have the http verticle receive the request and then whenever you need to go to the database switch schedulers (e.g. in rxjava switch to the io scheduler)?

Is there a performance benefit? Testability benefit? 

[Julien Viet]

both are acceptable solution.

For simplicity you can use a single verticle doing all operations.

If you want to encapsulate database operations and make them reusable from somewhere else or test them then you can make two verticles and go EventBus.

For performance, it is hard to speculate about the actual result as it depends on the application.

Collocating on same event loop reduce latency but increase IO operations on the same event loop, so your server might have some of its requests that don't need database calls to be delayed more because the database access would use some of its IO.

Also the database interactions latency will be impacted, so if you have a connection pool, then the connections will tend to stay out of the pool a little longer because it is sharing IO with the server and a connection pool can be a bottleneck in your application.

So well, very hard to speculate about performance without having a real test / benchmark and measure :-)

HTH

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/03be43a4-1946-4421-bf7a-4afd3388241f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jonathan Willis]

Hey Julien,

I like the idea of a DatabaseVerticle, but I'm a little lost on one point: How do you maintain database transactions across a verticle?

Here are a couple scenarios:
1. I want to do a get and a subsequent patch
2. I want to do multiple patches

If one of those fails I would like to do a rollback but how would I do this with an http verticle making requests across the event bus to a database verticle?

On Tuesday, July 16, 2019 at 10:20:30 AM UTC-6, Julien Viet wrote:

both are acceptable solution.

For simplicity you can use a single verticle doing all operations.

If you want to encapsulate database operations and make them reusable from somewhere else or test them then you can make two verticles and go EventBus.

For performance, it is hard to speculate about the actual result as it depends on the application.

Collocating on same event loop reduce latency but increase IO operations on the same event loop, so your server might have some of its requests that don't need database calls to be delayed more because the database access would use some of its IO.

Also the database interactions latency will be impacted, so if you have a connection pool, then the connections will tend to stay out of the pool a little longer because it is sharing IO with the server and a connection pool can be a bottleneck in your application.

So well, very hard to speculate about performance without having a real test / benchmark and measure :-)

HTH

Julien

On 16 Jul 2019, at 17:43, Jonathan Willis <quicksi...@gmail.com> wrote:

I've seen a few examples of creating applications in vertx where there is an http verticle and a database verticle:

The event bus allows the HTTP verticle to send a request to the database verticle that performs a SQL query, and responds back to the HTTP verticle - http://vertx.io/docs/guide-for-java-devs/ 

https://www.youtube.com/watch?v=3_CRKfs4Zzo&t=1174s also does the same thing where a database verticle is setup.

Why use a database verticle? Why not just have the http verticle receive the request and then whenever you need to go to the database switch schedulers (e.g. in rxjava switch to the io scheduler)?

Is there a performance benefit? Testability benefit? 

--
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 ve...@googlegroups.com.

[Julien Viet]

Hi,

I think you should encapsulate all the logic for a transaction inside each database verticle operation.

Instead you that would rather be a service verticle.

Julien

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/5b6651cc-4aca-47ca-bdc8-bfdd3092b740%40googlegroups.com.

[Trevor Young]

Hi Julien,

If you don't mind my intrusion, I'd like to ask a follow up question. It would seem like what you suggested could very easily lead to a rift in the business logic, where half of the business logic lives on the db verticle, and half lives on the verticle that calls the db verticle, with the split in the logic being defined by the technology and where a transaction might be needed as opposed to the split being defined by distinct groupings in the business logic itself. So while I like the idea of a db verticle, it seems like in practice it could lead to some fairly big compromises with perhaps limited benefits.

Am I missing something with this? In your experience how would this problem be handled? If this does end up being the case, why would you consider the benefits to be worth the trade offs? Is there perhaps any open source or example code that I could be pointed to which I could study to better understand how the db verticle works as part of a larger project?

Thank you for your time and any answers. I know that you're busy and don't want to take too much of your time, but a few pointers in the right direction would be much appreciated.  I'm very curious to understand how to make this work as part of a fully functional project.

Trevor

Julien

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

[Julien Viet]

Hi,

I wanted to express that the various database interactions would be done in verticle operations and I called this "database verticle" and instead I should have said "service verticle".

I did not say clearly that this would shift from a verticle that does plain DB operations to a verticle that instead expose a Service that encapsulates the full logic for a single service operation and actually the HTTP front is a gateway to this service.

That's a common pattern with Vert.x and it can easily be done using Vert.x Service Proxies.

HTH

Julien

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/082d358d-c83f-4c20-8046-3523722b51fd%40googlegroups.com.

[Trevor Young]

Alright, that makes a lot more sense. Thanks so much for the info.

On Friday, September 13, 2019 at 3:46:28 AM UTC-6, Julien Viet wrote:
> Hi,
>
>

> To unsubscribe from this group and stop receiving emails from it, send an email to ve...@googlegroups.com.
>
> To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/082d358d-c83f-4c20-8046-3523722b51fd%40googlegroups.com.

[lukjel]

Hi.

It is a very common problem. In a simple example there is no problem but imagine you use 3 different DB (Postgres, Mongo, Redis) and also some external REST calls... Then transactions became very problematic.

I recommend you to check pattern SAGA - we use it very often in our solution. Of course - it means longer processing time but because of reactive style, it makes no difference for end-user. I mean: for end-user, it is no difference between 450ms or 537ms :D

In our system, we decided to have MANY simple verticles. Mostly because we want to make it simple to test. And this is very simple to test one verticle (and mocking all others if needed).

We even created a whole library which makes it very easy to create handlers and test them.

And just BTW: I'm really a big fan of Kotlin. We discovered it during our development with Vert.X. Using coroutines really magically solves a problem of call-backs :D

Regards

Lukasz Zeligowski