Hey all! Is there any preferred way of reusing a configured set of middlewares?
I have a handler configured:
const handler = middy(async (event, context, callback) => {
(...)
callback(null, { });
});
handler.use(middleware1())
handler.use(middleware2())
handler.use(middleware3())
handler.use(middleware4())
module.exports = { handler };I'm looking for a good way of only having to specify something like:
const handler = withMiddlewares(async (event, context, callback) => {
(...)
callback(null, { });
});
module.exports = { handler };Where the handler is pre-configured with a bunch of middlewares.
I'm trying to avoid duplicating a bunch of handler configurations that are all going to be the same / similar.
Cheers!
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?