Improved vertx-web, as Akka-Http

[aesteve]

Hi @codepitbull and thanks for all your amazing work on vertx-lang-scala.

Something I've been looking for years with Vert.x is :

• the ability to reduce noisy code : checking parameter types (if it's not an Integer, return http 400, etc.) automatically (e.g. Spring MVC)
• the ability to generate full Swagger (or else) documentation from the routing description
• having strongly typed information within RoutingContext like context.getParam("test") should be an Integer if I checked for it before
• adding methods "dynamically" (but compile-checked) to RoutingContext if needed (see : https://twitter.github.io/finatra/user-guide/http/filters.html#using-c-t-finagle-http-request-ctx for instance)

At the end of the day, I think Java won't allow such features. I tried a few implementations that mostly use reflection (thus no compile-time checking). I was looking for another way to do so.

I found the akka-http very interesting, and am pretty sure we could be able to build such a thing with Vert.x.
It extensively uses the magnet pattern (which is also very very interesting).

I wanted to see if you were interested in helping me building such a "DSL" kindof. That'd allow Vert.x scala users to work in a very very type safe environment, reducing the need to check parameters at runtime and returning errors manually, and also generating accurate documentation.

Let me know if you have some questions ! Thanks.

[pmlopes]

@aesteve Hold on with Swagger, we've just started with GSoC project in that area, we might have some heavy reactoring in vertx-web to easily expose the routes and their configs so swagger/raml/something else can generate their metadata.

[codepitbull]

@aesteve thank you for the kind words :)
As @pmlopes mentioned there is already a Swagger-thing going on.
Your other suggestions sound pretty cool. How about collecting some real API examples in this issue so we could do a little PoC?
I am currently working on streams for vertx-lang-scala and it might be a good place to test your ideas :)

[aesteve]

@pmlopes I thought the goal was to create routes from a swagger / raml description, not the other way around. But anyway, I'm rooting for a full refactor of vertx-web to improve it ! I know we're on the right track
@codepitbull here you go for an example. Scala would bring a lot onto the table. (the implementation is still very dirty for now, I have to work on this).

Thanks to you both ! We're gonna make it :)

[pmlopes]

Hi @aesteve, @codepitbull there is some confusion here, the gsoc project hasn't officially started but @slinkydeveloper is already working on it. What was announced recently about swagger is a different project with some overlapping goals it is not what we were planning for GSoC.

If there are questions I think it is best if we include Francesco so we can help him making a great project.

[slinkydeveloper]

Hi @aesteve, as you requested I slightly changed my project to add this features. Watch what i'm working on: HTTPRequestValidationHandler
I created a BaseValidationHandler class to allow validation for every parameter location with every validation type method. In particular:

• You can use included ParameterType with included validation methods
• You can add a custom ParameterType plugging your validation method https://github.com/slinkydeveloper/vertx-web/blob/designdriven/vertx-web/src/main/java/io/vertx/ext/web/validation/ParameterType.java
• You can plug inside validation flow a sync function to do some custom validation stuff

For now I haven't created a standard failure handler, but when the validation fail it returns inside the failure handler a ValidationException
In this class I can add later the code -> swagger generation, for example a routine inside BaseValidationHandler.validate() that generates the swagger and loads it inside a RoutingContext's parameter

[aesteve]

Hello @slinkydeveloper

Very nice to see what you're going on with.
Also nice to see our projects could converge at some point without pursuing the exact same need.
Let's clarify our goals so that we're sure we all don't duplicate stuff, and work effectively :)

At the end of the day, I think an alternative routing approach could use your validators to bring even more expressiveness to vertx-web's routing mechanism.

Correct me if I'm wrong but for now, your projects allow to plug "validators" to a (set of) route(s).
What I'm trying to achieve is a more functional oriented routing mechanism, that'd allow to declare routes in a descriptive manner, rather than in an "implementation" manner. And manipulate params in a safe way (like, if you registered an Integer validator for param "id" then you'll be able, all along the route declaration, to use id as an int).

You can see an example of that here.

Let me explain in details what's going on :
First you declare that the route expects id to be set and be of type integer.
Here, my "checking" implementation should (must) be replaced by your validator mechanism once it's released, it'd be really better.
From this line on, every function invoked (check etc.) will have an Integer as first parameter, that's exactly what's going on here. ::todoExists takes an Integer as parameter and returns a Future<Todo> which now becomes the route's "payload". So from this line on, every handler would have a Todo as "payload".
Next is this. Here again, my checking implementation should be replaced by your validator registration. Totally ! But keeping the interface as is.

So in my opinion both approaches are complementary. A functional router would make extensive use of your validation mechanism.

What do you think ? Let me know if things are unclear, or if you want me to stop working on this subject if you think it overlaps in some way with what you're investigating at the moment !

Thanks @slinkydeveloper !

EDIT : we can discuss this everywhere you find more suitable, no worries.

[aesteve]

People interested in this (a functional way to describe routes and endpoints) may be interested in Tapir which now supports Vert.x as a server backend.