Alternative realization of farside

[cofob]

Hello!

I noticed that farside.link processes requests very long, redirect takes 700 ms (without taking ping into account). I don't really understand what this is due to, there is no objective reason for it.

So I decided to make an alternative implementation of farside, but in Rust, and called it fastside (fastside.link).
API is almost identical, the only difference is that:

• Redirects to links of the form fastside.link/https://youtube.com/... are not supported. (but may be supported in future. UPD: supported from version 0.2.0)
• Added a new type of redirect, which is cached on the client and does not require additional requests to the server, due to which it works faster and more private. Example fastside.link/@cached/nitter/#spacex (redirect will happen via html page where js redirects user to a random instance without sending url request to server).
• Web server supports http3, so tls handshake establishes faster.

Can you please mention fastside in the README and explain the reason why farside takes so long to process requests here?

[benbusby]

Interesting, I'm actually getting the complete opposite result on a couple of my machines. Farside is returning redirects in about ~100ms, and "Fastside" takes around ~600-700ms (!) across multiple tests.

There's nothing that should be slow about Farside since the logic is so simple, but I'll try to find some time to investigate why you might be seeing that.