Routing handling with filters

[maiph]

Hello there 😃
Found it while looking for open source projects to contribute to and this is something I was interested in and that I could learn from.

I would like to know what was the design decision on the request routing implementation.
It seems like you register a ServletFilter to the ServletContextHandler and call the route callback inside the doFilter.
https://github.com/hexagonkt/hexagon/blob/59d77521d41c507fa7b179c39984b74c058b8c5e/http_server_servlet/src/main/kotlin/ServletFilter.kt#L143
and then
https://github.com/hexagonkt/hexagon/blob/59d77521d41c507fa7b179c39984b74c058b8c5e/http_server_servlet/src/main/kotlin/ServletFilter.kt#L98

What I noticed is that you are not following the expected behaviour of the Filter behaviour by not calling the doFilter of the chain.

Just wanted to understand if this was done for a specific reason or just as a "cost cut" measure and take advantage of how the servlet context handler handles requests.
I also think there is something already in jetty that does some kind of routing based on the request path.

Loving the project and learning a lot from it ❤️

[jaguililla]

Hello and sorry for the late reply,

Did you meant? why do I check routes inside a single standard Servlet filter instead registering one Filter (or Servlet) for each route? (Just correct me if I understood it wrong)

Taking the previous assumption: the main reason to do that is that the URL pattern used by Filters and Servlets is less flexible than the patterns used in Hexagon (i.e.: they only support a single wildcard). So you cannot make a one to one mapping directly.

You can check the Servlet Spec (section 12.2) for the details.

I could have used a "default servlet" instead a filter catching all request though. That could be another option and I would have to consider pros and cons... however, now I'm focused on completing the feature set and that could be a future improvement.

I don't call the next filter in the chain as I expected the Hexagon router to be the only handler for a web application (I prefer not to test the scenarios in which a single WAR can have Hexagon routers and also standard Filters/Servlets).

Please, if something I wrote is wrong or not accurate. Just tell me! I'd love to know. The same if you have any kind of improvement proposal :)

Lastly, thank you for your support, and for your feedback, It would be great if you want to share any other details that you are curious about, or think that may be improved. Thanks!!!

[maiph]

Later I saw that the servlet path definition is not very flexible and understand a bit more about it.

Also took a look at the docs from Jetty and saw that they don't event recommend using servlets if we can't take any advantage from them as they will only bring an unnecessary overhead. What they recommend is that the request handling is all done with Handlers. The idea I got from that would be to have a RouteHandler that would see what route the request is supposed to be sent and call the before, callback, and after for the route.
This approach allows a better separation of concernes (with something like: BeforeRouteHandler, RouteCallbackHandler, AfterRouteHandler) and allows to chain all the Handlers in succession or wrapping other handlers.

[jaguililla]

You are right, using Jetty at a lower level improves the performance over using Servlets.

The reason behind this decision is to take advantage of the Servlet implementation made for Web applications (WAR files) to cut development time.

In the future, the best option would be to provide another Adapter using Jetty "low" level library (or other Adapter for, let's say undertow.io). And take advantage of the Port/Adapter architecture.

That's the goal, but before providing more adapters, the next milestone is to cover minimal functionality (parts missing are Auth and WebSockets).

Thanks again for your thoughts!