WebRTC requires an ongoing investment that doesn’t lend itself to a one-off outsourced project. You need to plan and work with it longtime.
[In this list of short articles, I’ll be going over some WebRTC related quotes and try to explain them]
WebRTC simplified development and reduced the barrier of entry to many in the market. This brought with it the ability to quickly build, showcase and experiment with demos, proof of concepts and even MVPs. Getting that far is now much easier thanks to WebRTC, but not planning ahead will ruin you.
There are a few reasons why you can’t treat WebRTC as merely a sprint:
- WebRTC as a technology is changing
- The standard and what browsers implement isn’t aligned just yet. There are discrepancies, and while they are getting resolved, this takes time, meaning we’re in a long transition period
- Browsers are investing in WebRTC (or at least the Chrome team is), so browser behaviors wrt WebRTC changes between one Chrome release to another
- Communications vendors have woken up
- Since the pandemic, communication vendors are investing heavily in innovation
- This leads to an arms race in feature sets and capabilities. Things you’ll need to keep up with as well
- WebRTC is a resource hog
- It uses microphones and cameras, it eats up CPU and memory
- New devices (and old devices seen for the first time) may well cause hiccups in your application’s behavior. You’ll be fine tuning, tweaking and troubleshooting your WebRTC code for years to come – assuming your service becomes popular
- Networks are flaky
- WebRTC needs to work on unmanaged networks at all times
- Often enough, users will fail to connect. Or have quality issues. You’ll need to help them out. A lot more than with “simple” web sites
I like using this slide in my courses and presentations:
These are the actors in a WebRTC application. While the application is within your control and ownership – everything else isn’t…
- Users are finicky and they use their own weird devices to connect. They also come with different levels of technical understanding and savviness
- Networks are unmanaged, and you can never know in advance where the user is, if his network is good or bad, and what kind of firewalls and other nasty devices along the route are going to hinder communications
- Browsers don’t adhere to your development schedule. They have their own pace, which is breakneck speeds of around 4 weeks between one release to another
Planning on using WebRTC? Great!
Now prepare for it as you would for a long marathon – it isn’t going to be a sprint.
👉 Things to in your preparation for the WebRTC marathon include:
- Getting skilled teams; most likely growing them inhouse and training them with WebRTC
- Tool up. Take care of long term needs of testing and monitoring (you definitely should check testRTC)
- Use a third party CPaaS to own most of the WebRTC infrastructure headaches if you don’t have the skillset to do it (and yes, I have a report for that)