What is a WebRTC Signaling Server and Why You Should NOT Use AppRTC?

AppRTC isn’t your friend when it comes to developing a commercial WebRTC application.

A WebRTC signaling server is but one of a few WebRTC servers that are needed to build an application. Learn more about WebRTC servers.

I already wrote about the fact that there’s no free TURN server from Google. It seems that I failed to mention the fact that you shouldn’t use Google’s “free” STUN server in production either. Which leads us to this great question on github on AppRTC:

apprtc websocket server down?

The interesting part about this one is that no one from Google commented on it at any point in time.

You see, AppRTC wasn’t meant as a full fledged application, and to some extent, not even as a reference application for other developers. It is mostly meant to be a hello world type of an example.

With a glaring lack of good, simple, popular open source signaling frameworks for WebRTC,
developers sometimes use AppRTC for that purpose.

While I use AppRTC for baselining, I don’t think it is a good starting place for actual development of a real service.

Here are 4 reasons why:

#1 – AppRTC doesn’t get much love and attention

Look at github insights for AppRTC:

See the number of additions and deletions taking place in 2018?

Latest commit? March 2018.

One could argue that this is because the “Hello World” example for WebRTC is already quite polished and working well, so there’s no need to change anything. Or that WebRTC is now stable enough.

#2 – This is just a “Hello World”

Here’s an example of a Hello World js function:

function hello(name){
   console.log("Hello " + name);
}
hello('node.js');

This isn’t a starting point I’d use for writing an application.

The AppRTC application is admittedly larger. Here’s the lines of code count for its github project at the time of writing (not that I’d expect much change to it in 2019):

The problem is in what AppRTC doesn’t include, which many developers want/try to add:

• Android and/or iOS AppRTC apps – these aren’t available from Google. There are 3rd party projects for it you can find on github, but they are even less maintained than the Google AppRTC one
• Screen sharing – it isn’t there. Need it? Add it on your own
• Multiparty – not there either. And if you’d try using AppRTC for it, my guess is you’d end up with a mesh architecture (which for 99.9% of the use cases and most definitely for your use case – is destructive)

#3 – Not built to scale

AppRTC uses a python based signaling server, which is great. The actual signaling protocol selected and used isn’t really documented anywhere, so you’ll need to dive into the code to figure it out if you’ll want to add or modify anything. And you will, simply because a lot of functionality you might want is missing.

The thing is, if you plan on scaling up your service to large number of users, you’ll need this to work across machines – and that’s not easy – or at least not trivial.

At Kranky Geek 2016, Google explained what they did to scale and improve signaling for their own production services. Check out what that means:

Not everyone needs to do things at scale, but many do. Starting for AppRTC places you at the wrong place for growth.

And when it comes to edge cases, it doesn’t cover them all – if ICE negotiation fails, you won’t know about it on the UI, just have it as an ICE failure message in the console log. That’s the example I’ve bumped into when using testRTC with it and closing all ports but 443.

#4 – Don’t iframe or URL to it

Running a service and just need basic meeting capabilities?

Don’t place AppRTC in an iframe of your app or have a URL to it open in another window.

You don’t get an SLA from Google when using AppRTC, and they won’t treat it like a critical service when it fails to run. Throughout the years there have been times when AppRTC was down for one reason or another.

Upwork, for example, used to use a third party free/sample/demo service similar to AppRTC or Jitsi Meet. You had to schedule a meeting with people you work with on Upwork? Click a button, it created a kind of an ad-hoc, random URL for that meeting and opened it on a new browser tab. They were smart enough to replace it with their own branded meetings feature later down the road.

That service that Upwork used? No longer exists. Want to get a signed guarantee from Google that AppRTC will stay up and running and work the same way it does today 2 years from now?

If you plan on running a serious business, host your own communications infrastructure or pay for it.

And you should also remember that signaling is just one of a few WebRTC server types you’ll need to take care of.

Do you have any other alternative?

Not really. Not an immediate one at least.

People are still falling to the trap of using peerjs (see here why NOT to use peer.js).

We used to have EasyRTC and SimpleWebRTC in the past. EasyRTC still gets some love and attention, so you can try it out. SimpleWebRTC is now deprecated – &yet have decided to offer it “as a service” instead.

There are many other github projects offering webrtc signaling. Most of them seem to be projects people built for themselves but never really matured to a robust framework that others have adopted.

I started suggesting matrix, but many don’t really manage getting WebRTC to work well with out.

Then there’s the cloud based services – PubNub, Pusher, Scaledrone, Ably and even Google’s Firebase. These give you robust transport where you can pour your signaling protocol into.

Or a commercial software you can install anywhere such as Frozen Mountain’s WebSync.

In many cases, this will be an each to his own situation, where you’ll just need to develop it yourself or start somewhere and make it your own quite fast.

Then there’s a WebRTC Codelab training 👨‍💻 you can take – I’ve created it in collaboration with Philipp Hancke.