Engineering at Discord with Justin Beckwith

0:00Discord is a popular communication and streaming platform that was originally launched in 2015. It was first popularized in the gaming space, but its user base has grown to include a broad array of communities, businesses, and social groups. Justin Beckwith is the Director of Engineering at Discord. He leads engineering for the Platform Ecosystem Organization and has played a pivotal role in developing Discord's embedded app SDK. Justin joins the podcast with Sean Falconer to talk about leading engineering at Discord. This episode is hosted by Sean Falconer. Check the show notes for more information on Sean's work and where to find him.

0:50Justin, welcome to the show. Greetings, Sean. Thanks for having me. Yeah, absolutely. So you're a director of engineering at Discord, leading platform ecosystem. I wanted to just start off by having you kind of walk us through, walk myself through some of your journey to Discord. And what was the state of the product as like a developer platform when you joined? Yeah, so I had a really unique opportunity in joining Discord. It's coming up on three years since I've been here, which is hard to believe. And before this, most of my career was really in enterprise software. So I'd worked a lot on cloud developer platforms, had an opportunity to work on Azure, on Google Cloud, a couple of different platforms there.

1:27But this was the first consumer platform I had a chance to work on. And one of the things that really drew me to it was that there's this large, vibrant, excited kind of, there's just a whole slew of developers that were already there. They were already building things, building chatbots, slash commands, rich presence, all kinds of any way that they could extend what was on Discord, people were trying to do it. And it was kind of a unique opportunity to walk in where that ecosystem had been defined. It was kind of core to the product and I'd have a chance to come and work on something that inspired people.

2:00How do you think working on something where you're building essentially like, you know, still building like a developer platform. So this is like designed for developers, but the sort of end user of the developer is going to be consumer. How do you think that might be like different from the types of work that you do versus, you know, B2B sort of technology SaaS or some sort of, you know, managed service or something like that? It's a really interesting question. I think that there are a lot of places where they're similar at the end of the day, you know, enterprise developers are still developers.

2:29consumer developers are developers, and we want a lot of the same things. We want great documentation. We want walkthrough guides. We want SDKs, command line tools. I'd say the places where it was uniquely different really came around velocity and stability. So I think on an enterprise platform, you kind of have it beat into you where it's like, you want to know your roadmap. You want to have that three-year roadmap. Some places I've worked, we had public 12-month roadmaps where we talked about what we're going to release. There are these very, very hard and fast rules about how you break things and never breaking the platform.

3:01And in a lot of cases, and sometimes in enterprise software, crummy UX is okay. The number one thing that you need is the ability to get the job done versus make the API exist. And then if we want to make it easy to use, or if we want to go have great UX behind it, then we can go focus in there. And I think what I've found is that the expectations on a consumer-facing platform for developers, they're a little bit different, right? Like it's expected you're going to move faster, it's expected that just the nature of the product itself, it's not going to be as predictable where we're going to go from one quarter to the next because we're trying to chase users and we're trying to react more quickly than a large enterprise scale platform.

3:39Yeah. You and I were chatting before we started recording. We were both at Google at the same time. You worked in cloud. I worked in cloud. I think cloud, you're dealing with like a 18 to 24 month public roadmap. Any breaking change of an API is probably going to be like a year and a half minimum deprecation cycle or something like that, that you're going through. Do you think when you're building like a developer platform where the end user is going to be consumer, are people sort of more forgiving of those kinds of breaking changes or are the same expectations there? Yeah. So I think that this is where it's like the same expectations are there for the end user.

4:14We can't do anything that's going to break end users, right? That would be a complete failure for us. And we absolutely don't want to willy nilly introduce breaking changes. And so that's one of the things with the activities platform that we've put out there that we've been very careful, right? We've worked with a lot of partners. We've spent a couple of years actually building this thing out, getting it stable, making sure that we had a good handle on the primitives of it. But just because it's a consumer platform doesn't mean that you can just go break things. It just means the cycle can be a little bit different.

