Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 15:48
    carlnordenfelt commented #895
  • 15:23
    willfarrell commented #895
  • 15:19
    willfarrell closed #959
  • 15:19
    willfarrell commented #959
  • 15:17

    willfarrell on 4.0.4

    (compare)

  • 15:17

    willfarrell on main

    chore: version bump (compare)

  • 15:14

    willfarrell on main

    Add transpile.d.ts to npm packa… Merge pull request #958 from da… (compare)

  • 15:14
    willfarrell closed #958
  • 13:27
    gregschroeder commented #959
  • 13:24
    codyfrisch commented #895
  • 13:23
    codyfrisch commented #895
  • 12:33
    carlnordenfelt commented #895
  • 12:10
    KillDozerX2 commented #959
  • 11:04
    dnicolson opened #959
  • 10:29
    dave-irvine opened #958
  • Dec 08 18:28

    willfarrell on main

    test: fix name to match pkg docs: add in list of configs docs: re-word (compare)

  • Dec 08 17:42

    willfarrell on main

    docs: update to show v3 sdk (compare)

  • Dec 08 17:37

    willfarrell on main

    chore: update to use captureAWS… (compare)

  • Dec 08 16:30

    willfarrell on 4.0.3

    (compare)

  • Dec 08 16:30

    willfarrell on main

    chore: version bump (compare)

Luciano Mammino
@lmammino
middy 2.0 is there!
Davide Behr
@behr-davide
Quick question.. can code outside of a handler function use parameters loaded by the SSM middleware? I logged the process.env object outside of my handler and it did not contain the SSM param I fetched.
will Farrell
@willfarrell
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.
Davide Behr
@behr-davide
Good to know -- thanks for your response and thank you to everyone who contributes to middy! :pray:
Luciano Mammino
@lmammino
Voxel Group has just announced a port of middy to the .net runtime: https://twitter.com/vgaltes/status/1366371605337825284
will Farrell
@willfarrell
Middy passed 100k downloads per week. Crazyness. https://www.npmtrends.com/@middy/core-vs-middy
Oh yeah, v2 beta is now releaseed :)
Luciano Mammino
@lmammino
WOOW great news!
Luciano Mammino
@lmammino
will Farrell
@willfarrell
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.
Luciano Mammino
@lmammino
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...
will Farrell
@willfarrell
Seriously, this is possible now? I've been waiting for streaming responses since apig was introduced. We have to add this to middy :P
Luciano Mammino
@lmammino
I might have to experiment a little with creating a non-standard executor
and see if my instincts are actually correct :D
will Farrell
@willfarrell
having stream requests/responses in middy would be a game-changer.
will Farrell
@willfarrell
@/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?
Luciano Mammino
@lmammino
https://nodeweekly.com/issues/384 A middy interview here! <3
will Farrell
@willfarrell
middy is listed on the new ajv website homepage. https://ajv.js.org/
khirodAsurion
@khirodAsurion
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());
will Farrell
@willfarrell
@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
khirodAsurion
@khirodAsurion
@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
will Farrell
@willfarrell
Your schema only need to include what you want to validate, but must expected the warper object around your request.
khirodAsurion
@khirodAsurion
Thanks @willfarrell . That worked. ! Although I am not sure if i use .use(httpErrorHandler()); I still do not see the real error around the Schema diff thrown as an error . It only says very generic message
will Farrell
@willfarrell
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).
khirodAsurion
@khirodAsurion
thanks
Maximillian Naza
@2Clutch
Hello. I currently have an Express API I'm looking to migrate to Middy. Is there a tutorial or some piece of documentation I can use as a compass to guide me in my efforts?
will Farrell
@willfarrell
Not that's I'm aware of, but if you find one, I'd be happy to merge it into the docs.
Maximillian Naza
@2Clutch
That's unfortunate. I'm not sure to translate the concept of an endpoint over to middy. or in other words, how do I determine what to do with a request once I receive it?
Has anyone here built an API with middy? If so, I'd love to take a look at it (assuming it's in a public repo)
Vincent Nmeregini
@v.nmeregini_gitlab
Hi everyone, I'll love to know if it’s possible to auto-generate swagger documentation using middy.
will Farrell
@willfarrell
Enric Bisbe Gil
@ebisbe
Screenshot 2022-01-04 at 13.15.23.png
Hi, I have a question regarding the sqs-partial-batch-failure package. When I use it the lambda functions is not processed as fast as when I don't use it. Here's a sample of the sqs queue.
The moment I switched to not using the sqs-partial batch the queue processes super fast. I'm not sure what is causing that. The processEvent is the same it just changes the handler function
module.exports.handler = async ({ Records }) => {
  const failedMessageIds = []
  let batch = {}

  for (const record of Records) {
    try {
      console.log(`Processing ${record.messageId}`)
      const bodyData = JSON.parse(record.body)
      await processEvent(bodyData, batch)
    } catch (e) {
      console.log(e)
      failedMessageIds.push(record.messageId)
    }
  }
  await table.batchWrite(batch)
  await flushQueue()

  return {
    batchItemFailures: failedMessageIds.map(id => ({ itemIdentifier: id }))
  }
}

That's what I'm using now and goes fast.

const middy = require("@middy/core")
const sqsBatch = require("@middy/sqs-partial-batch-failure")
const sqsJsonBodyParser = require("@middy/sqs-json-body-parser")

const originalHandler = ({ Records }) => {
  const recordPromises = Records.map(async ({ body }) => processEvent(body))
  return Promise.allSettled(recordPromises)
}

module.exports = {
  handler: middy(originalHandler).use([sqsJsonBodyParser(), sqsBatch()])
}

This is the slow code.

Any ideas?

Maybe I should post it on the issues aswell
will Farrell
@willfarrell
@ebisbe please open an issue
Enric Bisbe Gil
@ebisbe

@ebisbe please open an issue

ok

Enric Bisbe Gil
@ebisbe
done
will Farrell
@willfarrell
AWS has released some of their own Middy middlewares! https://github.com/awslabs/aws-lambda-powertools-typescript
will Farrell
@willfarrell
Alpha of v3 is now on npm!
Nemanja Stojanovic
@nem035_gitlab

hey folks, quick question.

I want to create a logger in a middleware that always logs the context information and then pass that logger to the middleware. Is my only option to attach the logger to the event or context?

Something like this:

function attachLoggerMiddleware(){

  const attachLoggerMiddlewareBefore = (
    request
  ) => {
    request.event.logger = new Logger(request.context);
  };

  return {
    before: attachLoggerMiddlewareBefore,
  };
}

And then in the handler I can do:

function (event) {
  event.logger.info('yo');
}
2 replies
will Farrell
@willfarrell
@nem035_gitlab Attaching to the context is the recommended way for passing things from middleware to the handler. However you could initialize in the global scope, then inject the context during a before middleware. Have you seen: https://awslabs.github.io/aws-lambda-powertools-typescript/latest/core/logger/
14 replies
Luciano Mammino
@lmammino

A new redesigned website has just been publishet at https://middy.js.org .

We'd really love your feedback on the new design, documentation and all over the new DX.