fastly / expressly Goto Github PK

Version

1.0.0-alpha.9

What happened
https://fiddle.fastly.dev/fiddle/c053c616
Doing res.clearCookie in Expressly results in Error: TypeError: option expires is invalid instead of the cookie being cleared.

A workaround is to change this line to
this.cookie(key, "", { ...options, expires: new Date("Thu, 01 Jan 1970 00:00:00 GMT" )});

context

related #30

express provides a nextvariable in middlewares which represents the next middleware function in the middleware stack

see: https://expressjs.com/en/guide/using-middleware.html

this is nice to have because it allows running some code in a middleware after the middleware chain

some useful hints on implementations might be

• https://github.com/expressjs/express/blob/master/lib/middleware/init.js
• https://stackoverflow.com/questions/44238150/why-calling-next-in-express-routes-is-optional

done

• support optional next var in middleware functions

Version

"@fastly/expressly": "^2.0.1"

What happened

We are having trouble trying to Type middlewares that would stub the request Object.

A common express.js pattern is to enhance the req and add new functionality to store data or add helper methods using middlewares. ie. express-session, body-parser to name a few.

We tried to do that, but we cannot find a way to Type the new methods/functionality because of the way the Request object is typed.

I opened a PR to address some of this. And would love some feedback.

Version

2.0.1

What happened

We would like to be able to catch and log exceptions such as bad requests. It looks like the bad request 400 status code is returned by the runtime. Can expressly throw an error that we can catch for these requests? We are using custom error middleware and they are not catching 400s.

A bad request to an expressly service can be recreated with:

curl -svo /dev/null  "http://127.0.0.1:PORT/<"

Version

2.0.1

What happened

Please describe what you did, what you expected to happen, and what happened instead.

When creating error middleware, the err parameter is of type Error which does not have the status property. The expressly docs mention errors would be decorated with status.

The typescript error is:

Property 'status' does not exist on type 'Error'.

The raw FetchEvent has a method waitUntil that is useful when you wish to send a response back to the client and then perform some additional async work.

Expressly does not currently (AFAIK) expose a way to use this function. It would be helpful for some use cases to expose it or something similar.

A workaround (I think) is to use the private property, but this is very ugly and hacky:

// @ts-expect-error: event is private on request
req.event.waitUntil(promise)

Version

Latest

What happened

Expressly wraps the original request in https://github.com/fastly/expressly/blob/main/src/lib/routing/request/index.ts#L17. This request wrapper effectively results in a new request created via new Request(event.request).

Per the spec, this results in copying the full input buffer and making a copy of it in guest memory - https://developer.mozilla.org/en-US/docs/Web/API/Request/Request#input.

The issue is that this extra copy has performance implications, and in addition is currently prohibiting requests from being passed to KVStore since we don't yet support guest streams in the JS SDK, only native streams.

Adding a callback when the request has finished would be useful for tidying up any post-request actions (e.g. sending logs/metrics/traces).

Currently we're working around this using a polling approach on res.hasEnded, but this is quite wasteful (all of the polling effort, added complexity and that after the request finishes but before the next poll the app will be sitting doing nothing).