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.

[hgl]

Thanks for providing the context @Conduitry.

I think the conclusion in #334 is worth revisiting, given the friction manifested in the current design, and the referenced repo shows that it's possible to expose node request & response types in a serverless environment, which was not mentioned in #334:

it's not enough to have a way to add middleware to adapter-node, because it doesn't apply to svelte-kit dev and svelte-kit start

If handle (and endpoints) provide node types, then middleware lives in unadapted code, so it applies to svelte-kit dev and svelte-kit start

ideally there should be some way to use existing connect middlewares, but we don't want to privilege adapter-node over serverless adapters (or CFW etc, when we get round to it)

If request & response from other adapters are polyfilled, then adapter-node is not privileged (at least not completely, streaming data in serverless is something you simply can't workaround or polyfill).

---

Rich did bring up another point:

I really don't think multer, formidable and passport are the right answers in 2021.

The future-proof thing to do isn't to throw our hands up and say 'we can't possibly anticipate everything people will need to do, therefore we should abdicate the responsibility to the ecosystem of Express middleware'

This raised a very good question that is using middleware a dogma? Is there some room for innovation here? I really hope there is a positive answer here. But middleware is not a standalone thing. They usually serve the services that bundle them. Even if there is an innovative approach, you either have to write adaptors for bundled middleware, or create unofficial bindings for at least popular services, this seems unscalable.

If you accept that middleware is currently the most pragmatic approach, I think it really boils down to two choices:

1. Provide the lowest common denominator, which is the current approach. This treats every adapter the same, but at the cost of hamstringing adapters for more capable environments.
2. Provide the greatest common factor, but polyfill the rest and document the discrepancies. This does make some adapters for less-capable environments less first-class, but they are not second-class either.

[hgl]

But if I have to be honest (also to provide field report), I initially opened the issue for a GraphQL middleware I want to use, but after some experiment, I realized the isomorphic load & fetch design really prioritizes Restful APIs, so I end up putting GraphQL behind Restful APIs (i.e., calling GraphQL only on server side in endpoints), obviating the need for middleware. So I no longer have skin in the game currently, but I do see the need for other services (and would probably need middleware again when I need subscription support in GraphQL).

P.S. Should I open a new issue about the friction between isomorphism and GraphQL?

[benmccann]

The maintainers have discussed this in depth. Some made the same arguments you're making now. While some of the maintainers agree with you, the decision was made in the other direction. Continuing to push for having Express request and response types directly is not going to change anything because these points have all been considered. Continuing to argue the same point will only bury the suggested solution (#1610 (comment)) making it less likely that someone will see it and work on creating a converter or facade between SvelteKit and Express request / response types.

[benmccann]

Should I open a new issue about the friction between isomorphism and GraphQL?

As far as I'm aware, there isn't any friction between isomorphism and GraphQL. It's hard to give more advice without more details. I would suggest discussing on Discord first and seeing if folks have a solution for the issue you're running into or if there's agreement that there's an issue in SvelteKit

[hgl]

because these points have all been considered

I was not aware of that solely from #334, but I respect the decision the maintainers landed on.

creating a converter or facade between SvelteKit and Express request / response types.

As previously mentioned, my only gripe is that this seems to punish adapter-node with double conversions.