introduce lambda-http module based on lando to support apigateway #18
Conversation
|
Small thing @softprops—can you fix the build issues on https://travis-ci.org/awslabs/aws-lambda-rust-runtime/jobs/462147745#L1072? Otherwise, this looks good to me! |
|
Will grab this tonight, Bali time :) |
|
All set |
|
I've successfully implemented this PR in my app: https://github.com/phillyfan1138/option_price_faas It works great! One suggestion: would it be possible to re-export the crate http? I had to add it to the project as a dependency to get the code to compile (see, for example, https://github.com/phillyfan1138/option_price_faas/blob/master/src/bin/output_constraints.rs) |
|
@phillyfan1138 will do. I tried to keep this as keep some corners from lifted lando kept conservative initially. I too found this annoying in practice, much as you typically need to pull in |
…( http::Response::builder() for example ), re-export the http crate for convenience
|
done. I backed out of the type alias I re-exported the I'll likely follow up on this pull with a proposal on one last bit from lando, the IntoResponse trait. Which greatly improved the easy of constructing common types of responses with semantic correctness and decreased verbosity. Again, iteration++ :) |
|
Awesome! Thanks @softprops ! |
|
@davidbarsky let me know if there's anything left you'd like to see in this pull. I'd start to.start iterating on top of this in smaller pulls |
|
I think this looks solid rn. I’m happy to merge. |
Issue #, if available:
This attempts to address #13
Description of changes:
Motivation
With this project announced at reinvent, I saw an opportunity to rebase lando a crate providing http crate interfaces for api gateway for deployment on lambda. I started working on that then I stumbled on #13. These crates seem to all serve the same purpose and landos goal from the start was to
not to replace tools but instead to work well with them. I saw this work going down the path of fracturing when I'd rather push it forward.Impl
I just took what I was working on in lando's in migrating towards rebalancing on top of this project and moved into a module in this project.
I took some steps to remove a few dependencies lando had that I think we're actually needed, but my first attempt forced a change to the
lambda_runtime::startapi which introduced a single allocation in order to support a serde deserializable =>http::Request=>http::Response=> serde serializable transformation where the user space dealt only in terms ofhttp::{Request, Response}'s . I couldn't find a way to avoid it with the lambda_runtime's function pointer interface but I'm open to change/suggestions.The
RequestExttype contains one opinionated methodpayloadwhich was lando's convenience for transparently deserializing request bodies from form encoded or application/json content. I'm open to pulling this out but I wanted to get the temperature in the room before I didThere's also an opinionated dependency on the
failurecrate. the failure crate mainly facilitated removing Error definition boilerplate for thepayloadmethods errors. I'm also open to ditching this dependency on impl the boilerplate by hand to keep the dependency tax lowBy submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license. ✅