Making a simple game with Warp and websockets

Sure that makes sense. The main issue with anyhow and Box<dyn Error> is that it is difficult to inspect the underlying error, so when writing a library crate, you should use custom error enums instead. However, that is not your situation: You are building an application, and you can simply change the error type to an enum when you need to be able to handle the error.

Keep mind that ws.next().await if is None, then the stream has ended. Depending on the kind of stream, you should consider doing something more intelligent than returning an error when the stream ends.

I have started working on a web frontend in Yew. Unfortunately, I can’t compile it to the target wasm32-unknown-unknown because the deprecated net2 crate, which is an indirect dependency of tokio and warp, fails to build with a strange message:

> cargo build --bin client --target wasm32-unknown-unknown
   Compiling proc-macro2 v1.0.17
   Compiling syn v1.0.24
   Compiling net2 v0.2.34
   Compiling rand_pcg v0.1.2
   Compiling rand_chacha v0.1.1
   Compiling rand_core v0.3.1
error[E0432]: unresolved import `sys`
  --> /home/loewenheim/.cargo/registry/src/github.com-1ecc6299db9ec823/net2-0.2.34/src/tcp.rs:18:5
   |
18 | use sys::c;
   |     ^^^ maybe a missing crate `sys`?

As far as I can tell, sys is a module in net2. Strangely, this only happens for wasm, not for normal compilation. How can I fix or work around this? Should I raise an issue somewhere (yew, tokio, warp)?

Tokio is generally intended to run on web servers, not in the browser.

I’m not trying to use tokio in the browser, but currently my project has just one set of dependencies. Does that mean I should split them up so that the frontend doesn’t depend on a lot of server stuff and the backend doesn’t depend on yew?

The typical strategy would be to put any code that makes sense to share between the frontend and backend in a module/crate and then include that from both the frontend and backend code. In something like this, the shared code would probably primarily include types for data that is shared between the server and client along with any common functions for interacting with that data.

You can use a cargo workspace for this.

Thanks, I’ll read up on workspaces. I haven’t encountered them before.

I got it working very easily with a workspace :slight_smile:

Regarding the frontend: Currently, my backend contains a route that sends index.html to anyone who connects. The first thing index.html does is attempt a websocket connection to the server. However, all yew examples I've seen work by running a small server that hosts index.html and connects to the (separately running) backend process. Is this the way forward?

I think either is probably fine.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.