4:44I think that the industry just moves a little bit faster. Yeah. I think one of the things that's really interesting about Discord is that it was designed, from my understanding anyway, to be extensible and sort of adaptable from day one. And I think it's really hard to build a product that has a singular focus, has product market fit, and be really good at that while also being good at being extensible and being extended in ways that probably the founders never, ever thought anybody would extend it in that way. Can you talk a little bit about, as far as you know anyway, the decisions behind that?

5:18And what was particularly difficult about pulling some of that stuff off? Yeah, I mean, I think that you'd mentioned it being maybe extensible in ways that, you know, maybe the founders didn't think of. That's actually not true. Jason and Stan, the co-founders of Discord, they constantly talk about the value of it being an extensible platform and how that was one of their goals actually from day one. And I think that made it a lot easier for me to walk into this job where they had this kind of running head start. I'd mentioned it already They had this vibrant community of passionate developers.

5:48And it's because it was built like that from the beginning. And they kind of erred on the side of make it open, let people use the platform in the way that they're going to use it. Early on, we might change some things. We might break some things. And that's OK. We know that people are kind of coming in and just trying to build against it. But they definitely started with that philosophy of keeping everything open and then just seeing what people would build. One of my favorite things when I joined here, we have, of course, all of our communication at Discord is through Discord. And AppCity, the channel where we communicate most with the team, has this kind of channel description on it that says, you honestly wouldn't believe the things that people make.

6:22And it's really resonated for me. And it's turned out to be entirely true as you see the stuff that people just kind of come up with and build. Yeah. It's kind of interesting also in a time where companies like Reddit and X or Twitter have actually closed down their APIs. It feels like Discord's kind of going the other way where they're actually leaning into this even more. And it's becoming, you know, it was already a developer platform, but there really seemed to be like investing resources into that. You know, given that they already had sort of this thriving developer ecosystem when you joined, like what were some of the like focal points and areas that you like initially jumped into and thought either they were a problem area or maybe there were things, you know, they weren't doing today that needed your expertise to kind of get in there and take care of?

7:11Right. So, I mean, in terms of like needing my expertise, that's certainly not the thing that I provide for the team most of the time. I'm there to kind of guide, unblock, you know, very much in the style of letting the experts that we have do their best work. But the first place when I joined the team that we spent a lot of time was kind of helping shepherd this transition with chatbots, where originally the way that chatbots kind of were born on Discord, because everything was just open, was you would build a bot. You would listen to every message that came through on a WebSocket. If that message summoned your bot, sometimes it was with, you know, like a bang and then the bot name, then you would parse the message and react to it and then respond just like a user would, right?

7:50It was effectively using the same APIs we used in the client to send and receive messages. And this worked kind of initially out of the box. But as we grew, and as more and more users came on board, we realized, one, that was a pretty difficult way to build a bot because you had to handle the scale of listening to every message in every single server and responding to that. And two, from a privacy standpoint, we didn't want to put users in a position where, you know, as these bots proliferate, they could start collecting all these messages and doing whatever with it. And so one of the things that was put into motion before I got here, but I had to help see it through, was this transition to what we call slash commands.

8:26And that's effectively building a model where a user has to summon the bot in a very specific way. You register your commands. It has different sets of data types. We can provide really nice, fancy UX over this to make a great user experience. Whereas before, it was a little bit more hacker-eating kind of terminal feel. Now we have broad, rich UI that makes it easy to use. But kind of helping the team through that and what that breaking change meant, what was a reasonable amount of time to give developers? How do we communicate it? How do we make sure that we have all of the features that we need in place before we kind of make this migration?

8:59I would say that was the first big project that I got to work on when I came in. So ironically, it was thinking through a breaking change and how we rolled that out in a way it's safe for users. Yeah. So what were some of the decisions that had to be made in order to do that gracefully? I think the biggest issue there is always going to be trying to give the same amount of features that users are accustomed to. So we wanted to make this change that we thought was going to be good for developers and was going to be good for users. We want to make sure we did it in a way where they weren't losing anything, right?

