Add a JSON Deserializer Middleware

[matt-jenner]

Is 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?

• [x] 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).

[dbartholomae]

Thanks! Happy to help with the PR, feel free to open it early.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[matt-jenner]

Hi, sorry for the delay, I got bogged down in a code-coverage issue then had to park this due to work release pressures and needing to spend time on some DIY issues while the weather was good. I hope this is the sort of thing you were looking for, I look forward to your feedback and then I can start moving my io-ts validator middleware in that will utilise this.

[matt-jenner]

I think this issue also needs the stale tag removing, have a good holiday and I look forward to your feedback in August.

[dbartholomae]

The comments should be enough