@tus/server: split server into runtimes

[Murderlon]

In order to make the tus server less tightly coupled to Node.js, we can create runtime adapters which are consumed in the request handlers. This would allow tus to be ran on the edge, such as with Cloudfare Workers.

Example is how Remix does this:
https://github.com/remix-run/remix/tree/main/packages/remix-cloudflare-workers

[Acconut]

That might be a good abstraction to keep the main upload handling logic clean. In tus-js-client, we have similar HTTP adapters, but for the outgoing HTTP requests not the incoming ones. This way, we have one logic, but HTTP adapters for Node and the browser.

I don't have much experience with this edge computing, but I am wondering how well a tus server is fitted there. Do edge functions have streaming access to the request body? Or do they only receive a buffered version of the request once it has been fully transmitted?

[Murderlon]

Do edge functions have streaming access to the request body? Or do they only receive a buffered version of the request once it has been fully transmitted?

AFAIK JS runtimes stay as close as possible to each other so I wouldn't expect this to be suddenly different.

[fenos]

@Acconut @Murderlon implementation wise yes all edge runtimes are following the same standards and most runtimes do support request streaming.

Also, I would expect users using the client side chunkSize when using the edge implementation as usually edge function invocations has a time limit or resource limit

[Acconut]

implementation wise yes all edge runtimes are following the same standards and most runtimes do support request streaming.

That's great to hear!

[CanRau]

I think this would be fantastic.

There's https://github.com/Klowner/tussle which basically does this and could serve as inspiration or maybe there's even an opportunity for collaboration.

Trying to integrate a tus server in a Rakkas API route which is basically HatTip on the server which already supports all/most (edge) runtimes