9:25So we want the same level of flexibility. But most importantly, we wanted users that are using these bots day in and day out to be able to do most of the same things. So a lot of the decision making was how far do we build, right? How do we take this system that was completely open-ended, put some structure around it, give it some nice primitives, make it feel good, make it feel like it wasn't just we're asking users to move just because we asked them to. We wanted them to want these bots. We want them to want to move to this new system. And so we spent a lot of time thinking through the end user implications of what we were building.

9:57Yeah. How do you sort of manage to strike a balance between making something that's user-friendly to the consumer, but also extensible to developer to a place where you're not able to extend it, where it becomes just difficult to use? If I think about back in the early days of MySpace and some of the things that people could do, you'd hit a MySpace page and your browser would basically crawl to a halt because there's multiple musics playing and there's all these slow loading graphics and stuff like that. Because there was no guardrails around what anybody could do. So you're just having people create these horrific websites.

10:33How do you basically give people the freedom to create while essentially putting some limitations around what it is possible so that they are always creating a decent user experience? a great question. I think I'm kind of of two different minds here, I'll be honest with you. I think, you know, on one hand, if you want to have a truly open platform, you have to be able to accept that people are going to build things that maybe don't look great or don't look the way you would have built it. And if it's not popular, and if it looks bad, and if it isn't a great experience, they're not going to use those apps.

11:04If someone creates an app for your phone that looks terrible and doesn't use the right primitives, then you're probably not going to go download and install that, right? But if it does something great, if it does something novel, if it does it in a way that we never imagined you building it, like that's the goal, right? And you can't get that level of creativity and you can't get that break out of the norm and the expectations unless you get a little bit more freedom on what they can build. So that's kind of like one piece of it where I definitely have, that's my general mindset. That having been said, we also want to make it easy for developers.

11:38And the last thing we want to do is have the out of the box experience be compromised on Discord for something you can do with a developer. And I think that's where with slash commands, it's a great example where we spent just a ton of time stylizing it, having developers provide us with a declarative way to say, these are my commands, these are the inputs, giving them structured ways to provide output, not completely giving up formatting. And one of the advantages of that that we get that's obvious is to the user getting that level of consistency. The other kind of hidden advantage that you get out of it actually is managing a lot of the things that come from having a desktop web and mobile platform.

12:16Developers don't have to think as much about how is this formatted on mobile? How would look with this device? How does it look in this situation? And we can do a lot of that for them. Yeah, I think there's a lot of stuff that has gone into not only making development easier, but also like in particular, like gaming development, where I think like Discord has been really successful. like just so much has gotten easier you know when i think back nearly 20 years ago when i got into building games for a while like it was just a lot of work like it was c plus plus open gl direct x you know there's a lot of math physics but game engines have kind of you know lowered the bar there made things much easier and then with discord you're getting cross-platform compatibility and then as a game designer you have kind of like a fast path to users and distribution and now you throw in things like gen ai and just even using it as a development tool it was probably easier to build a game now than it ever was.

13:07And I'm curious, I know you're more on the sort of, you know, developer ecosystem side, but what are your thoughts on how some of those things, in particular, like Discord and the distribution that's available there, has impacted how we build games and design games and what kind of games are possible? Yeah, I think that's one where I'm all for democratizing developer platforms, right? I think anywhere in the industry where we can make it easier for more people to build, especially folks that are creative and don't have traditional backgrounds, maybe in computer science. And then we're like opening the possibilities of what can get built out there, right?

13:40And I think those are all positive. I think that's been one of the funnest projects I've ever worked on here at Discord has been the release of activities and making it so that developers can build HTML5 JavaScript games, put them right into Discord. And I mean, web games, that's not like entirely new, but I think the twist that we're able to put on it that's a lot of fun is sort of bringing the social structure to that game. So instead of starting a game, you know, maybe on your own and then going off and playing it solo, it's something you can do with friends. You can do it in a video call, have context, have video, voice, chat, all of that just kind of already taken care of in there and then bring your game into that environment.

