What's something your current-self could tell your past-self before you started building a WebRTC service or platform?
WebRTC is a standard, but the 😈 is in the details 😅.
As part of a former job, I built a video calling app on top of an infrastructure provider (I'll leave out the name to keep this friendly 😄). While we had lots of control around architecture and scalability, we also had to maintain and control the hard parts of running a video service. And, this was all while trying to build an app with a user experience and capabilities that was differentiated from Zoom and Webex. If I could do it all over again, I would opt to use an API provider simply to manage the infrastructure and scalability for me.
So, yes, WebRTC is a standard and setting up a basic 1:1 peer-to-peer call is relatively easy, but there's a lot more to it than just the APIs.
Get ready for the amount of acronyms you'll be learning and relaying on a daily basis. :)
re: @ashley's comment directly above.
I've been thinking about all the acronyms that we encounter in WebRTC and beyond.
I'm wondering how helpful an acronym glossary might be for the peerConnection community.
❓️Do you think it's helpful for developers who are working with WebRTC directly? Or is it something that you just get used to and don't really think about on a regular basis.
❓️ Would it be helpful for developers who are adding live video to a site but not necessarily working directly with WebRTC? Or is it not necessary if you are working at a higher level?
I think we get used to them when working with them on a regular basis, but I also think there are a lot of acronyms that cover the entire video dev community and just because you're really heads-down on one part of the stack doesn't mean you'll be as familiar with another part. So I can see it being helpful all-around even to engineers experienced in this area of streaming media and VERY helpful to developers in general and not working direct.