Make SvelteKit compatible with server middlewares

[hgl]

Is your feature request related to a problem? Please describe.
There are a lot of issues that either ask for server side features like SSE, websocket, etc or directly for server side middlewares.

I think the root issue is that the handle hook exposes its own types for request and response, which are not compatible with express middlewares that is the de facto standard in Node.

I get the rationale behind this design, as @Rich-Harris said in #334

it means that the answer to various problems becomes 'use adapter-node, because you can use arbitrary middleware'

However, the current design feels more like making adapter-node a second-class citizen in order to treat every adapter the same.

I recently came across https://github.com/vendia/serverless-express, which seems to contain a solution to this problem.

Describe the solution you'd like

This code converts a request-like object into http.IncomingMessage (there is similar code for http.ServerResponse)
https://github.com/vendia/serverless-express/blob/5cd87c8e7ca3a5e971d26d471cb70a6ac15cc61f/src/request.js#L7-L16

And it's the cornerstone for using middlewares in a serverless environment.

I wonder if it's a good idea to make the handle hook (maybe also endpoints) expose http.IncomingMessage and http.ServerResponse instead? For adaptor-node, the corresponding objects from polka are directly returned, for other adaptors, the aforementioned polyfill is applied.

This should open Svelte Kit to the vast amount of server middlewares that are available.

Describe alternatives you've considered

How important is this feature to you?
Very, not being able use existing middlewares is a deal breaker for many people from the referenced issues.
But it's actually possible to polyfill in userland to use the middlewares.

Additional context

[benmccann]

The idea that Rich had suggested was to build a converter between the SvelteKit and Express request and response objects

[hgl]

That works, but if they're convertible, I wonder what's the appeal of exposing the custom types in the first place, and for adapter-node, that seems to mean converting back and forth?

[jthegedus]

@benmccann Is that suggestion tracked in this repo somewhere? It would make the Firebase adapter (which uses Express APIs) much easier to integrate.

[benmccann]

if they're convertible, I wonder what's the appeal of exposing the custom types in the first place

We didn't want to use Express types because not all adapters provide an Express request / response the way adapter-node does.

@benmccann Is that suggestion tracked in this repo somewhere?

I think this is the best issue tracking it

[Conduitry]

This is a retread of #334.

When this was being discussed internally in March (rather heatedly!), where I believe we landed was that, if someone cared enough about supporting the Express middleware API, there could be a community-maintained interop library between that API and what the handle hook provides. Rich wanted a certain amount of friction in place for using things that needed the middleware API, and forcing this to happen with a third-party library in userland was approximately the amount of friction he said he wanted to have.

The outcome of the conversation at the time was summarized in #334 (comment) and I don't know how much of the thinking has changed since then.

[benmccann]

this is done now. please see the faq and adapter-node docs for more details. we may make additional dev mode APIs available in the future after some pending PRs to Vite are merged