-
Notifications
You must be signed in to change notification settings - Fork 361
[WIP] feat!: Replace Handler with tower::Service #375
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
Changes from all commits
0620189
ddc9d48
8427987
4a92c0c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -148,6 +148,15 @@ impl TryFrom<HeaderMap> for Context { | |
} | ||
} | ||
|
||
/// Incoming Lambda request containing the event payload and context. | ||
#[derive(Clone, Debug)] | ||
pub struct LambdaRequest<T> { | ||
/// Event payload. | ||
pub event: T, | ||
/// Invocation context. | ||
pub context: Context, | ||
Comment on lines
+154
to
+157
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nit: I'd make these fields private and only expose them via getters to not make adding fields a semver-breaking change. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good point! For reference if anyone else reads this, I wanted to dig into why getters would be a good idea here and found this message on the Rust forum. That said, given that the only benefit of getters here would be preventing breaking changes, isn't it better to use There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I may be confusing what is being discussed. Feel free to ignore ... My understanding is that &mut is not possible due to Would it be a good idea to have something like this? pub struct LambdaRequest<T,Q> {
/// Event payload.
pub event: T,
/// Invocation context.
pub context: Context,
/// User-defined cache
pub cache: Q,
}
It probably doesn't matter if the example given by @softprops in #372 (comment) would still work after this change. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hey @rimutaka ! Thanks for taking the time to look at this. 😄 With this change, the example from @softprops would not directly, but you could make your own
That said, for your specific use-case, you could also use the high-level interface if you're OK with using a There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Actually, taking a step back, I think the Then from there, you could provide There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Extensions would be a nice addition to the current option of implementing Handler trait. I am concerned we may overcomplicate the user interface, though. Just a thought. |
||
} | ||
|
||
#[cfg(test)] | ||
mod test { | ||
use super::*; | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this intentionally not public?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes! My thinking here was to only use this function as part of
handler_fn
to help wrap a function that takes two arguments.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
gotcha. for the public interface, i think i'd personally try to use (and-reexport)
tower::service_fn
.