-
Notifications
You must be signed in to change notification settings - Fork 478
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
System.Text.Json Support for AWS Lambda SDK? #544
Comments
Thanks @martincostello. I'm gonna move this to our Lambda .NET repo. |
Just a note, @martincostello that wont work for API Gateway.
You need to add this too or the response will be considered malformed due to pascal casing on the properties. |
Thanks @phillip-haydon that is helpful. I have been working on official support for this in the system.text.json branch. I'm working my way through the existing event tests to make sure the new serializer works the same as the Newtonsoft one. Its still very much a work in progress but feel free to take a look and provide feedback. |
The PR for this has been created with a link to some preview builds of the NuGet packages for those that are currently trying out .NET Core 3.1 with the Lambda custom runtime feature. #568. I'm going to close this issue and use the PR to track this feature going forward. |
As part of migrating some existing .NET Core 3.0 worker services running on EC2 to AWS Lambda, we've coded-up a custom
ILambdaSerializer
implementation to handle deserializing payloads to the Lambda function, such asSQSEvent
.While this is relatively simple to do, it would be nice if a serializer implementation for System.Text.Json was built into the Lambda SDK to save the need for copy-paste across different function codebases.
One shortcoming with the state-of-things as of today is that
PropertyNameCaseInsensitive
has to be set totrue
on the serializer options as the events don't use consistent PascalCase vs. camelCase naming, which incurs a performance penalty (I don't have a quantifier for how much the penalty is). In the case ofSQSEvent
I believe it'seventSourceARN
that trips it up as it doesn't map over toEventSourceArn
.I imagine this could be easily fixed in the event libraries by adding
[JsonPropertyName("...")]
attribute annotations to the properties on the models.I believe further benefit could be gained if there was asynchronous methods on the interface to leverage the async support of
System.Text.Json.JsonSerializer
and consume theStream
directly, but that's a bigger change that just providing an implementation based on the current interface.Below is the code we're using. It might benefit from further optimization, but as it is right now it's working well for us:
/cc @normj
The text was updated successfully, but these errors were encountered: