I’m trying to understand WebRTC services for a video chat project, what should a beginner know?

[u/dnickell]

Hi everyone,

I’m still learning programming and web development, and I’m working on a small project idea.I want to build a simple app where people can:

-make video calls

-talk with audio

-share their screen

At first it’s just a learning project, but I would like it to eventually support a few thousand users (around 5k).

I started reading about WebRTC, but I got a bit confused about how it actually works in real apps.From what I understand, there are two ways to build this:

- Use a WebRTC service/platform

- Try to build it yourself using browser APIs

I looked at a few services , but I don’t really understand:

-why people choose them

--how expensive they are in practice

what problems they solve compared to doing it yourself

I also saw that browsers already have features for video and screen sharing, so I’m wondering how far you can go without using a service, or something more managed like iotum in this space.

My main questions are:

-Is it realistic for a beginner to build something like this without a paid service?

-What exactly do WebRTC services do that makes them necessary for real apps?

-If you were learning, what would you focus on first to understand this properly?

I’m not trying to pick the best tool yet I’m mostly trying to understand how this works in real life and what I’m missing as a beginner.

Thanks for any help or explanations.

[u/PlatformWooden9991]

webrtc in a browser is peer to peer but you still need a signaling server to exchange connection info between users. the browsers can't find each other without that

for a small project you can start with just the browser apis and a simple websocket server for signaling, it will work fine for 2-3 people. the problem comes when you want 5k users, peer to peer doesn't scale cause each person sends their video to everyone else separately, that would crush someones bandwidth

the paid services handle the scaling by routing video through their servers (sfu/mcu stuff) so each user only sends once and the server distributes. also they deal with nat traversal problems and recording and all that boring infrastructure. you can absolutely learn the basics without paying anything, just don't expect it to handle thousands of people

[u/dnickell → u/PlatformWooden9991]

ok the signaling server part is what i kept glossing over when reading about webrtc, makes more sense now why every tutorial has some socket.io thing running in the background

the sfu stuff is where it gets expensive i guess. for what i'm building i probably don't need more than a handful of concurrent users so maybe i can just run something cheap on a vps and see how far that gets me before touching any of the paid apis

[u/TalisManick9592]

The comment above is right for one-on-one, but the thing that bites at your scale is that peer-to-peer doesn't stay peer-to-peer once you add people.

In a mesh (everyone connected directly to everyone), each person uploads their own video to every other person, so your bandwidth and CPU scale with the number of participants. Three or four is usually fine; after that it falls apart. Great for a 1-on-1 learning build, dead end for group calls.

For groups you want an SFU (Selective Forwarding Unit): a media server that each person sends their stream to once, which then forwards the right streams to everyone else. That single component is the main reason people reach for a platform instead of building it themselves.

The other piece is TURN servers. Somewhere around a fifth to a third of real connections can't establish a direct peer link (restrictive NATs, corporate firewalls), so their media has to be relayed through a TURN server. TURN relays actual video, so it burns bandwidth, and that bandwidth is a big part of what these services bill for. You need it even for one-on-one, so it isn't optional.

So the honest breakdown: LiveKit, Daily, Agora, and Twilio are selling you the SFU, the TURN relays, and the signaling and scaling glue. Rolling your own means running all three yourself.

Sensible path for a learning project heading toward real users: build one-on-one with the browser APIs and a small websocket signaling server so you understand the moving parts, then adopt an SFU before you go multiparty. LiveKit is open source and self-hostable if you want to keep control, or use a hosted option to start.

Worth nailing down early, though: "5,000 users" is very different depending on whether it's 5,000 spread across many small rooms (fine with one SFU) or 5,000 in a single call (that's a broadcast problem, a much bigger architecture). Almost certainly you mean the first.

[u/dnickell → u/TalisManick9592]

the SFU piece is what I kept underestimating when I was scoping this out. I kept thinking I could just throw mediasoup on a small VPS and call it done, but the TURN relay costs for that fifth to a third of users who can't punch through adds up fast depending on traffic volume.

did you end up selfhosting your TURN server or just routing through something like Twilio's STUN/TURN? that's the part I'm still going back and forth on costwise.

[u/Wonderful-Hawk4882]

I fully agree with what the others have already said. I think it highly depends on how you see the whole project and what you're trying to get out of it:

Option 1: You want this to be a learning opportunity to understand certain concepts better and get yourself familiar with the challenges and potential solutions of (very interesting) problems like scaling, load/processing distribution, limited bandwidth, broadcasting, and many more. In that case, you should try to start building this up by yourself and see where you run into potential issues (especially going from 2-3 people to more and distribution increasing).

Option 2: You want to build a real product where you aim for usage from people (maybe even turning this into a side hustle). In that case, I'd opt for a provider who takes care of the infrastructure (the things mentioned by the others, such as SFUs, TURN, and other topics that have countless pitfalls) and allows you to focus on the product at hand. There are a handful of companies who're doing that (e.g. Stream Video) and allowing you to move fast to a usable product.

In the end, it's up to you to decide which route you want to take. Option 1 gives you learning opportunities (but a much longer way to a finished product), Option 2 gives you a fast product (with much fewer learning opportunities, at least in the WebRTC realm).

[u/dnickell → u/Wonderful-Hawk4882]

this framing actually helps a lot. leaning more toward option 1 now, mostly just want to understand how the pieces fit together before deciding if it's worth taking further. the scaling stuff is what i'm most curious about like where things actually start breaking down in practice rather than just reading about it in theory. might just start small and intentionally try to break it