What does it take to call yourself a WebRTC Developer? Or, if you’re looking to hire or contract a WebRTC Developer, what exactly does that mean?

The term WebRTC Developer can actually be a pretty broad term. It’s best to know what you need before hiring anyone who uses that title. In my experience, there are five different types of WebRTC Developers:

  1. JavaScript CPaaS Integrator
  2. Mobile Video Developer
  3. Open Source Media Server Developer
  4. DevOps Scaler
  5. WebRTC Protocol Engineer

All of these are valuable roles, but most teams don’t need all of them. You may need just one or you may need many, based on your specific application architecture. 

Understanding the distinction between these roles is important in any of the following scenarios:

I’ll cover each of these types of WebRTC developers in turn below.

The JavaScript CPaaS Integrator

This is probably the most common type of WebRTC Developer out there. If you’re just getting started, this is probably the person you need. These developers should have significant front-end web development experience with frameworks such as React, as well as server-side JavaScript technologies such as Node.js.

I use the “integrator” distinction here to indicate that these developers are most likely working with a commercial WebRTC media server. We typically refer to this as a CPaaS, which stands for Communications Platform as a Service. These services include companies like Vonage, Twilio, daily.co, and many others.  

What the CPaaS’s all share in common are JavaScript-based APIs which they advertise as being easy to use for any JavaScript Developer, with minimal knowledge of the low level details of WebRTC needed.

How successful those APIs are at making it easy for a JavaScript Developer to build a video application is up for debate, perhaps, and certainly varies across each CPaaS. Each CPaaS also has different pricing models and feature sets. A lot needs to go into the decision of which CPaaS to use in your application!

The ideal JavaScript CPaaS Integrator has experience with one or more of those APIs. They should also carry a decent understanding of WebRTC protocols, even if the JavaScript APIs shield them from having to know the details. This is because even if you are building a relatively simple video application on top of a CPaaS, the work will still be much smoother if you have experience with best practices around building, testing, deploying, and scaling video apps.

So while I do not believe that any JavaScript Developer can learn to become a good JavaScript CPaaS Integrator in short order, it is a prerequisite that they have a solid foundation of JavaScript web development skills.

The Mobile Video Developer

This type of WebRTC Developer is similar to the JavaScript CPaaS Integrator, with the main exception that they prefer to focus on building mobile applications instead of web applications.

Using frameworks like React Native, many JavaScript Developers can also become mobile developers with relative ease. And since CPaaS providers typically offer mobile specific libraries and APIs to build video applications, Mobile Developers don’t have to know all the finer points of how WebRTC works if the mobile API shields them from it.

However, just like the JavaScript CPaaS Integrator, the more experience a mobile developer has with video APIs, the better and faster their applications will be. This combination of experience is harder to find, and we are lucky to have multiple members in our WebRTC.ventures team who fit the bill. That being said, if you can’t find a mobile developer with video experience, I would favor using a JavaScript mobile framework and a JavaScript Developer who already has experience with WebRTC video applications.

The Open Source Media Server Developer

I have not thought of a more elegant term to use here, but the distinction I’m trying to draw between this role and the JavaScript CPaaS Integrator is how comfortable the developer is with WebRTC and with managing their own media servers.

There are many open source media servers used in WebRTC applications, such as Janus, Jitsi, and the more outdated Kurento. As is typically the case with an open source library vs a commercial API, these open source media servers offer much more flexibility and capability than commercial APIs. But they require more technical expertise to integrate into your application. 

An open source media server needs to be deployed to a cloud environment and managed. This is opposed to a commercial API that does all the scaling behind the scenes for you (for a price). This means that an Open Source Media Server Developer should be someone who has experience with open source projects, understands details of WebRTC like the signaling process, and has enough cloud deployment experience to set up the infrastructure.

In more complex implementations, the Open Source Media Server Developer may also work directly in the code base of the open source media server, building plugins and new interfaces or committing code back to the open source project. This means they need more than JavaScript knowledge, and likely have some combination of experience in Java, C, or C++.

The DevOps Scaler

The DevOps Scaler is a role that overlaps somewhat with the previously described Open Source Media Server Developer. The distinction I’m drawing here is that building a highly scalable video application on your own cloud infrastructure is no small task.

Even leveraging the built in features of cloud providers like AWS and Google Cloud does not do all the lifting that a video application will need.  The DevOps Scaler is likely building their own Docker images based on what the Open Source Media Server Developer has specified, and implementing Kubernetes and auto-scaling tools. 

In addition, the DevOps Scaler is going to put in monitoring and testing solutions that are standard to any highly available web application, or others specific to video applications (such as testRTC.com.)

This combination of video knowledge, network and cloud debugging, and cloud experience is not easy to find and takes time to learn. We have multiple people on our team who can do it, but only our more advanced clients need these roles. If you’re just building your first prototype and gathering investor funding, you may not be ready for this role yet (even though we will still want your application architecture to take future scaling needs into consideration!)

The WebRTC Protocol Engineer

If you love counting individual packets, working with complicated build systems, analyzing network traffic, writing C or C++ code, and debating the finer points of video and audio compression protocols, then this is the job for you.

The WebRTC Protocol Engineer is the most low level of the WebRTC Developers. This is the most rare person to find with experience, and luckily is also the least likely role you need. Most of what a WebRTC Protocol Engineer would do for you is already built into the commercial and open source APIs. However, this person is still very valuable in certain use cases.  If you need to do some very unique implementations or even make your own customized version of WebRTC (Danger!), this is the person you need to find.

Parting words

In a competitive economy, finding the right technical talent is never easy. Finding tech talent with niche knowledge or experience such as WebRTC is even more difficult! That’s why we train and hire the best WebRTC Developers — of all kinds. Leverage our team of experienced professionals for your video application – contact us for a quote!

Recent Blog Posts