This version (2017/05/27 13:44) is a draft.
Approvals: 0/1

[09:39:32] *** ChanServ sets mode: +o purplefox

[11:31:22] <BadApe> i am trying to understand how best to structure my app, i thought i could create a verticle to be the database service, so i could deploy a number of these to service the rest api controllers, but it seems clumsy to send db results over the eventbus

[11:33:42] <qsys> why would sending the results over the eb be clumsy?

[11:38:02] <qsys> I think it's very common to have a webserver/sockJSServer which just delegates the work to several other verticles. Makes it very easy to just drop in new functionality: add another verticle, job done (at least, using a sockJSServer). I hardy ever touch the 'web server/sockJS server'.

[11:38:49] <qsys> … well, sockjs server, I mean, sockjs handler

[12:08:06] <BadApe> qsys, the reason was i am sending SQL and params over the eventbus, seems a bit weird, but maybe that is something i have to get used to

[12:10:42] <qsys> aah… well, depends on your design, of course. I'm using the (clustered) JDBC Client. I think this one embeds the connection into each verticle. I don't send SQL over the eventbus, just messages, like: 'give me all persons' and some parameters. My verticles translate this into sql.

[12:12:01] <qsys> this way, I can send messages from the client, without worrying about sql over websockets, like {'action':'persons', 'params':{restrict:'age > 18'}} or something.

[12:13:26] <qsys> the 'database verticles' can easily be changed, for example, if one doesn't use sql (or another dialect), it's the responsability of the verticle to translate the message into the 'right' SQL statement.

[12:14:02] <qsys> same message sent, other sql (or whatever the database 'talks') generated

[12:35:07] <BadApe> maybe i should change the way i am doing this

[12:35:35] <BadApe> i can see i am going to have a huge db class

[12:35:47] <BadApe> can i send ResultSet over the eventbus?

[13:00:12] <qsys> sure, you can, or you translate the resultset into something not-sql-related, like a json array, which would make more sense

[13:53:36] <BadApe> qsys, thanks! i've got a really small code base now

[13:54:02] <BadApe> i think a blog post on how to structure larger projects would be nice :D

[13:54:24] <qsys> :p

[13:56:49] <BadApe> seriously i've learned a lot from the blog posts, they are of a very high quality

[14:20:34] <BadApe> hmm, seems that i had overlooked updating a record from a bit of json

[14:28:34] <aesteve> hello everyone :)

[14:28:49] <aesteve> hello BadApe, I saw your question in the IRC logs ;)

[14:29:36] <BadApe> i think i've solved my problem

[14:29:49] <aesteve> an approach you could consider, would be creating a service to query the database, with “functional oriented” primitives like : “getAllUsers”, “getUsersByNameMatching(String name)”

[14:30:06] <BadApe> aesteve, that is pretty much what i've done now

[14:30:10] <aesteve> and then use vertx-service-proxy to use this service over the eventbus

[14:30:28] <aesteve> without even implementing a single line of code

[14:31:42] <BadApe> oh hmm didn't know about the service-proxy

[14:31:53] <aesteve> for example, if the signature of your interface is : getAllUsers(AsyncResult<List<User» result), all you have to do is :

[14:32:21] <aesteve> 1/ tell vertx how User should be marshalled/unmarshalled (using a specific interface)

[14:32:46] <aesteve> 2/ Annotate your interface (the DAO-one) with Proxy-related annotations

[14:32:52] <aesteve> and you're good to go

[14:34:28] <aesteve> can help

