RFC: support for multi-endpoint HTTP handler Lambda functions about powertools-lambda-java HOT 9 OPEN

Sure, that makes sense. I'm in no rush to include this - happy to contribute whenever it makes the most sense. It probably offers this RFC a chance to breathe a little bit and gives us time to get the right kind of feedback.

from powertools-lambda-java.

Morning @dnnrly ! Thanks heaps for this - it is clear you have spent time thinking about this. There is prior art here too - powertools for python supports something similar .

Full disclosure - we are focusing at the moment on getting V2 #1522 into a good state, targeting H1 this year. This is certainly something we'd be interested in in the future, though, and would have a natural home in V2, as we're reluctant to add net new features to V1.

from powertools-lambda-java.

Thank you very much for your contribution here. Let's sleep on this a bit. v2 is around the corner, then it makes sense to have another look at it.

from powertools-lambda-java.

absolutely - it would be great to get other views on this pop up in the coming weeks !

from powertools-lambda-java.

Thank you @dnnrly for this very well detailed RFC. As Scott mentioned, there is an equivalent in python, and this is a feature we were thinking about when we looked at the feature parity with Python. To be transparent, it was definitely not our number one priority as it's a complex one and also very competitive (vs Spring & other fwks). But I like the idea to have something lighter and the first thoughts you put in this RFC.

About this, can we have pre-filters and post-filters (for example to add CORS headers or other data transformation) ?

Also, it would be great to see what has been done in Python, not to replicate but to get inspiration and maybe complete the feature scope.

from powertools-lambda-java.

The filters in this implementation aren't pre- or post-, you can write the code around the call to next(...) however it makes sense. The internal implementation we have includes a library of filters that we can use in our routers. Some do validation, others logging, and even some mutate the request before it gets to the handler. A lot of the behaviour implemented in the Python version could easily be implemented as filters that you just add to your chain.

As for the comparison with other frameworks, our experience with Spring and JaxRS performance was very poor when we tried it. The cold-start times were quite high - beyond our budget for the APIs that we have implemented. It's not really meant to compete with those technologies, just give you options if you want to host your API using lambdas.

I totally understand that it's not a priority. I raised this RFC as we have had a stable implementation for a couple of years now and it has become an important part of how we deliver our APIs and it seemed a shame not to share our experience with the wider development community. 😄

from powertools-lambda-java.

Thinking out loud @dnnrly - what would be the downside of providing a powertools implementation of JAX-RS? I don't think it should be inherently slow in and of itself (see e.g. Quarkus). On the other hand from my own perspective I quite like this style of API modelling you've done here - it feels more "modern" to me, and lines up with the way we're using builder-style interfaces in V2 e.g.

from powertools-lambda-java.

@scottgerring remember our conversation on jax-rs: #1103

from powertools-lambda-java.

@scottgerring remember our conversation on jax-rs: #1103

In retrospect I think my suggestion to use quarkus or spring-boot is a bit heavy-handed. I see the value in providing something lightweight like both yourself and @dnnrly are suggesting! I am not sure about the performance impact of it; it feels like quarkus with resteasy-reactive mitigates this somehow (compile time weaving ? 🤷 ).

Ultimately I am hoping to prompt new discussion on options !

from powertools-lambda-java.