Is it desirable to use webrtc-rs for web-based multiplayer game?

[codernineteen]

I just start to reading webrtc book a few days ago, so sorry about my lack of knowledge of this field.
I'm doing a project to implement virtual classroom service running on browser.
As i know, Webrtc is p2p networking and peer connection doesn't need central server.
My initial plan was to implement rust webrtc server handling user's movement sync jobs for better performance.
But while i'm reading webrtc book, i just realized it might be better to use peerjs instead of separating sync logics into two different language ecosystem.

I want to get opinions of below question
Is it desirable to use webrtc-rs for web-based multiplayer game? If so, how can i connect each clients while i'm creating clients with three.js library

[InDieTasten]

Considerations for why you want to use/avoid webrtc for web-based multiplayer:

The web clients of your multiplayer game should use the browser native APIs for webrtc for talking to eachother. PeerJS is a wrapper around that API and might be easier to use. It's definitely a viable option.
You can dedicate one of the players in a lobby to a "host" for streamlining the way data is synced. If that peer goes down, the remaining peers need to figure out a new host. This is typically called host migration and is a major headache.

You could get around the unreliability of player hosts by providing hosts for these lobbies. Then you start to have a very client/server -ish layout and you can start considering client/server -ish protocols. Like websockets. Which would be easier IMO, as that is already a lot more common than WebRTC.

So if you are willing to host servers for your player base, or provide players with server software they can run on their hardware, then websockets might be a better fit in your scenario. The server software CAN be built using Rust and webrtc-rs as well. For connection establishment with WebRTC, you'll need some kind of server to exchange service descriptors between your players, or you are left with players having to send base-64 strings back and forth with their session descriptions.

Considerations for why you want to use/avoid webrtc-RS:

If you do decide to go with WebRTC over websockets, you need to think about the implementation of the server. If you are not a Rust developer, learning it will be a long journey. It will be worth it. But it's going to take you much longer than building it using node.js, when you are already familiar with JavaScript for your game client development. Depending on how much verification/simulation needs to happen on the server/host, you can also share code between client and server, since both of them are JS. If you are writing both server AND client in rust (it compiles to wasm after all), then you get the same benefit. While the server can use webrtc-rs, the client software would still use JS interops to call the browser webrtc APIs.

Frankly, there isn't enough information about yourself in the question. If all you wanted to know, whether it is at all feasible, then yes. webrtc-rs is a perfectly good choice to implement a game server that communicates with clients. But I can't tell you whether it's going to be better than websockets. And I can't tell you whether Rust in general is better (for you).

[codernineteen]

First of all, Thanks a lot for your detailed answer!
Honestly, i didn't know how webrtc works at the moment i wrote this question.
Now I realized that webrtc-rs will be a great choice if i build client side project using wasm as you mentioned.