[14:34:40] <aesteve> (especially if you're using Gradle)

[14:35:17] <BadApe> ok so it reduces the amout of event bus consumes i have

[14:36:26] <aesteve> yes, something else to note, too : if you decide your service should no longer be used through the event bus but locally, you have a minimum amount of code to change

[14:37:08] <aesteve> the idea between service-proxies is : no matter if it's invoked through the event bus or locally, you call the same methods

[14:37:13] <aesteve> behind*

[14:40:09] <BadApe> i am a little lost on the value of this so in my ignorance i created something like private void abc{eventBus.<JsonObject>consumer(“db.service.updateby”, message → { …

[14:41:01] <aesteve> you'll recreate service-proxy ;)

[14:41:21] <aesteve> (I did that too on my first project)

[14:42:53] <BadApe> but as i only use it once, and not many times

[14:43:49] <aesteve> I'd need some real code to understand :\

[14:44:19] <BadApe> so i am writing a rest api just to do some crud operations

[14:45:11] <BadApe> say i have an angularjs data grid, i create eventBus.<JsonObject>consumer(“db.service.pager”, message → {})

[14:46:10] <BadApe> if i use your service proxy it suggests i reimplement the same functionality over and over for each table or data structure

[14:46:43] <BadApe> so all i did was to do something like sql = String.format(“SELECT * FROM %s ORDER BY %s %s OFFSET ? LIMIT ?;”,

[14:46:43] <BadApe> table, column, directionSql);

[14:46:58] <BadApe> sending over the table, column and direction

[14:49:55] <aesteve> why do you need the eventbus ?

[14:50:05] <aesteve> not simply jdbc client ?

[15:01:43] <BadApe> so your want me to create an instance of this object many times?

[15:02:37] <BadApe> i have many services, i create 1 verticle, i deploy it with x number of instances, now different parts of my app can get data

[15:03:07] <BadApe> i would also have to pass config down the chain to the jdbc client

[15:11:58] <aesteve> I “want” nothing… I'm here to help :\

[15:24:17] <BadApe> aesteve, sorry didn't mean that to sound aggressive

[15:25:12] <aesteve> just be careful that using the event-bus locally introduces unnecessary overhead (serialization / deserialization)

[15:25:46] <aesteve> where you could just use the JDBC client everywhere you need it, even though it's “painful” to instanciate it everywhere you need it.

[15:26:39] <BadApe> it seemed to be a huge advantage to be able to use the eventbus to communicate with data services

[15:27:20] <BadApe> so i can deploy a rest service and a tcp service, and both can get data

[15:27:35] <aesteve> I'm not an expert in that domain. I'm using DAO with service proxies and it works kinda well

[15:27:36] <BadApe> and i only have to deploy 1 data service in the cluster

[15:28:12] <aesteve> there it's interesting, if a cluster is involved

[15:28:20] <aesteve> my point was “locally” ;)

[15:28:36] <BadApe> yes i can see how it wouldn't be such a smart idea

[15:29:32] <aesteve> but no matter what, discussing architecture without knowing exactly what your application is doing is abit pointless

[15:29:51] <aesteve> just be aware of the tools you can use : service-proxy is one of them

[15:30:00] <aesteve> now, it's up to you :)

[15:30:07] <BadApe> i thought there might have been a methodology that is best to follow

[15:30:34] <aesteve> I don't think so, applications are really different

[15:30:37] <BadApe> thanks for your help, i didn't know about service proxies

[15:30:59] <aesteve> and the best thing about vert.x is that it doesn't force you in a way

[15:31:17] <aesteve> np, hope you can find what suits your needs perfectly

[15:31:26] <BadApe> i think i have what will work for now

[15:31:34] <BadApe> right now i just want to get some data :D

[15:31:43] <BadApe> come here data! damn it

[16:42:01] <BadApe> is it right that if i run an DELETE FROM i will get an error message of No results were returned by the query. with the result saying failed?

[16:44:15] <qsys> probably not… are you using vertx JDBC client or sql common? what 's your code?

[16:45:17] <BadApe> ah something else that confused me, i've probably done something stupid as i thought they were the same thing

[16:45:39] <qsys> :)

[16:46:12] <BadApe> read the docs they look to be the same thing

[16:46:18] <BadApe> reading

[17:16:31] <diega> hi!, is the only way to get the byte[] from a Groovy Buffer to access its delegate as “buffer.getDelegate().getBytes()”?