Question: Why does Rubytus use Goliath?

[janko]

First of all, thank you for sharing this with the world, it was very inspirational to dive into the source code.

But I'm curious, why does Rubytus use Goliath instead of a regular synchronous framework? I feel like using EventMachine is awesome when you're doing a lot of IO (e.g. HTTP requests), because then everything is asynchronous. But Rubytus only writes to filesystem, which is very fast. And even if it's not, it's currently still synchronous.

So just out of curiosity I wanted to know why did you decide to use Goliath? Is it because of its ability to terminate the request before the request body is received?

[janko]

Ok, I got it now. So I think the main advantage of Goliath over other web frameworks here is that it supports this part of the tus specification of the PATCH request:

The Server SHOULD always attempt to store as much of the received data as possible.

Since Goliath is a thin wrapper around EventMachine, it allows you to save however much data was sent in a PATCH request before it was terminated. Which is what tus-js-client does at the moment, it just sends a PATCH request with the whole file, and counts that in case of interruption the server would save whatever was received so far.

Rack-based web frameworks don't have that, as I see from the code none of the Puma/Unicorn/Thin currently allow forwarding the request to the Rack app if the connection was terminated, which means that any received data is lost.

I opened tus/tus-resumable-upload-protocol#89 to hopefully relax this constraint. But until then Goliath is the only one that can properly resume an interrupted PATCH request, because it saves any received data in case of interruption. Tus-js-client can be configured to send data in chunks, but sending a single PATCH request is probably faster and preferred. And that answers my original question 😃