Event struct definitions
LegNeato opened this issue · comments
Hello! I am one of the maintainers of https://github.com/srijs/rust-aws-lambda (Rust interface to the Go runtime). As part of that project, we have lambda event definitions that don't depend on the runtime:
https://github.com/srijs/rust-aws-lambda/tree/master/aws_lambda_events
It would be great to have those event types integrated in this crate, preferably by re-exporting. I'm also fine if you want to take over ownership and make it officially supported, as long as it doesn't take too long for changes to be merged.
Note right now the generated structs take String and thus may require more allocations. I plan to also have variants that take Cow<'a, str>.
Hey @LegNeato, thanks for offering. I'll talk this through with @davidbarsky once we get back from re:Invent.
It would be great to have those event types integrated in this crate, preferably by re-exporting. I'm also fine if you want to take over ownership and make it officially supported, as long as it doesn't take too long for changes to be merged.
In the short term, we'd be very happy to re-export those types. Until we have a PR (whether from us or you—let us know; I won't be able to put one up today), we'll link to the lambda definitions in the README.md.
In the long term, we'd like to take ownership of those definitions, but we'd need to weigh whether we want to generate from Go's definitions or our internal definitions.
Great! I'm hopping on a plane right now so won't be able to get a PR up for the readme for a while. No rush!
I agree long-term it would be ideal for you to generate the defs from your internal definitions rather than the go code. If there were public defs like boto has for service apis I would have used those, instead I just used what I could find.
Great! I'm hopping on a plane right now so won't be able to get a PR up for the readme for a while. No rush!
Totally, travel safe :)
I agree long-term it would be ideal for you to generate the defs from your internal definitions rather than the go code. If there were public defs like boto has for service apis I would have used those, instead I just used what I could find.
I'd need to chat with the right people internally. I suspect that there's a proper long-term solution available.
Few ideas I wanted to throw out there because this same topic must be opened for each and every type checked language used in lambda in the past and likely every type checked language implemented in the future.
Something I'd considered a few months back was kicking around the idea putting together a repository that collecting machine readable json schemas documenting and describing AWS lambda types. https://github.com/softprops/typed-lambda
It's just an idea at this point and it's incomplete ( as you can see from it's Travis build :) ). The first attempt was to use a go package to read the go structs and output Json schemas that could in theory be used to regenerate the go and any other type checked language AWS lambda structures.
In practice I found the go definitions to produce imprecise information. For instance in go, zero values (nil) are useful and don't translate information to a language like rust.
My next exploration was going to be translating this via typescript types which express type information more precisely to Json schemas https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/aws-lambda/index.d.ts
I wanted to drop a heads up in case you folks would be interested in collaborating to generate rust types from Json schemas as well. I see this kind of thing have a benefit to a wider audience as other language sdks would also benefit.
Hey @softprops, I'll meet with the Lambda team next week to figure out what we have internally and could use for this. I'd try to rely on those definitions since they are the ones the Lambda team is likely to keep up to date for us. I'll update this issue once I have something.
Any progress on this lately?
@alexreg It's something that the Lambda team is looking at, but unfortunately, I can't give you a specific date as to when it'll be ready. In the meantime, I suggest using the aws_lambda_events crate, as that is the most comprehensive source of typed CloudWatch Events currently available.
We'll update this ticket when official support is available.
Looks like someone is running into a related problem in #307.