Differences

This shows you the differences between two versions of the page.

Link to this comparison view

irc:1453676400 [2017/05/27 13:44] (current)
Line 1: Line 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>​ https://​github.com/​aesteve/​vertx-markdown-service 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()"?​