Best of Breed WebRTC Software Components

Putting you in control over what gets into play in your WebRTC project

In every WebRTC project there are the following areas you need to deal with:

• Client side application and cross browser/platform support
• Server side for connecting peers
• Creating the media connection and overcoming NATs
• Handling additional features such as multi-party, recording…

The approach to this can be:

• Do-it-yourself
• Best of breed – use some 3^rd party components (cloud or SDK) and build the others yourself
• Use a complete API platform that will solve all of the above

The third option of using an API platform is covered in-depth in Tsahi’s report, it is money well spent if you are in a search for an API platform or thinking if you should use one. This option is not covered in this post.

I want to talk more about the first two options and how they relate to the WebRTC API compatibility challenge.

WebRTC is close to becoming a standard but it is also going through constant change and updates. This will continue further to the ratification of WebRTC 1.0 as new capabilities will be added, ORTC brought to play and other changes made. Constant updates on this are provided on webrtcstandards.info, a site I’m running together with Dab Burnett.

Add to the mix the business objectives the browser vendors have and the impact of these on the implementation.

The result is that a WebRTC client application will not necessarily work on all browsers and will not always survive browser version updates. That’s why the pure do it yourself option becomes a pretty tedious choice. It does fit some; you just need to know what you are getting into.

WebRTC Wrappers

What is a WebRTC wrapper?

It is a layer of code that comes on top of the native WebRTC API. You add it to your client application and it hides the differences and compatibility issues between browsers.

The reason WebRTC wrappers such as PeerJS have merit highlights the incompatibility issue in WebRTC.

In this context, the 2 interesting things PeerJS gives developers are:

Client API – A wrapper on top of WebRTC that eliminates the differences between browsers and between browser versions

PeerJS-Server – This is a Node.JS based server that takes care of creating the connection between the peers. It deals with signaling only and doesn’t touch media or provide TURN functionality. PeerJS-Server is open source with a permissive MIT license so you can host the PeerServer yourself and make changes to it as your application requires.

Another option is to use the PeerServer Cloud for up to 50 concurrent connections free of charge.

Conclusion

The optimal goal for WebRTC should be that Web developers will be able to easily add WebRTC features to their applications. Throw in some media services as they see fit and not need to worry too much for client side WebRTC API compatibility.

Reality is that for the common Web developer, we are not really there yet.

Challenges are both client side API changes and the server side that requires some domain specific know-how.

The best of breed option of combining several solutions such as PeerJS, NAT traversal services such as the one Twilio offers and other media services is a good option for those that know what they are doing and what they need.

Being best of breed, it gives the developer more flexibility while reducing development efforts compared with the do-it-yourself option.

To some extent, it also reduces the vendor lock of the full-blown API platforms option.