“Why do people refuse to use WebRTC? Is it really its quality question?”

As a CEO who has 15+ years of software development, I take part very often in the first call with our clients. Very often, I can hear something like “We should like to move away from WebRTC because it’s not stable. Can you do it?” It’s not always easy for me to continue a conversation after such a statement, so I decided to write some generic answers for such questions. 

First of all, if we are talking about Web solutions the right answer is “no”! You have no other way to develop real-time communication with a more or less significant amount of transferred data except using WebRTC. 

WebRTC is the ONLY streaming protocol available for your Web application and all repositories from GitHub cannot change it, so do not waste time searching for magic libraries.

On the web we have good old HTTP(s) queries, WebSockets, and WebRTC for communication and that’s it. You may ask what about WebSockets, can we use them? — Partially yes, but WebSocket in opposite to TCP sockets are NOT streaming protocols, WebSockets just allow sending packages in both directions between server and client. WebSockets can give you real-time in-text chats and that’s it. 

Now we know that we can’t go away from WebRTC if we are doing something like video calls. But why so many video calls Web solutions are so bad? Does it mean that we still have no possibility to implement good-quality Video calls in our browsers? Actually, no, we have everything to make calls and other real-time communications of perfect quality. Take a look at Google Meet for example.

So what is the difference between your buggy WebRTC and Google’s perfect WebRTC? The answer is so simple: the difference is in the developer’s qualification. 

WebRTC browser API looks so simple and easy to learn and many front-end developers are starting to play with it and get immediate results on their local networks or their machines. But WebRTC is actually not something to develop in the browser. It’s more about infrastructure. Browser code is very simple and straightforward, but the infrastructure to make connections possible is the key to success. So it’s better to hire C# developer who isn’t so skilled in React but has knowledge about operating systems and networks rather than React developer with perfect UI/UX skills who knows nothing about networks for your WebRTC project. And be ready for expansive infrastructure and expansive development/deployment services.