Hi! I'm having some issues while working with
middy and httpErrorHandler middleware. I am using AWS Lambdas through an API Gateway, I have wrapped my handler in a middy() function and also applied the middlewares with .use(). When I need to throw an error inside my Lambda handler, I use the createError method from the http-errors library. But for some reason, the lambda response is always a 502 with {"message": "Internal server error"}. Am I missing something?
Hey there! Big fan of middy.js - it takes so much pain away. I was wondering if there's a standard approach to routing, i.e. one Lambda function that serves several of API endpoints with different handlers depending on the .routeKey (or .httpMethod + .resource)? Searching for router or routing on the issue tracker returns nothing.
hi everyone, I'm new to middy and I would like to create an official middleware for MikroORM (a typescript ORM I'm using). I'm using typescript on my project but I cannot find no typescript example on how to correctly use a middleware with typings and lambda or an example of custom middleware developed with typescript. Is there someone that has already did that and can share some example/process?
Happy New Year everyone! It's been a growing year for Middy with lots of adoptions (see below). Thank you for all of your help over the past year in making middy better than ever. We have some great news to start the year off with; I've started working on middy v2. We're addressing some of your most requested features and performance bottlenecks but will need to make some breaking changes. My goal is to have something together over the coming month so the community can comment. I'm hopeful AWS will support Node.js v14 around Apr/May and plan to have an alpha release ready for then.

Full trend details at middyjs/middy#590
1 reply
@zacyang Thanks for reaching out. Changing from callback to promise does also require you to return the response instead of using the callback function. There is an example in the README. This is a common pain point for many. We've rebuilt middy to remove the callback option in v2 to make this easier for all. We hope to have an alpha out in the next week (you can check it out sooner on the
release/v2 branch). Plans to have it released after AWS supports Node.js v14.
middy 2.0 is there!
In v1 you need to consider when things are triggered in the event cycle. So, yes it can. Saving to
context should make it easier. In v2 there is an all-new internal object that can be used to share data between middleware securely and asynchronously to make these usecases easier.
AWS Supports node.js v14!!!! https://aws.amazon.com/about-aws/whats-new/2021/02/aws-lambda-now-supports-node-js-14/
Voxel Group has just announced a port of middy to the .net runtime: https://twitter.com/vgaltes/status/1366371605337825284
Middy passed 100k downloads per week. Crazyness. https://www.npmtrends.com/@middy/core-vs-middy
Oh yeah, v2 beta is now releaseed :)
Oh yeah, v2 beta is now releaseed :)
really cool news, a good example here: https://eoins.medium.com/using-s3-object-lambdas-to-generate-and-transform-on-the-fly-874b0f27fb84
I was wondering how they allowed "streaming" file changes since lambda doesn't support streamed responses. Not a fan of the pattern their using, I think we could make this much better. I was hoping they would pass in a read stream and we could return a transform stream. I'll for sure use this feature once terraform supports it. I see a lot of value in having a middleware for this to make it way easier.
I had the exact same thought and I was a bit disappointed too :D However, from what i have seen in the api to create a custom lambda executor, I think doing a streaming implementation for Node.js could be feasible. I had a look sometime ago but if I remember correclty in that abstraction you have access to raw http requests, therefore you should be able to access streaming requests and provide streaming responses...
and see if my instincts are actually correct :D
@/all Looking for some feedback. I'm looking into adding in support for parsing nested aws events, ex: s3 -> sns -> sqs. In this example would you prefer using; a) single middlware for the source event (s3 in this case) that parses the wrapper events (sns/sqs) as well; b) have a parser for each event, and each would need to be applied in the correct order of use; c) single middleware for any event with wrapper event parsing.
They all have their pros/cons. Let me know what you think, which would you prefer to use?
They all have their pros/cons. Let me know what you think, which would you prefer to use?
Guys , i have a very simple payload via api-0gateway to lambda
{"email":"abc@gmail.com"}. and my Schema looks like this .const inputRequestSchema = {
type: 'object',
required: [
'email',
],
properties: {
email: {
type: 'string',
},
},
additionalProperties: true,
}; when i fire up the request , i get error message: 'must have required property email'les/@middy/core/index.js?:80:5) {ex.js?:51:21) Event object failed validation. any help here ? i am using following dependency "@middy/core": "^2.2.0",
"@middy/http-error-handler": "^2.2.0",
"@middy/http-header-normalizer": "^2.2.0",
"@middy/http-json-body-parser": "^2.2.0",
"@middy/validator": "^2.2.0". . use of middleware code \ export const handler = middy(handlerLambda)
.use(httpHeaderNormalizer())
.use(httpJsonBodyParser())
.use(validator({ inputSchema: inputRequestSchema }))
.use(httpErrorHandler());
@khirodAsurion your input schema doesn't match what API Gateway sends in. Should look something like:
{ "queryStringParameters":{...}, "body":{...} }. https://docs.aws.amazon.com/lambda/latest/dg/services-apigateway.html
@willfarrell thanks for the quick response. but I am only interested to validating body . in that case should I always have to provide other details also in schema ? or is there any other way ? See that I am adding
additionalProperties: true, just to make sure other added by APIGateway do not create issue .but still it says message: 'must have required property email'les/@middy/core/index.js?:80:5) {ex.js?:51:21) Event object failed validation
If you want to return errors, you need to handler ajv errors yourself. There isn't a standard everyone follows so we can't do it for you.
httpErrorHandler is a catch all if an error hasn't already been handled. It returns a generic message (which can be overridden), because you don't want stack traces returned to the consumer, leading to leaking too much information (security best practice).