search

mkotsur / aws-lambda-scala

Writing AWS Lambdas in Scala
MIT License
145 stars 21 forks source link

Proxy Method to require a different return type on error (not a throwable) #12

Open rmmeans opened 6 years ago

rmmeans commented 6 years ago

I'm curious to hear your take on this.

So far we love your library, and our primary use case is using it with API Gateway and SAM to deploy serverless Scala based API's. Our problem is that we are wanting to use the Lambda Proxy invocation as it is the easiest to use from an API Gateway perspective. This works great with your library on the happy path for the Lambda.Proxy impl - but on the failure path, I need to be able to grab a hold of that failure and have full control of the ProxyResponse that is returned. When using the Proxy return style, I do not want Throwables as the Lambda payload that is returned would end up going all the way as-is through the API gateway and back to the caller. This would end up being a different type than ProxyResponse[O] as the happy path return type can't be generated in the error scenario. I think what I would want for the the output on error is a type of a ProxyResponse[E] (e for error type), or something similar. Thoughts?

mkotsur commented 6 years ago

Hi @rmmeans. Apologies for late reaction. I think, what you want makes total sense. As you might have noticed, the library is built mostly around the happy path and there are neither facilities nor documentation regarding error handling. I would be happy to change that now that someone wants it.

I’ve been looking into allowing to return different types (e.g. Future[O] instead of O) from the handler using implicit conversions underneath.

While not exactly the same, this mechanism could open the doors for the error handling facilities you want. Let me do some hacking during this weekend and I’ll come up with some proposal early next week.

rmmeans commented 6 years ago

No worries, sounds good!

We have actually been hacking on our variation of this problem from scratch as well using as little of libraries as we can (e.g. no Circe automatic derivation - everything is done with custom encoders / decoders in the lib, etc.) so we can keep the overall jar size down for the library itself... users could still use the automatic for their types if they wish to pull in more dependencies.

I hope to open source what we've done next week sometime with a beta release. Our initial scope is very narrow - only focusing on API Gateway Proxied responses and building a nice type system for a developer to deal with that setup.

rmmeans commented 6 years ago

We have open sourced our take on this problem. https://github.com/lifeway/scala-aws-lambda-handler I gave you credit for the inspiration in the README.

We'll be getting the first release of it out to maven central hopefully tomorrow.

mkotsur commented 6 years ago

Hey @rmmeans. Nice, good luck with that. For me it's still an interesting challenge to support both: proxy and plain lambdas in the same library.

I'll take some more time before making the change: considering a couple different alternatives how to implement it, and the time I can spend on this project is pretty limited... Will let you know when it's done, of course :-)