I recently had the opportunity to speak at the Mux TMI event about about building realtime video products.
Jenny: Next up, one of our partners is going to demo the very first application built with the real-time API. This is the one that Phil mentioned earlier, Mux Meet. Because we’re building a video product for developers, of course, our team wanted to use the tool ourselves. So, the Mux team built a basic meeting app that we could use for our daily stand-ups. Here you can see some of those early and somewhat embarrassing screenshots from that. But it helped us find and fix bugs quickly, and it helped us improve the SDK along the way. But what we needed to do was really accelerate development so that this tool would be ready for our whole company to use and for all of you to use as a reference project, and that’s where our partner Quarkworks comes in. Brett Koonce is the CTO and co-founder of Quarkworks. He and his team have experience building several products using WebRTC, including Houseparty and Reddit Live. So, we thought it would be a perfect fit to take our team side project to the next level. He’s here to tell us a little bit more about that. Welcome, Brett.
Brett: Hello, and thank you all for having me. What we’re going to show here first is just a demo of how to set up the whole Mux Meet experience. At a high level, we’re simply going to
git clone the repo. So, to pull the code down from the internet. Next, we need to connect to the Mux API. So, for this, we’ll need to set up some keys and signing access stuff. So, we’re going to copy the example environment file over, and then from here, we’re going to edit it for our specific implementation. So, we’ll jump over to the Mux API Dashboard, the spaces API, and we’ll set up a set of API access tokens. This is needed for all projects on Mux in general. We’ll generate the token. We’ll copy it, then we’ll paste it into our project, and then repeat this process as well for our secret key. This real-time streaming API also needs its own little set of signing keys. So, we’re going to also need to generate a public-private key pair and add them to our project as well. So, for this, we’ll use the dashboard again to generate a key, and then once again we’ll simply copy things over to our environmental variables for our project. Here’s the long, ugly one. and violá. Now we’ve done all the configuration necessary in order to take our demo project from the internet and use it ourselves. The final little step we’ll need to do here is to manually create a new actual space to be using for your project, and so, we’ve done that now on the back end. From here, the process should be relatively straightforward. We do our standard npm install process. We pull some plugins and whatnot down from the internet, and then finally we can launch node in development mode and see stuff locally. So, we’ll load things up here and, wallah, we have Phil appear on the screen. That’s literally all that’s needed, and then just to sort of showcase our tech, we’ll add in another person. So, here’s Jared. I believe they’re talking about code here. So, we’ll actually add the computer itself as a video source, so to speak. So, we’ll share the screen, and there we go. Now we can look at our React app and pair program on it together, and then modify things to our heart’s content. Anyway, this is all pretty turnkey. In just a few minutes, we’re able to get up and running. Thanks again, Phil and Jared.
Jenny: Awesome, thanks for walking us through that demo, Brett. So, since this isn’t your first project that you’ve been building with real-time, can you tell us a little bit more about how you’ve integrated real-time in the past, and the challenges with those projects and how it compares?
Brett: Okay. My experience with real-time technology in general is that things really start off simple, but they get really complicated in a hurry. One on one on a single platform is generally a good place to get started. But then, as you start trying to add more clients and peers to the project, things can really start to get interesting in a hurry. Real-time video technology in general is built up on top of a whole large and complicated set of both hardware and software working together in order to make all this stuff work. As an engineer, I think we sort of love this idea of having clean, beautiful API’s to work with and being able to have the perfect interface. But my experience with real-time tech is that more often than not we have to go in the opposite direction. We have to get our hands dirty and go and down into the internals, dealing with C++ templates or low-level networking details. And then, even whenever our tech all works, deploying into the world brings its own set of challenges. Bandwidth, latency, cloud gremlins. There’s a whole sea of monsters out there that are wanting to eat your packets before they get to the end customer. I’m not going to say this stuff is impossible, certainly not. But real-time systems have a very unique set of challenges that make them a particularly interesting problem to try and solve.
Jenny: Yeah, it sounds like. So, going forward, what use cases or applications do you see your team being able to use the Mux real-time API for in the future?
Brett: To me, videos are an extremely common feature request, especially for consumer apps. People love video. Having said that, my experience is also that people do not have a very clear vision of how video is going to fit into their project from day one or how all this stuff is going to work together on the backend. So, what this means in practice is that, more often than not, you’re going to have to end up rewriting things a few times on the way. So, in the world of startups, you sort of have this concept of innovation tokens. I think this concept can be expressed quite simply as saying, “Are you spending your precious time and energy on the one thing that makes your app unique?” So, to me, the joy of this API is quite simple. We did the demo earlier, and in just a few minutes you were able to get an enormous amount of functionality up and running out of the box. So, on day one, you can have all this. Where you go from there is up to you.
Jenny: Awesome. Well, thank you so much, Brett, and thank you to everyone at QuarkWorks for making this project awesome. We really appreciate it. Thank you. Okay, you’ve seen a couple of examples of what you can do with the API scenes and how it can get out of your way to let you focus on your core business problems, and you’ve got a preview of the open-source project that you can use to get started today, and I hope you do, and I’m really excited to see what feedback you’re going to bring for us.
Thanks for reading brett koonce! Subscribe for free to receive new posts and support my work.