Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: add new lambda feature #824

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

Fishrock123
Copy link
Member

For interacting with lambda_http, part of the official awslabs toolkit.

Needs more real testing. TBD.

This is easier to do in Tide directly because otherwise you have to make a wrapper, which seems unnecessary (though I could be convinced that perhaps this is still better in a separate crate).

For interacting with `lambda_http`, part of the official awslabs toolkit.
@adam-the
Copy link

adam-the commented Aug 18, 2021

This looks good and works fine for me after testing a few use cases. Only gripe I had was that binary is returned for all content types, but I couldn't find a better solution than just switching out the relevant code for lambda_http::Body::Text(body.into_string().await?).

Maybe we could pass the expected body type as a generic or something? I don't like the idea of checking the headers to find out what type should be returned.

This is easier to do in Tide directly because otherwise you have to make a wrapper, which seems unnecessary (though I could be convinced that perhaps this is still better in a separate crate).

I think it's a good idea to support it here and probably not in a separate crate, cause AWS is one of extremely few services that work like this, plus as you say, you'd then have to write a wrapper as well.

lambda-http 0.4.0 uses explicit lifetimes: 7211131

@Fishrock123
Copy link
Member Author

I ended up doing this as the "lambda-http" for the Tide-wrapping framework I maintain for my employer: https://github.com/eaze/preroll#list-of-optional-add-on-features

@adam-the
Copy link

adam-the commented Aug 21, 2021

I've just had a quick look over tide-lambda-listener; by comparison to this solution, it seems unnecessarily complicated? I don't see any practical difference functionality wise - how come you chose that solution over this?

@Fishrock123
Copy link
Member Author

Oh right. This is also available standalone as https://github.com/Fishrock123/tide-lambda-listener, which I completely forgot about.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants