WebRTC's Endgame: Being a Part of BaaSWebRTC's Endgame: Being a Part of BaaS

Will Backend-as-a-Service help developers take advantage of WebRTC?

You guys who come here to NoJitter to read are used to these stupid acronyms: IaaS, CaaS, UCaaS.

The latest in a row of acronyms is BaaS. It has nothing to do with voice or UC, but it has a lot to do with BYOD (yet-another-acronym) and at how the technology world is evolving around us.

BaaS, also known as "Backend-as-a-Service," is all about making it easier for mobile developers to build mobile services. It does that by offering developers a lot of capabilities they need in their backend: things like push notifications across mobile operating systems, persistent cloud storage, social networking services, etc.

Want a few examples for BaaS? Check out the directory of Developer Economics. A couple of them actively promote their usability for WebRTC, but not in a tight enough integration for my taste.

By employing BaaS, a developer can focus on his or her mobile app (native or HTML5), and then just consume all the stuff they need in the app that cannot be done locally and requires a server. It reduces development time, but also maintenance work around upgrades, scaling, monitoring--classic DevOps.

What I think is missing from BaaS is messaging, or more accurately, the ability to add voice and video communications. The closest platforms are the WebRTC API Platforms, but these are so focused on WebRTC and VoIP that the other critical needs that make BaaS so enticing to developers get lost in the noise.

Moving forward, what I think needs to happen, and probably will, is having BaaS vendors come with an additional feature in their toolset--WebRTC. Once this happens, WebRTC will have a lot more reachability into the market and will be taking an active part of mobile-first and mobile-only types of services.