14:20And it's been just a ton of fun to work on. Yeah, you get a lot of the, like, you're basically providing a lot of the sort of social communication infrastructure that for any kind of modern game, you probably would have to build from scratch if you didn't have it out of the box through a platform like Discord. Yeah. I mean, if you're already here, you're hanging out, you're with your friends and you want to find something to do, it's nice to just have it out of the box, be able to go into our app launcher, pick a game, and you just get all that stuff for free. Talk to me a little bit about activities and how that works from the development standpoint.

14:53Like, how do I get out, you know, building one of these? Yeah, so we have a lot of great guides. We were talking earlier about standing up our first developer relations team here at Discord over the last couple of years has been fun. And so we have great documentation on discord.dev that goes step-by-step. But at the end of the day, the games that we support right now on the platform, they're web games. They're HTML5 and JavaScript. You host them. We have an NPM module that has our SDK that kind of gives you all of the hooks into Discord. So you can get things like session start, knowing what people are playing, invites, sharing interesting things that happened back in the game back out.

15:29But you, for the better part, can build a standalone HTML5 JavaScript game, add the social layer in with Discord, and then go through some lightweight steps to publish it in a way that we can access and launch it through Discord itself. But at the end of the day, if you're comfortable with web development, web game development specifically, it's pretty easy. And then as a developer, I'm using the embedded SDK to build those experiences? And then is that loaded up essentially as like an iframe embedded directly within Discord? Exactly. Well, it's an iframe, but it's locked down in a variety of ways to make sure that it's safe for all of our users that are using it.

16:04But yeah, it effectively loads the whole experience inside of an iframe in the client, and that's both desktop and mobile platforms. Yeah. What are some of the limitations that have to be put on that to make sure that it's secure. I'm sure there's a number of privacy challenges as well that come along with that. One of the nice things about working at a company with a world-class security engineering team is that they really helped us make sure we got that right. And we've had a couple of years to work on it sort of out of the gate. In terms of how it limits what you can build, most of the things that are really limiting there are like, well, A, it is limited to web.

16:38So we're not able to go provide things like native game development just yet. That's not something that we can go out and build. So it's restricted to HTML5, JavaScript. And any feature that has a risk of exposing the user's IP address to other users or to end developers, those are actually things that we try to avoid as well. And I would say that's probably where the majority of the limitations come from, honestly, is that at the end of the day, Discord is, you know, we're a communications platform that is primarily working with the people who game. And one of those big risks in gaming communities is having someone get your IP and then getting DDoSed while you're trying to play a competitive game.

17:15So that's something we're incredibly sensitive to. And when you're dealing with something like an iframe or a web app like this, we have to be really careful to restrict which APIs you can put into place and how you build it to make sure you do it in a way where there's no direct communication from user to user or even user directly to the developer. We actually proxy everything. And then for me, if I build one of these games, these activities. I put it in Discord's app store. People are installing it. It gets really popular. Is it on me to essentially be able to scale the infrastructure to match how much interest there is essentially?

17:48That's exactly right. We definitely discussed the idea of having our own hosting platform. That's something that we went back and forth with a number of times. But at the end of the day, the variety of ways in which people can build these backends, the richness of them, the differences from one game to the next and what its requirements look like, we really wanted to leave that to developers to be able to own the intricacies of that stack and own how they're going to scale it. We have some developers that have their own whole backend ecosystem that's common across all of their games, regardless of where they run.

18:17And so we didn't want to dictate the backend to developers, but yeah, ultimately they're responsible for how they scale and the stone of triumph, how they carry that. And then can I monetize my game through like downloads or installs? Yeah, absolutely. So, I mean, not through downloads or... I just not really in downloads. ...specifically. Yeah. Downloads, not really a thing in this case. Yeah. But that's something that we've been working on for the last year as well is it's called premium apps. And this works across both actually slash commands, traditional apps on Discord, as well as activities.

