Auto-generated transcript JSON is slow, and yes, I know that the entire internet is running with it. I know every single REST API you've ever written is written with it. I'm not here to tell you that's wrong. On the web, using JSON actually makes a lot of sense. But when it comes to really performance-critical applications, where you really need to squeeze in every last millisecond of performance, where you really need your app to perform as fast as it possibly can, right? That's when you really start to notice the downsides of JSON. In particular, how much more characters and boilerplate it needs to send the same message that some other more efficient protocol could send in a lot less bytes. So the point of this video is to show you an example project that I just wrote to show you how much more bytes JSON takes to send the same message as opposed to a custom binary protocol that I wrote. So here we are in the code base. This is a multiplayer gaming server or an example of a gaming server. Basically, you have your clients that will connect to a central server and the central server will just run and store every single client player state. Right. Their player information and then broadcast that to every single client that's connected to the server. Right. So you can imagine if you have something like 50 players or something playing the same game in the same server together, you you need every single player to know where every single other player is. right you need to know the state of every single other player and so what you need to do is you have a central server like this that broadcasts the entire player base to every single player right the actual code over here is not really important what really matters is that you understand the architecture and the concepts that i'm about to explain so this is what we have right now we have a server and this server is connected to multiple clients right and each of these clients needs to know every single thing about each other. They need to know where each player is standing. They need to know all the other things in your game, right? And so you need some sort of a communication protocol between them, right? Obviously, you're going to use sockets or something to establish a connection, right? But for the actual raw message that you're going to send, you need some sort of a communication protocol. And since most people are web developers, most people are used to using JSON in REST APIs and stuff, they kind of just default to JSON, without ever considering whether there's another more efficient protocol or not, right? Let's say we have a player state object like this JSON that I just pasted over here. You have a player ID, the username, the XYZ location of the player, the health, the mana, the stamina, the level, experience, and a bunch of other stuff, right? Basically, every single thing, all of the information about the player that you need to create the game, right? You know where the player is, you know what equipment he's carrying, you know, the velocity, the speed at which he's moving around and stuff, right? Now, the thing is, you need to have this player state object for every single player, right? This is just the first player, right? Player one. If you have like 50 players, you need this object for every single player, right? And then you need to broadcast all of these objects to every single client That a lot of data right So going back in the code I actually have a little demo to display over here What I going to do is I going to run this multiplayer gaming server. The mode will be server because I'm going to start the server first of all, and then I'm going to use the format of JSON. All right. Okay, so our server is listening on port 8080. Let's open up two new terminals over here. And in both of them, Let's start a client that connects to this server and also uses the format of JSON. Let's do the same thing over here as well. Mode client format JSON. All right. So this is going to start broadcasting the player state every single second, right? So let's just go up here and see what this means. You have two players, right? Because I have two clients connected to the server right now. And it's going to send the player state for both of these. You can see we have the second player over here with this unique ID and we have the first player over here with this unique ID, right? Now, if you go back to the server over here, you can see that the broadcast size is 620 bytes, all right? That's for sending the player state of two players per second. But when it comes to video games, we're not actually transmitting player state per second. We're sending them 60 or 120 times per second, right? If you want to have a game that has 60 frames per second you need to send 50 you need to send 60 updates to the clients per second so if i just pull up uh if i just pull up a little calculator over here you can see that the broadcast size for the player state object is 311 bytes right 311 bytes because that's the size of the player state object when we had only one player connected to the server right so 311 bytes if we have the json payload that has the size of 311 bytes and we have let's say 50 players right and then we want to send 60 frames per second that's a lot of bytes right if i then convert this to megabytes let's say this is going to be if i can do my math right this is going to be 911 111 kb right kilobytes and that's gonna be about 0.8 megabytes per second of network activity that you're sending off right doesn't sound like a lot does it but it actually adds up very very fast especially if you have more details in your game that you want to broadcast to all clients right especially if you're building a much more much more complex kind of game right because this one this is just an example right and this little player state object this is quite basic right If you want to make a real game, you probably have a lot more data to transmit, right? So that's what the JSON format has, right? Let's actually stop the server now. Stop the clients over here as well. Or I guess they already stopped because we shut down the server. And now let's start a new server and this time use the binary format. And then let's start two new clients as well that each use the binary format. I've started one client and there goes the second client. So once again you can see we have two clients two players over here with unique IDs They transmitting the player state and it going to keep happening every single second right If I go back to the server now again we are only using 202 bytes to transmit this data If I go back up to where we had just one client, you can see that the broadcast size of this payload in binary is just 104 bytes. If I do my calculations again, let's say we have 104 bytes per player, right? And we have 50 players. And then we want to have 60 frames per second. So 60 updates to the client per second. That's 312,000 bytes. In kilobytes, that's 304. And if I go over to megabytes, that's literally just 0.29 megabytes. So more like 0.3 megabytes. That's a huge amount of data savings from JSON. So that's the that's the lesson for today That's the lesson for this video is When you want to write a performance-critical application instead of using JSON, which has a ton of boilerplate code Like you can see over here. Let me just let me show you what I exactly mean over here when it comes to JSON you have this Structure in your database where you have to have these curly brackets that takes bytes, right? You need to have the double quotes and the colons and the new lines and the comas over here That's a lot of boilerplate code Also, you need to have the name of the field every single time you want to add something over here, right? So you need to have this username key over here. You need to have this ID key over here You need to have all of these words, right? All these labels instead of just a list of values and all of this stuff takes a lot of storage, right? You can imagine every single time, let's say we're sending the player state for like 20 players, right? We will need to repeat this structure 20 times. We will need to repeat username, ID, rotation, health, mana, all these words, right? We'll need to repeat them 20 times, right? Even though we know exactly what they mean. And that's the problem with JSON. That's why it's so slow because there's so much boilerplate code that goes into it to make sure that it works, right? And that's why when it comes to performance-critical applications where you need every single millisecond, video games are a good example of that. You need to make sure that you're using the right communication protocol for you and your specific use case. And I'm not saying JSON is bad. I'm just saying, hey, maybe it could work for you, right? But in most cases, it's not going to work for you, and you should look into some more efficient protocol. Now, for this project, I've set up a custom binary protocol, and the actual protocol over here is not really important. you can read through the code if you want but it's really not important what really matters is that you use a custom protocol or a predefined protocol but something more efficient than json but just just a high level overview the way this binary protocol that i've written over here works is it literally just writes writes this entire player state in binary right just just has the list of values one after the other. So instead of using instead of using let's say ID 987 whatever right it just has it right And 654 whatever the ID is right And then it has the next value over here, like the username, which is player1 in this case, right? And you can see this is going to be a much more efficient mode of communication, right? Because we don't need these curly brackets. We don't need the colon, the comma, the double quotes. We don't even need the field names, which is one of the biggest cost savings in terms of data transfer when it comes to switching from JSON to binary, right? We don't need any of those things. And so what we get is a much more efficient communication protocol that takes much less bytes and takes much less time to transmit to every single client. And it's things like these that you need to figure out when you're really building large applications or really performance critical applications. If you're building some tutorial project, you probably don't even need to worry about this, right? If you're building a project that only you are going to see or some just hobby toy project, you probably don't even need to worry about these things. But when you're building a real world product, this kind of stuff starts to make a lot of sense. And I can tell you this because I had a similar situation with myself, right? Like I spent a lot of time as a programmer back in the early days when I was learning these things, just building stuff, but not really making it perform well, perform fast, or all those other things that tutorial developers do, right? But long story short, I got an opportunity to work on some really large projects for some pretty big companies. And when I worked for them, that's when I started to really realize the importance of writing good code, of writing fast applications that really perform fast because when you're serving thousands of users or in this case in a in a video game when you're when you have 50 or 100 players in the same server and you need to make sure that they're communicating efficiently with each other so they so the gameplay can be smooth you need to consider things like these so i'm not going to drag the video on for too long guys the main thing is just if you want to write a good high performing application look into a much better communication protocol than json that's it that's the video in my case i used a custom binary protocol you can do the same thing or you can do something else it's it's really up to you that's it that's the video thank you so much for watching i know i haven't uploaded in quite a while now but i'm gonna go back to being consistent on video uploads so if you're enjoying these kinds of videos make sure you subscribe because i am back i am going going to be uploading every single day from here on. Not really, but you get the idea. Lastly, quick little self-promotion plug. I work as a freelance web and mobile developer building websites and mobile apps for people and businesses. And if that's something you're interested in, or if you know someone who's interested in something like that, then check out my website or check out the top link in the description of this video to book a call with me. And then we He just will talk about your project and discuss everything over there on the call and we'll get started building it. This is literally how I make money and, you know, provide for myself and my family. So if this is something you're interested in, let's talk.