With WebRTC, better stick as close as possible to the requirements, architecture and implementation of Google Meet

When developing with WebRTC, try to stick as close as possible to how Google Meet is designed and architected. That’s where love and attention is given to the source code.

[In this list of short articles, I’ll be going over some WebRTC related quotes and try to explain them]

This is something that I’ve been saying time and time again - when you are developing anything with WebRTC, the closer you are to the requirements, architecture and implementation of Google Meet, the easier your life is going to be.

Here’s why 👇

Browser support

Chrome is the biggest game in town when it comes to market share.

If you want your application to run well on browsers, then Chrome is the first one you’ll be looking at.

But it gets worse/better than that:

• Edge = Chromium = Chrome - same WebRTC stack in there
• Firefox uses libwebrtc internally, which is… the same WebRTC stack used by Chrome
• Same thing for Opera
• And same thing for Safari, which generally ports libwebrtc to work inside their WebKit browser stack

Which leads us to libwebrtc…

libwebrtc

libwebrtc is the WebRTC implementation that Google has open sourced. It is also the one they are using themselves for Chrome and for their mobile applications.

Since it is the one you’ll be bumping into in ALL browsers, it is the one you will be working in front of most of the time assuming you are going to have browsers as part of your service.

What Google cares about

Google cares about Google.

Ignore open source. The open web. Search. People.

A company at the end of the day needs to deal with the fact that it is here to generate revenue for its shareholders. If open source or open web helps, then so be it. If it doesn’t, or there are other interests, then… well… that's what gets done.

Google isn’t maintaining WebRTC out of the goodness of their heart. It is an essential part of the web, but is also a component they need for Google Meet and a few other, less important projects.

As such, the attention of the team maintaining libwebrtc is going to be almost always razor focused on what Google Meet needs in their roadmap. Their bugs. Their features.

Planning to do something Google Meet doesn’t need? Does libwebrtc/Chrome support it or is it clunky or broken in that area? If it is broken, then you are in a world of pain… because the team at libwebrtc probably won’t have the attention span to assist you with it.

When to go against the tide?

That’s a good question.

When should you go against the tide and develop something that is far remote from what Google Meet is doing, with requirements that are different and even go against the requirements of Google Meet on the part that deals with media processing?

I guess the answer is when your team is savvy enough and experienced enough with developing WebRTC products. Not just using open source tools, but in looking at the internals and low level components of WebRTC.

It also greatly helps if they are known in the industry as individuals and known to the team at Google maintaining libwebrtc. When you need things, such personal relationships will be really important.

Sadly, there aren’t many around with that kind of skill set.

👉 That’s part of the objective behind the new Low-level WebRTC protocols course we’ve just launched. Check it out

👉 You should also read about the state of open source WebRTC projects to get a better understanding of when to use something other than libwebrtc and what to do about the server side of your WebRTC application