Version 6

[willfarrell]

aka The OTel Update (Hopefully)

Release: Nov (after nodejs active LTS starts)

Timeline based on AWS nodejs22.x release cycle

Release Notes: https://github.com/middyjs/middy/blob/release/6.0.0/website/docs/upgrade/5-6.md

Planned

• [x] Drop Node v18, Add support fro Node v22
  • [x] Update engines to "node": ">=20"
  • [x] Update github workflows node-version
• [ ] docs
  • [x] migration
  • [ ] release cycle
• [x] --experimental-require-module support #1233
• core
  • [x] support early response undefined values #1236
• http-response-serializer
  • [x] deprecate use of event.requiredContentType
• s3-object-response
  • [x] Update docs to show use of new aws-xray-sdk-fetch, deprecate awsClientCapture option for captureFetchGlobal()
• [x] http-cors Change default origin:null
• [x] http-urlencode-body-parser deprecate use of qs for native solution
• [x] validator upgrade ajv-formats to v3 (https://github.com/ajv-validator/ajv-formats/releases/tag/v3.0.0-rc.0)
• [x] replace use of:
  • [x] sinon with node:test

Moved to v17

• [ ] LLRT Support
• [ ] Move to Otel for Logs, Metrics, Traces? (if possible) https://github.com/aws/aws-xray-sdk-node/issues/515
  • Update Logs, Metrics, Traces to use OTel if ready (https://github.com/willfarrell/aws-wishlist#lambda)
  • Use Otel: https://aws-otel.github.io/docs/getting-started/javascript-sdk
  • Use powertools: https://awslabs.github.io/aws-lambda-powertools-typescript/latest/core/tracer/#patching-aws-sdk-clients
  • discussion: https://github.com/awslabs/aws-lambda-powertools-typescript/discussions/665
  • [ ] error-logger update to print otel by default
  • [ ] input-output-logger update to print in otel format
• [ ] Deprecate Report-To, default to Reporting-Endpoints

Maybe

• [ ] improve response streaming support (new middlewares?)
• [ ] plugins as packages?
• [ ] Routers updated to support URLPattern? Still experimental?
• [ ] Move to JSDoc notation? https://www.youtube.com/watch?v=zPOHY-cZ1wE
• [ ] Update abort signals if Lambda adds support

[dreamorosi]

Hi @willfarrell - would like to learn more about the OTel/Powertools points in the list above.

On our side we’ve been looking at OTel closely and for now we have decided to not move forward because the performance impact, especially on cold starts, is still too big.

At least for now, that’s something we won’t be doing at least until 2025, which would be v7 for you.

Curious to hear if you’ve arrived at different conclusions

[willfarrell]

@dreamorosi

On our side we’ve been looking at OTel closely and for now we have decided to not move forward because the performance impact, especially on cold starts, is still too big.

Same, along with OTel Logging not supported for nodejs yet (at least the last time i checked).

OTel was listed for v5, but sounds like it's still not ready for production yet. The idea is to deprecate our logging/cloudwatch middlewares for Powertools using OTel, whenever it's ready. The switch to Otel is the only big change on the horizon for Middy currently.

[jlarmstrongiv]

Might be worthwhile improving middleware types https://github.com/middyjs/middy/issues/1221#issuecomment-2210497881

[dmeehan1968]

middy currently throws exceptions dependent on whether the event/onError handler returns a response that is 'undefined'. However, void/undefined is a legitimate value for many Lambdas (indeed the default handler definition is for a return value of void | Promise<any>.

Whilst the invocation source of the Lambda should discard any received response the docs currently state 'return request.response will silence the error', but this is only the case if some other middleware had set a response value. At the origin handlers point of failure, response would be undefined.

In my case (EventBridge Rule target), I wanted to send some errors immediately to a DLQ, as Lambda retry wouldn't have been meaningful. I found that return request.response ?? null was what I needed to prevent the error from bubbling up.

[joebowbeer]

Why wait for OTEL logging? OTEL is not all or nothing; the three parts are separable.

Being able to leverage OTEL metrics and/or traces would be helpful.

For example, prometheus can now receive OTLP metrics directly. See exporter-metrics-otlp-http.

The modular OTEL producer/reader/exporter design is very flexible.

[willfarrell]

6.0.0-alpha.0 is now released. You can preview the release notes at https://github.com/middyjs/middy/blob/release/6.0.0/website/docs/upgrade/5-6.md