Differences

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

Link to this comparison view

irc:1485903600 [2017/05/27 13:44] (current)
Line 1: Line 1:
 +[03:28:06] <​KeplerOil>​ Apparently, saying good things about Vert.x in a Pivotal post can be outrageous. Added some comments about my recent experience comparing Vert.x with Ratpack and NodeJS and, the comment was removed. Maybe that's teh reason why Vertx was not included in their list in the first place: https://​spring.io/​blog/​2016/​06/​07/​notes-on-reactive-programming-pa
 +
 +[03:28:06] <​KeplerOil>​ rt-i-the-reactive-landscape
 +
 +[09:12:12] <​aesteve>​ hi everyone !
 +
 +[09:13:55] <​aesteve>​ pmlopes: temporal_ just let me know if you're available at some point, I'd like to discuss an "open topic" re. vertx-web, not very easy to discuss in the Google Group
 +
 +[09:14:07] <​temporal_>​ hi aesteve
 +
 +[09:14:24] <​temporal_>​ I'm there, but pmlopes is definitely the vertx-web master :-)
 +
 +[09:14:36] <​temporal_>​ aesteve have you tried the new groovy support in vertx 3.4 snapshot ?
 +
 +[09:18:42] <​pmlopes>​ @aesteve i'm also here
 +
 +[09:19:32] <​pmlopes>​ are you refering to your post of today?
 +
 +[09:20:07] <​aesteve>​ temporal_: not yet (Groovy)
 +
 +[09:20:17] <​aesteve>​ I'm into Kotlin for my latest Vert.x projects
 +
 +[09:20:25] <​aesteve>​ yes pmlopes definitely
 +
 +[09:20:35] <​aesteve>​ did you get a chance to look at rapidoid
 +
 +[09:20:45] <​temporal_>​ aesteve you might want to try kotlin support in 3.4
 +
 +[09:20:48] <​pmlopes>​ I'm going over it and I see it probably as a good summer of code project
 +
 +[09:21:13] <​aesteve>​ I used it for a very small project (for JPA support originally) and the "any function can be an handler"​ is so neat !
 +
 +[09:22:19] <​aesteve>​ and I kinda like the idea that by reading the route declaration you can almost tell what's going on :
 +
 +[09:22:45] <​temporal_>​ aesteve are you going to devoxx this year ?
 +
 +[09:23:15] <​aesteve>​ checkSecurty.then(checkUserLanguage).then(findUser).withBody(validateBody).then(saveItToMongo).finally(marshallInJson)
 +
 +[09:23:42] <​aesteve>​ I registered a few days ago, I think I'm on the waiting list
 +
 +[09:23:56] <​aesteve>​ hope I can make it to Devoxx, definitely
 +
 +[09:25:09] <​temporal_>​ aesteve I hope to see you there !
 +
 +[09:25:50] <​pmlopes>​ the rapidoid api is quite concise looks like imho but if we're to build something similar this would be a huge api break or a totally new API...
 +
 +[09:26:03] <​pmlopes>​ not saying that i'm against (which i'm not)
 +
 +[09:26:25] <​aesteve>​ I think it should even be a separated project
 +
 +[09:26:32] <​aesteve>​ not to break any API
 +
 +[09:26:45] <​pmlopes>​ but we're aiming to get 5 start RX support for vert.x and rapidoid seems to be more Promise-ish like API
 +
 +[09:27:12] <​pmlopes>​ so i see here a conflic of interests wdyt temporal_?
 +
 +[09:27:16] <​aesteve>​ and maybe Java / Kotlin / Groovy specific (because annotation / type reflection could? be involved)
 +
 +[09:27:28] <​temporal_>​ what is rapidoi ?
 +
 +[09:28:01] <​pmlopes>​ it's other framework that is ranked high on techempower
 +
 +[09:28:29] <​pmlopes>​ that aesteve showed on his email, here's the snippet: https://​github.com/​aesteve/​rapidoid-todobackend-hibernate/​blob/​master/​src/​main/​java/​com/​github/​aesteve/​rapidoid/​todobackend/​Main.java#​L35
 +
 +[09:28:34] <​temporal_>​ based on java ?
 +
 +[09:28:41] <​aesteve>​ the approach is quite the opposite of Vert.x btw, sync by default, async if you ask for it
 +
 +[09:28:46] <​temporal_>​ ok
 +
 +[09:30:20] <​aesteve>​ the interesting thing in rapidoid'​s API is the "Any lambda can be a handler, depending on the type & annotations of the parameter, it'll be automatically resolved"​
 +
 +[09:30:38] <​aesteve>​ the part that they'​re missing is a fluent lambda / route composition API though
 +
 +[09:30:43] <​aesteve>​ (imo)
 +
 +[09:31:39] <​aesteve>​ but anyway pmlopes I hope this can be submitted to Summer of Code, definitely
 +
 +[09:32:15] <​temporal_>​ looking at it
 +
 +[09:32:48] <​temporal_>​ rapidoid seems to have its own networking layer
 +
 +[09:32:50] <​temporal_>​ that's interesting
 +
 +[09:32:56] <​temporal_>​ probably why it ranks high
 +
 +[09:32:59] <​temporal_>​ (if it does)
 +
 +[09:33:27] <​pmlopes>​ well, if we can rewrite it more like a project definition definitely we can listed on the "​project ideas" for 2017
 +
 +[09:35:14] <​temporal_>​ can't we have something like an alternative route builder for vertx web ?
 +
 +[09:37:03] <​aesteve>​ that's the second step temporal_ indeed a fluent builder API
 +
 +[09:37:26] <​aesteve>​ but I think the first step is to be able to "​resolve lambda parameters"​ automagically
 +
 +[09:37:48] <​aesteve>​ then the second one is to deal with Future in vertx-web
 +
 +[09:38:11] <​temporal_>​ what means resolve lambda params ?
 +
 +[09:38:29] <​aesteve>​ see the code line I highlighted in my example ?
 +
 +[09:39:22] <​aesteve>​ Req req is automatically mapped onto "​context.request()"​ in our case, "​String id" is automatically the captured route param which name is "​id",​ etc.
 +
 +[09:41:27] <​aesteve>​ this will help in the "​declarative handler"​ approach. If it's a lambda that takes (HttpServerRequest req, String id, @Body Todo todo) I will know, only by reading the method signature that the function doesn'​t do anything with the http response, that it reads the request body, and that it captures a parameter named "​id"​
 +
 +[09:41:48] <​aesteve>​ no need to read the implementation
 +
 +[09:42:32] <​aesteve>​ and then, we'll just have to create a nice "​handler composition"​ API to "​pipe"​ handlers alltogether
 +
 +[09:43:09] <​temporal_>​ I think the problem with java lamba is that you canno retain them
 +
 +[09:44:44] <​aesteve>​ don't know how rapidoid did their magic trick, I think javassist might be involved at some point
 +
 +[09:54:38] <​pmlopes>​ aesteve could you re-write your post but more in a project proposal style, e.g.: what is the goal, what should be achieved and indentify a couple of milestones and we can add it to the GSoC ideas list for 2017
 +
 +[10:04:19] <​aesteve>​ ok
 +
 +[10:04:32] <​aesteve>​ in a separate thread then ?
 +
 +[10:19:38] <​pmlopes>​ it can be the same, i'll reply that this is a good idea for GSoC you can add the proposal and we'll start curating the 2017 page
 +
 +[10:20:20] <​aesteve>​ ok writing it atm
 +
 +[10:24:07] <​temporal_>​ aesteve would you mind to look at
 +
 +[10:24:21] <​temporal_>​ https://​github.com/​vert-x3/​vertx-kotlin-common
 +
 +[10:24:26] <​temporal_>​ and tell me what you think of it ?
 +
 +[10:24:33] <​temporal_>​ it's DSL for vertx json
 +
 +[10:25:40] <​aesteve>​ finishing writing the proposal
 +
 +[10:25:42] <​aesteve>​ then looking at it
 +
 +[10:25:47] <​temporal_>​ thanks
 +
 +[10:26:30] *** ChanServ sets mode: +o purplefox
 +
 +[10:44:30] <​aesteve>​ mmh actually pmlopes I think there'​s a very very simple way to get started, I don't understand how I didn't see that before
 +
 +[10:45:06] <​aesteve>​ We simply have to write (and then automate by code generation) that :
 +
 +[10:45:18] <​aesteve>​ https://​thepasteb.in/​p/​BghPpkvWE9PUY
 +
 +[10:45:43] <​aesteve>​ wdyt ?
 +
 +[10:52:10] <​pmlopes>​ still code generation is a project on its own, i think the tricky part here is that vertx-web router is not a single class so you can get everything together, you will need to link, router, route, and handlers...
 +
 +[10:54:56] <​aesteve>​ not sure I understand, what you mean is we'd need to create a wrapper around Router ?
 +
 +[10:54:58] <​temporal_>​ I think building routes in vertx-web is an hot topic
 +
 +[10:55:00] <​temporal_>​ :-)
 +
 +[10:55:23] <​aesteve>​ https://​thepasteb.in/​p/​LghNygL9AoYsZ
 +
 +[10:55:39] <​aesteve>​ that's the kind of stuff that would save us hours
 +
 +[10:56:37] <​aesteve>​ maybe not hours, but that'd allow us to express our routes in a very elegant way
 +
 +[14:01:15] <​aesteve>​ pmlopes: https://​groups.google.com/​forum/#​!topic/​vertx/​01tCUjTm01s
 +
 +[14:01:26] <​aesteve>​ feel free to comment / move / tell me what's wrong
 +
 +[15:11:07] <​temporal_>​ aesteve so I talked with Norman about rapidoid
 +
 +[15:11:33] <​temporal_>​ and he said that they do an active poll on NIO select()
 +
 +[15:11:37] <​temporal_>​ which makes better performance
 +
 +[15:11:45] <​temporal_>​ but uses a lot of CPU
 +
 +[15:11:54] <​temporal_>​ "busy spin on selector"​ :-)
 +
 +[15:12:07] <​temporal_>​ and actually the same can be achieved with Netty
 +
 +[15:12:17] <​temporal_>​ so perhaps for techempower we should have a magic secret sauce that uses it :-)
 +
 +[16:57:19] <​aesteve>​ temporal_: nice !
 +
 +[16:58:03] <​aesteve>​ actually I used for its simplicity to deal with JPA, it was a very simple use case where the POJOs where already mapped & I had to deal with an SQL db.
 +
 +[16:58:38] <​aesteve>​ it allowed me to create a REST API over JPA in a matter of minutes, for a simple proof of concept
 +
 +[17:00:02] <​temporal_>​ yay
 +
 +[18:33:33] <​BadApe>​ hello, reading the blog article about AMQP, i am confused to what service the bridge is connecting to
 +
 +[20:03:42] <​chermah>​ hi guys, is there someone to help about a little architecture issue :) ?
 +
 +[20:50:28] *** ChanServ sets mode: +o temporalfox
 +
 +[23:51:47] *** ChanServ sets mode: +o temporalfox