18:50And we've had a number of features we've rolled out where we'll do all the payment platform stuff for you. And you just have to integrate. You can sell in-app purchases, subscriptions. We have some new things that are about to come out in the next couple of weeks that are going to continue to make that better. But we've been actively working there for a while and all that stuff's out and you can absolutely monetize. Yeah. And then were there particular, I guess, like technical challenges with rolling out the embedded SDK? Like you said, the activities platform was something you were working on for a number of years.

19:19Like what was some of the big challenges there besides some of the security things that we mentioned? Well, I think we talked a little bit about building out a developer platform for a consumer ecosystem and how that can be a little bit different. I think the first thing we really needed to nail down was the user experience. Playing games inside of a chat app comes with a number of interesting UX challenges and figuring out how to do that in a way that's delightful and gets people coming back and doesn't interfere with the main point of the app, which is connecting with people, chatting. And so I think that the first challenge is there.

19:50I mean, yes, there's a bunch of interesting technical challenges, but the first ones were really the UX and making sure we got that right. When we get into the technical side of the house, I would say the number one challenge we faced initially out of the box was that security problem. We wanted to be so careful here because we have what is an iframe running inside of Discord, making sure that nothing can escape that iframe, making sure it doesn't get access to anything on the user system that it shouldn't have access to, pen testing that, trying out all kinds of different ways to make sure that we'd covered all of our bases.

20:21That was one of the key technical challenges that we had going in. When it comes to the titles themselves, because actually many of the initial activities are actually built by Discord. We have an in-house studio that goes and has experts in building web games. Performance was really a bit of a challenge because we have these games we want to build. We want to have great experiences. These are game developers. We have a Discord that have worked on large AAA titles, and they have very specific things they want out of that experience. They want it to be great. Building it in a way that runs on the web, that is also rich with features, gameplay mechanics, performance, and would run not only on a desktop, but on a mobile device in an iframe was actually a pretty big technical challenge.

21:05And it's been inspiring to watch them work through that. Did you have to do some work to like kind of seed the marketplace of the app store essentially with building some in-house apps to launch with something like this, you know, empty marketplace is not very exciting. Yeah, we activities have actually been on Discord for a couple of years, but they've all been those first party ones that we've built. So these have been titles like Chess in the Park, Poker Night, Letter League, kind of some of the classics when we wanted to put out there to feel out, is this something users want? And so I think out of the gate, we had over 40 titles that were available before we went to GDC last year and opened this up for anyone to start building.

21:43And then even during that time, over the last couple of years, we've been working with a bunch of other game studios. So we ourselves tried it out. We built some titles. We had some games we felt great about. We worked with other partners like FRVR, a couple other companies to release their titles that we thought were really exciting and captivating on the platform. And also to make sure we had the API right. If you're the only one that's tested your API, you can't be sure that you have that thing right or that others could use it. We wanted to get that validation as well. In terms of the UX, like, what's it look like as a game embedded in Discord versus, you know, me having essentially a conversation with the other people who are actually also playing the game?

22:21Yeah, so there's kind of two different modes that you can you can play these games. And one is through starts with a voice call. And that's kind of been the original mode. And it's right now our most popular where we get in. Let's say that we're in a server and we get in a voice channel. We're talking and we just decide, hey, I want to play a game or I want to listen to music. That's another thing. We have multiple music activities that are available as well. Someone can click in on the app launcher while you're in that call. You pick the activity and then other people can just jump and join in.

22:47And you're still in the voice channel. You're still in Discord. You have text. You have voice. You can scoot around the rest of the app, but you're just inside of the main screen playing a game. We also have outside of the voice call, if you want to have something that's a little bit more async, you can start these games from inside of a text channel as well. And let's say you want to start a game, have other people see that the session is happening, then join in without having to be in the voice call first. You can do that as well. What about multiplayer? Like if I'm building one of these activities, like what do I essentially see as a developer to know how many people are there?