Switch away from tide web server

[ranile]

Currently, tide has its limitations especially not having support for web sockets which is preventing trunk from supporting web socket proxy and auto reloads (it may be possible to use SSE for auto reloads but tide's SSE's documentation also leaves a lot to be desired).

I suggest that tide should be switched out with something that is more complete at the moment like warp (or maybe even actix-web) (there are others servers too but they either don't have web sockets well documented or don't have support for web sockets at all). It's important to note that both of those frameworks would require switching away from async_std, which seems to be a requirement if web sockets support is needed. tokio-async-std crate can be used as a drop-in replacement to obtain the tokio runtime and use warp (from my very limited testing, it seems to work but I have never personally used it in a real application)

[MartinKavik]

Additional note - if I'm not wrong, tide doesn't support HTTP/2 so it limits SSE connections and theoretically may cause different behavior of the proxied server. I would also choose probably actix or warp.

[ranile]

Additional note - if I'm not wrong, tide doesn't support HTTP/2 so it limits SSE connections and theoretically may cause different behavior of the proxied server. I would also choose probably actix or warp.

If that's correct, that's yet another reason to switch. I'd personally take warp over actix-web (since it has served me better in the past).

[thedodd]

Yea, I know that not having WebSockets is a pain point for the current web server. I have been really hopeing that the WebSocket work in tide would have landed by now. I love the simplicity and clarity of the async-std & tide ecosystem. Don't get me wrong, I've used the hell out of the tokio stack and in other contexts I would definitely reach for it.

The one thing that I don't like about warp is it takes a very non-standard approach to building servers. It works, and is a solid system. However compared to tide, tide is exactly what you would expect from a web server. I have production systems running based on actix-web ... but that is also a bit heavier than I would like for this.

My plan at this point is to cross this bridge when I have the time to hack on the WebSockets/HMR/Browser reload feature. I might even just implement websocket support in tide myself, we'll see.

If someone beats me to it and has a PR which does all of the things and is of good form ... well, I'll probably merge it :)

[MartinKavik]

Ad HTTP/2 for Tide:

We've talked about authoring an async-h2 crate, but we currently don't have the bandwidth to.

• Quoted from https://blog.yoshuawuyts.com/async-http/

There is also a reserved crate: https://crates.io/crates/async-h2

[jeroenvervaeke]

I've started implementing hot reload using tide using their SSE and it simply doesn't work.
There is an open issue in their repo but it has no comments yet.

I would personally pick actix since I've used it before and I never had issues with it, but then again I don't think it would make that much of a difference since serving a few static resources and a websocket endpoint isn't rocket science.

[thedodd]

@jeroenvervaeke mind taking a look at #137 ??? Not sure if this will help at all, but with WebSocket proxy support landing soon, we could build on top of those capabilities perhaps?

Also, do you mind sharing some of your work related to the SSE bits? Perhaps the issue has a relatively simple fix, even if we need to patch tide/async_std.

[jeroenvervaeke]

@thedodd sorry for the late reply I'm currently too caught up with other projects.
At the time I started working on the implementation I had a lot of free time but it doesn't look like I'll have a lot of free time to contribute to this project anytime soon.

[thedodd]

Hey there @jeroenvervaeke. No worries. All of our main requirements (websockets and such) are now covered by Tide and working quite nicely. So I'm actually going to close this issue. HTTP2 was the last outstanding issue, but Tide will support that in due time I would imagine. Not a critical issue for a dev server.