Hi!
My name is Arnaud Budkiewicz
I am Senior Director of Engineering at RingCentral, and W3C Member.
Along the way, I’ve built 5 different products and platforms based on WebRTC.
Today, I am going to talk about my experience delivering an Electron-based desktop application that heavily use WebRTC.
<NEXT SLIDE>
People love apps!
On MOBILE, an average person has 40 apps installed on his phone.
But in most cases, really use 18 of them on daily basis.
<NEXT SLIDE>
On Desktop, even if both Apple and Microsoft have their App Store to extend users appetite for apps
The behavior is different
And Businesses want full control on what their users install on their devices.
<NEXT SLIDE>
WebRTC runs in browsers,
but what if you want to build a desktop app, out of your web application?
2 options are available
PWA as in Progressive Web Applications,
a quick and easy way to distribute your existing web app on the stores,
and get installed on a PC or a Mac
But the most popular one remains Electron
<NEXT SLIDE>
You are in good company with Electron
Microsoft Visual Studio Code is a reference
But for RTC Applications, you will find Slack, Messenger, Whatsapp, Teams, Discord
And of course, RingCentral
<NEXT SLIDE>
So what is Electron?
The “simplest” way to build from a Web App
a desktop app for Windows, Mac, and linux.
<CLICK>
Electron = Chromium (WebRTC) + nodeJS
<CLICK>
So your Electron App is a function of Electron, the version you pick, your WebApp, and eventually, your Native Modules
<CLICK>
Your dependency tree is your electron app, as a container for your Web app,
coming with your native and electron modules, and a specific version of Chromium and within, WebRTC.
<NEXT SLIDE>
What can go wrong with Electron?
<NEXT SLIDE>
Your Web App has ONE MORE browser to support: your Electron App
In the case of OUR desktop client, it Triggers a different screen sharing implementation,
different portion of code, different features
This browser is always older than the latest Chrome or Edge,
But is not not 100% exactly Chrome
And must be integrated and tested with your Native Modules
Your Native Modules expose one API to your Web App
but have different implementations Windows, Mac
and hardware specificities, like GPUs
Your Native Modules usually work with only one given major version of Electron
So it has to be tested multiple times, as a component, with an integration test app, end-to-end with multiple versions of your Web App
<NEXT SLIDE>
Another pain point is the Upgrades.
Both your Web App and your Electron Container can be upgraded separately
But they have different methods of deployment
An app server upgrade for one, the distribution of an IT package for the other.
An upgrade of Your Electron App will probably require a restart, to reload the native modules, and expose the new API
So there is a solid upgrade experience to build,
to not disrupt the user,
but guiding him through the upgrade process.
<NEXT SLIDE>
Another pain point is the dependency management.
When things go wrong, this is a complex onion to debug, and you may need to talk to different open source communities.
For Electron you ll need to report on github, and use slack and discord to socialize and discuss it.
Abre in mind that the community support only 3 versions.
Chromium its own bug tracker, and Electron can cherry pick a few minor releases of the same version of Chromium
If you are facing a WebRTC issue, that’s the hardest one, you need to touch all the layers, and discuss with the 3 communities.
<NEXT SLIDE>
So it’s very important to understand the entire release cycle.
And Chromium has just moved to a release every 4 weeks, so Electron has change its cadence from 12 to 8 weeks now
Picking every even number of Chromium.
Fortunately, Electron increased the supported Electron versions from 3 to 4, until May’22 (E19)
More frequent releases means smaller releases and you will get Chrome fixes and feature quicker.
<NEXT SLIDE>
As an exemple, Electron 16 has been released 2 days ago
It comes with Chromium 96
And the supported version are 13 to 16
Again, in May 2022, the Electron community will support only 17, 18 and 19.
<NEXT SLIDE>
Now, let me give you a real example of bug tracking we experienced.
VP8 is an excellent codec for video, but for screen sharing, in the context of business meetings, when people mostly share presentations, and expect the remote participants to see a crisp image, our research proves that H264 provides a better quality than VP8.
Among others, this issue was in our way to use H264 for screen sharing.
<NEXT SLIDE>
Now, How to identify the release train of the fix in WebRTC, then Chromium, and Electron?
First, you need to find the patch submission.
Get the commithash from the patch submission, or in the issue tracker if they have been linked together, you will find a comment from bugdroid.
<NEXT SLIDE>
Enter the commithash into cdash and voila
<NEXT SLIDE>
Sometimes there is a backport in the current stable release, like in this exemple.
Just Repeating the same steps will give you the minor release in cdash.
<NEXT SLIDE>
Now, where this commit landed in Electron?
A quick look at major release notes will tell you which version to look at. In the current example, E11.
Then you can find the release notes of all the minor releases of E11.
In that case, Electron 11.0.0 already contained the fix we are looking for.
Sometimes Electron also cherry-pick some Chromium patches, mostly related to security.
<NEXT SLIDE>
Now that you master Webrtc bug tracking in Electron,
let’s talk best practices.
<NEXT SLIDE>
Test, Test, Test!
Test all your upgrades, combinations, your backward compatibility
Test your performance, your media quality, during dev, regression, in production
Test Electron Beta versions
Upgrade as fast as you can on the latest Electron stable version
Go with a Custom Electron strategy ONLY if you have the resources, dev and QA
<NEXT SLIDE>
Contribute back!
You don’t want to maintain your own build for too long, so report issues early, use tools like this very handy bisect python script
that let developers find the exact version of Chromium that introduced the bug they are facing.
For more information, I recommend this video on WebRTC-Course.
<NEXT SLIDE>
Also, contribute by Testing experimental features
One example from RingCentral: RED, an IETF RFC that describes an audio packet duplication mechanism to fight against packet loss.
Jitsi supported Philipp Hencke’s contribution, we performed Extensive lab testing, and shared our Internal User feedback.
RED is now GA in Chrome 96
<NEXT SLIDE>
What if you need to go further, pushed on the cutting edge by users who want more and more AI based features
<NEXT SLIDE>
You may consider building your custom Electron like we do.
It allows RingCentral to have our own desktop capturer, run native modules as audioworklets,
Expose a new API to run native modules to apply video effect and filters in the WebRTC breakout box
And finally, create audio dumps to help us investigating audio issues.
<NEXT SLIDE>
All these AI-based features come with a very high price on the CPU and Memory footprint,
so you may consider a similar solution as Microsoft Teams announced recently,
mixing native code with javascript code using a new feature from Windows 10: WebView 2
<NEXT SLIDE>
Under the hood, WebView 2 is an instance of Microsoft Edge, based on Chromium, that has the exact same release cadence.
This new approach is interesting, if like us your application is a mix of real-time communication features, and asynchronous communications.
You may have an alternative that allows you to have
the best for each of these worlds,
well, on Windows only for now.
<NEXT SLIDE>
I am now ready to answer any question you may have.
<NEXT SLIDE>