async support

[srijs]

Given that the runtime is built on top of tokio, I think it would be useful to be able to provide async handler functions.

Happy to contribute this if there is interest from your side!

EDIT: Support for tower via the tower-service crate could also be interesting.

[davidbarsky]

Given that the runtime is built on top of tokio, I think it would be useful to be able to provide async handler functions.
EDIT: Support for tower via the tower-service crate could also be interesting.

That's the approach I was considering; I'd love to rewrite a big portion of this library using Tower. The concern I had—and I spoke to Carl Lerche about this earlier today—is that I'd like to have more of Tower (retry, balance, etc) on Crates.io before we commit to using Tower. The other concern I had is that Hyper's service is not the same as Tower's service, and I'm not sure of how to best resolve until everything is moved over in one big shift.

Happy to contribute this if there is interest from your side!

We'd be very happy to accept contributions, especially if this isn't too much effort on your end!

[sapessi]

To add a little context here @srijs, we did not prioritize async handlers because the Lambda service itself enforces one event per environment at a time.

[softprops]

I'd to see this continue slim as it can be. Is tower slimmer than hyper in some way. I'd like to get more familiar what is gained by the extra dependencies. My understanding is the provided is a long polling based runtime, you only handle one task at a time and that lambda's scaling model was to spin up more instances when that's not sufficient. If that's correct I'm not sure what would be gained from the async interface.

[davidbarsky]

Is tower slimmer than hyper in some way.

Not necessarily, but we've run into bugs (prior to release) that could have been prevented if we used off-the-shelf tools provided by Tower. Additionally, Hyper currently has a Service trait that's based off Tower's Service trait, but isn't mutually interchangeable with Tower's service trait. Defining the runtime in terms of Tower allows us to use Tower's crates that provide retries, mocks, and timeout features. Additionally, it'll make it easier for customers to define their handler in terms of a Tower service, allowing them to leverage a vast and robust middleware ecosystem that provides instrumentation tooling like the upcoming tokio-trace. Given that using serverless technologies like AWS Lambda make the use of instrumentation tooling even more critical, we'd like to provide hooks to customers that make it easy for them to do the right thing.

My understanding is the provided is a long polling based runtime, you only handle one task at a time.

Yes, that is correct—Lambda currently works like that.

If that's correct I'm not sure what would be gained from the async interface.

Nothing directly, performance-wise, but we'd like to build on Rust's async tooling so that we're not re-implementing a bunch of stuff and allow our customers to do the same.

[srijs]

Additionally, in my mind there's two things that I'd like to get out of an async API:

• Ergonomics: Most lambda code I write ends up doing outbound network requests (e.g. to other AWS APIs), and this code is async. Being able to slot in a function returning a future directly into the lambda! macro, instead of having to write wrapper functions, would be super convenient.

• Cancellation: The golang runtime has this useful feature where the context.Context is cancelled once the lambda exceeds its deadline. Given that futures in Rust have cancellation built-in, it would be super cool if this just worked out of the box.

I haven't had time to look into it this weekend, but experimenting with an implementation for this is high on my to-do list!

[davidbarsky]

@srijs Those are all good points! Thanks for adding them.

I haven't had time to look into it this weekend, but experimenting with an implementation for this is high on my to-do list!

No worries! Shoot me an email (in commits on this repo) or a Twitter DM if you've got any questions. I'm thinking we should create a Discord room (or piggy-back on a Slack room elsewhere...) to discuss this kinda stuff.

Out of curiosity, do know if Rusoto intends to move to Tower in the near future? (I hate asking y'all to do work that Amazon should own, but internal politics and prioritization is a thing).

[jaysonsantos]

Hey there, I was thinking that from your app perspective it should be able to run in async fashion as for example S3 event on lambda is something like this:

{
  "Records":[{}]
}  

So, if you use the same runtime you used on lambda!{} you should be able to process n records using tokio and your actual lambda code would join on the tasks and send the synchronous answer to lambda runtime.
Does it make sense?

[nappa85]

Hello there,
I lost a few hours to create a wanna-be drop-in improvement of the runtime to enable async support: https://github.com/nappa85/aws-lambda-rust-runtime

On my tests it works fine, it just needs a new Tokio dep on the implemtation.
Any comment is appreciated.