vert-x3 / vertx-lang-kotlin

Vert.x for Kotlin
Apache License 2.0
296 stars 68 forks source link

Vert.x Web DSL routing #91

Open vietj opened 6 years ago

vietj commented 6 years ago

The new Kotlin stack integration in 3.6 allows to have custom Kotlin DSL's.

It would be great to have a Kotlin DSL for Vert.x Web that makes templating more Kotlin-ish.

gmariotti commented 6 years ago

do you have an example on how you think it should look like? Also, should it be part of the vertx-lang-kotlin module, autogenerate or a completely new module?

vietj commented 6 years ago

I am not a Kotlin expert and I leave that up to the community to come up with the best API that makes sense.

It should be custom code part of vertx-lang-kotlin without generation, just plain Kotlin simple integration code that makes Vert.x applications more Kotlin-ish.

gmariotti commented 6 years ago

cool, I'm curious to try it, even just to give inspiration to others

AlexeySoshin commented 5 years ago

I did something similar for one of my own Vert.x+Kotlin projects. Will try to come up with a proposal in the next week or two.

vietj commented 5 years ago

it would be great to involve also the Kotlin Vert.x slack channel for feedback :-)

JohannesLichtenberger commented 5 years ago

A proper coroutine handler would be great, supporting suspending functions. Workaround currently is to write an extension function. Furthermore the route definitions could be as in Ktor:

route("a") { // matches first segment with the value "a"
  route("b") { // matches second segment with the value "b"
     get {…} // matches GET verb, and installs a handler 
     post {…} // matches POST verb, and installs a handler
  }
}
oripwk commented 5 years ago

@JohannesLichtenberger +1.

I cannot stress enough the importance of coroutine-enabled io.vertx.ext.web.Route#handler methods. The current workaround of manually using an extension function is not clean.

gmariotti commented 5 years ago

@JohannesLichtenberger this is quite an interesting problem. Since 0.26.0, you need an instance of CoroutineScope to be able to start a coroutine, however, having coroutineHandler as an extension on Route, would require the scope to be passed as a parameter. An option would be to have a RouterK/RouteK that behaves exactly like the Router/Route except that it implements CoroutineScope, similar to what we do in CoroutineVerticle, and that expose a Route.coroutineHandler extension. What do you think?

JohannesLichtenberger commented 5 years ago

Currently I'm using this extension function:

private fun Route.coroutineHandler(fn: suspend (RoutingContext) -> Unit): Route {
        return handler { ctx ->
            launch(ctx.vertx().dispatcher()) {
                try {
                    fn(ctx)
                } catch (e: Exception) {
                    ctx.fail(e)
                }
            }
        }
}

So, this doesn't work anymore? But sounds great, implementing CoroutineScope.

gmariotti commented 5 years ago

It still works in 3.6 as long as the extension is defined inside of a CoroutineVerticle, where the scope of the verticle is used. If you try to move it out, you'll see that the code doesn't compile anymore because launch is now an extension function of CoroutineScope

Tim-Britton commented 5 years ago

Hello All,

I am currently working on a dsl for our internal use and I wanted to show it off a bit determine whether it would be something good to give back to the the vertx project.

fun main(): Unit {
    val vertx: Vertx = Vertx.vertx();

    server(vertx) {

        router("/v1") {
            //Create a route at localhost:8080/v1/hello
            getAwait("hello") {
                //this is a coroutine handler

                delay(500)
                it.response().end(jsonObjectOf("hello" to "world").toBuffer())
            }

        }

    }.listen(8080)
}

Its lightly inspired based on the dsl for koin which we use for dependency injection.

If interested I can start looking at getting the dsl code together for contribution.

vietj commented 5 years ago

that would be great @Tim-Britton

JohannesLichtenberger commented 5 years ago

Could we get rid of the "Await" method postfix? :-) I know it's otherwise for the Vert.x calls auto generated, but then it would be in-line with the Ktor routes, I think.

vietj commented 5 years ago

I think if we get rid of it, it would create ambiguities sometimes.

On 28 Aug 2019, at 13:08, Johannes Lichtenberger notifications@github.com wrote:

Could we get rid of the "Await" method postfix? :-) I know it's otherwise for the Vert.x calls auto generated, but then it would be in-line with the Ktor routes, I think.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/vert-x3/vertx-lang-kotlin/issues/91?email_source=notifications&email_token=AABXDCQIR2E3EI3MXRCWOB3QGZMCHA5CNFSM4GDB4JB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5KX4UY#issuecomment-525696595, or mute the thread https://github.com/notifications/unsubscribe-auth/AABXDCQA3FXJMNDL6B33LR3QGZMCHANCNFSM4GDB4JBQ.

JohannesLichtenberger commented 5 years ago

Ah okay..., but looks great :-)

vietj commented 5 years ago

we also discussed that with vertx 4, the new Future API should improve coroutines API

Tim-Britton commented 5 years ago

@JohannesLichtenberger I use the await postfix to inform the user that they are getting a coroutine context rather than a standard handler context.

@vietj we'll start moving in that direction then! The implementation details require delegation similar to what is used with the rx versions of the vertx classes.

I'll try to block out some time to get this started!