Project: something using WebSockets?

[chriskrycho]

WebSockets are relatively lightweight from a protocol POV and there are a couple solid Rust libraries for them. I wonder if they might be a good target for showing some of the interactions and coordination you want t

• Chat server: This one is relatively obvious in that it is the canonical example and motivation for WebSockets themselves, and building a chat client is actually pretty neat: being able to have two browser windows up next to each other and see the messages appear back and forth in basically-real-time is great. The downside I see here is that it does not show a lot of the coordination aspects—basically just shutdown for closing the socket, and having both sender and receiver sides.

• Live reload server: This is a little less obvious but I think might actually work better. It would show async coordination between file events (using notify or maybe watchexec), the web server (probably using Axum? But I am very open to something else, too), and a WebSocket connection (fastwebsockets seems nice?). It also basically covers everything that the chat server does, I think.

  I have been thinking about this one for a while (I was interested in it at a personal level, never having built one), and I think it might be just small enough to manage.

For either of these, or indeed anything which has a browser UI attached, I think it will behoove us to supply a Git repo (perhaps a GitHub “template”-style repo) which people can use as the starting point for their implementation, which supplies (minimal) pre-baked HTML, CSS, and JS/TS (already compiled, or with a known-good and verified-by-CI-all-the-time build) that makes it easy for people to just focus on the Rust part. The client-side code there can be fairly minimal.

Thoughts, @carols10cents?

[chriskrycho]

[!note] I have been thinking about the live reload server at a personal level, never having built one, so I am building an example of that out anyway as one of the ways to get my head around some of those challenges with my “newbie” hat on.

[carols10cents]

For either of these, or indeed anything which has a browser UI attached, I think it will behoove us to supply a Git repo (perhaps a GitHub “template”-style repo) which people can use as the starting point for their implementation, which supplies (minimal) pre-baked HTML, CSS, and JS/TS (already compiled, or with a known-good and verified-by-CI-all-the-time build) that makes it easy for people to just focus on the Rust part. The client-side code there can be fairly minimal.

So I like involving the browser because you get to make something more "tangible" in a way, which feels satisfying.

On the other hand, maintaining this repo of HTML/CSS/JS is making me feel a bit 😱, but it is sort of comparable to the idea of providing a little toy async runtime, so I haven't entirely ruled it out. It does sound like you're thinking of small, simple, likely-to-work-and-keep-working, so I'm open to it!

[chriskrycho]

@carols10cents yeah, that maintenance side is, I think, even simpler than I was thinking it would be: there is a working version of it now in the lrrs directory, and the entirety of what we need for a working example there is 29 lines of HTML and JS in a single file, with no CSS, and that's with 7 lines for logging and a generous deployment of white space. 😅

I am going to spend some time next week iterating on the server code there, but all told that comes out to about 300 lines of code, and even once I add a touch more error handling it’ll probably be under 350LOC, which isn’t too bad—and could likely be simplified/cleaned up! What’s there now is best labeled “Chris finally got his head around enough of this to be able to start making coherent design decisions.” 😂