3 ms·
Interesting, I was recently researching the idea of using Webrtc on the backend. Don't have to worry about setting up DNS, SSL, etc on each host, and could spin
by Keverw 7y ago
Interesting, I was recently researching the idea of using Webrtc on the backend. Don't have to worry about setting up DNS, SSL, etc on each host, and could spin up and down as needed. I would use a signaling database/api microservice though. Got an idea for an app related to virtual worlds, and was thinking webrtc on the backend would be neat to use for the instances in the backend.
One of the downsize though is opening up firewall ports. So if you wanted to run instances in a more locked-down environment using containers... So be nice if you could just open up a few ports and have multiple connections go over them. Looks like not many projects are trying this though, so not sure how well of an idea this is though, but something about it just seemed neat and might possibly be an advantage. For the voice stuff you are forced to use webrtc anyways it seems since more optimized for audio than using regular WebSockets as far as I know.
https://github.com/node-webrtc/node-webrtc/issues/584 https://github.com/node-webrtc/node-webrtc/issues/584
Another idea I was thinking is to run some services inside of Kubernetes, and the services needing webrtc outside of Kubernetes with an API in-between. Nothing solid yet, just still exploring the idea though.
- Sean-Der 7y agoHey everw, you should join the Slack! I would love to build this/make it work for you. I really just want to pull in everyone that is enthusiastic/interested in the space, if we get that energy all in one place I think we can make magic happen :) I would love to see WebRTC take off on the backend. I think when building services it could go a long way to creating resiliency/reduce complexity. When you start designing things with the WebRTC state of mind (vs starting a Websocket and just assume everything is ok) you really end up with better stuff. I think today your best bet is doing the port ranges. The single port mode is possible, but you add some extra logic. Like if you have two remote peers behind the same NAT, you really don't have a way to distinguish them from each other. My plan was took look at the SSRCes of the packets, and hopefully you don't have any duplicates between PeerConnections. I don't think the existing C++ code base is flexible enough to do this currently.
- Keverw 7y agoNeat, I might check out Slack. Kinda annoys me how every workspace has its own login and just find chat apps somewhat distracting to run but I know a lot of projects use Slack. I'm more of a Node and Typescript person though, but I know Golang is popular. I want to try to run babylon.js on the server side using its nullEngine to be authoritative. Still doing a lot of research though, so not sure if it will end up being a actual project. There was another project in Go I came across relating to WASM too that looked interesting. I know some projects or companies they are a polyglots though, whoever starts a new project picks whatever, but I'd prefer to limit things 1 or 2 languages on the backend as I think code reuse and would make it more maintainable. Like if it grows from an idea to a company, seems like having everyone on one tech helps with hiring and moving around resources. But I feel whatever you pick probably going to be locked into it for a while, like picking the right database but I know some projects run 2 or 3 databases... Social functions might use one, billing might be another one, search is another one. But yeah I liked WebRTC for voice for sure, but wanted to use it for other parts of the system too for the instance simulations to be able to connect to each other directly, but I guess I could always just use raw IPs too but it seemed like WebRTC gives you some things built-in for free like securing the data channels. I was thinking if I used WebRTC for voice only, then all I'd need to do is write some sort of API running inside of the cluster and just run the WebRTC servers outside of the cluster, since wanting to mix the audio on the servers to cut down on bandwidth to users, and also increase privacy a bit for users.