Add a JSON Deserializer Middleware
See original GitHub issueIs your feature request related to a problem? Please describe. I spend a lot of time writing and rewriting deserialization and type validation code in my lambdas. I’ve just started a project where we have a large number of endpoints (roughly 40 of them) and I really didn’t fancy rewriting this code again and again.
As a result, I’ve written two middlewares compatible with your lambda-middleware library and I’d like to see if you’d like them as part of the main package before I publish them as separate packages, this feature request is for the JSON deserializer.
Would you be willing to help with a PR?
- Yes, absolutely (already written, writing tests now)
- Yes, with some guidance
- Unfortunately no time 😢
Describe the solution you’d like
This takes incoming event with a JSON payload, deserializes it to an object and replaces the body property with it’s object equivalent and throws a custom error if JSON serialization fails (so it can be picked up by a global error handler middleware).
The implementation types would be something like this:
<E extends APIGatewayProxyEvent, R>() => PromiseHandler<Omit<E, "body"> & { body: {} }, R> => R
It does the following:
- Asserts that the mime type on the request is JSON - if not it should throw a BadRequestError (if we’re setting up a middleware to deserialize json, a non-json request should be considered “bad” in my opinion?).
- Attempts to deserialize the payload - if it fails it should throw a
RequestBodyNotJsonError
. - Switches the
body
property on the request with the object and passes it to the handler.
Describe alternatives you’ve considered
- Writing the above functionality within the handler.
- Writing a compatible middleware and keeping it within my code.
- Releasing this as a separate project and package (but it seemed to make more sense and provide more visibility to add it to the main project though, and a nice way to give back to a really useful project).
Additional implementation notes/considerations
Changing Properties vs Adding New Properties to the APIGatewayProxyEvent
Currently I’m stripping the body and replacing it with an object, this does mean it could have negative effects on a downstream middleware, but I think it is cleaner for my code and reflects the object being transformed into something my handler will want to work with.
If you don’t want that, I could add another bodyObject
property in addition to the original body but seeing as you used a similar method in the class-validator
middleware, I hope you don’t have any issues with this? 😃
Error Handling
I like the idea of “typed” errors, as such my middleware will probably use two examples of this (and my implementation uses these).
I extend Error and add any relevant properties to the extended error class (so if it’s logged out I would get useful semantic logging).
You can then use these with http-error-handler
middleware (switching on error name) or I could use an app-specific error handler middleware at the top level (as I’m doing in my code at-present).
Issue Analytics
- State:
- Created 2 years ago
- Comments:5 (4 by maintainers)
Top GitHub Comments
The comments should be enough
I think this issue also needs the stale tag removing, have a good holiday and I look forward to your feedback in August.