Stress Test Your Reflexes (And My App)

Thank you everyone for the warm welcome. I'm super excited. I'm glad we've got quite a full house here today. So my name is Eddie, and thank you so much for being here. I'm a dev advocate as part of the PayPal team, and today I want to talk about real-time data. But first, let's play a game.

As mentioned, the game is Whack-A-Mole. Who knows the game Whack-A-Mole? 75%? Yeah, that's really good. Okay, great. I promise you, no moles were hurt in the making or playing of this game. But just to clarify, this talk is not about game development. It is about real-time data with the open-source project Superbase.

The aim of the game is to whack the mole, if you haven't played before, but I'm not going to go into that. I'm going to skip that. It seems like you all know how to do it. But the bit that you don't know is, with the moles, there are some PayPal logos where you can get a bonus 10 points. So do try and get those, and they appear in the second half of the game. Okay, let's play. So if you scan this QR code, this is a great photo, just a second. Can I get a photo of you all? Perfect. Scan the QR code. If you don't want to scan the QR code or your phone doesn't have a camera, you can use the link later on, and you can send it to your friends if they're not here as well.

Please use the name on your badge for two reasons. One, it's going to be up on the screen, and I don't want anything rude. And two, there are big prizes to be won. There is extra swag that you get for being here, but it is on a first-come, first-serve basis. So do go to the booth straight afterward, and say you've been here, and show them the game on your app, maybe a photo of me on stage. And also, there is an iPad Air. I think it's an Air to be won at 5 pm today, so you'll need to be at the booth at 5 pm to see who won.

I think it's an Air to be won at 5 pm today, so you'll need to be at the booth at 5 pm to see who won. One last thing, don't close the browser after the game, because we need that for the end of the talk. So while you're playing, let's just talk about real-time data. So why is real-time data important? Nobody wants to keep refreshing the page. When I'm showing the leaderboard, I don't want to keep refreshing it and seeing if new data has come in. And polling is not really a good solution, because I don't think it really solves anything. It might do in the short term, but every request is going to the server, and maybe nothing has changed. So that wastes compute, wastes bandwidth, and really compounds at scale. And for this game, as I'm going to show you in a minute, I specifically need some real-time features. I can see how many people are playing right now. We'll get to how that probably works shortly. I mean, you use real-time data every day, Slack, Discord, WhatsApp, so you see it all the time. So let me bring up the leaderboard and see how the scores are doing. How is everyone doing? Wow. Okay, my computer was asleep and locked. Let me just start everything again. Wow, 160 games in progress. I mean, that's really, really awesome. Hope someone's taking a screenshot of this. I think I need to. Hopefully that works, a little keyboard shortcut. But yeah, people are playing. Thank you so much. This is great. So let me explain to you a bit about the leaderboard and what's real-time. Well, all of it is real-time. But if you look at the games in progress, that's people playing right now, and we're going to talk about how we can achieve that. And then you've got the total games played as well. That will increase as games in progress decrease. So as the results come in when the game finishes, then total games played will increase. And also the leaderboard and other sections will also update in real-time.

Okay. I think someone spelled their name wrong. There might be a typo in the first place. How many games have you played? Just one, two? Two? Okay. Perfect. Ready to move on. Did anyone manage to get the PayPal logo? A few people. One of them, two of them, or three of them? Two? Anyone get three? Oh, there's a three and a three. Oh, there's a few of you. The game's too easy. I need to make it harder next time. Okay. Awesome. I want to give you a very brief back story, not on my 15 years, how I got here, but how I got here today with PayPal. So I recently joined PayPal, and they said, can you do a fun talk at JS Nation? And I thought, well, I do talk on open source, full-stack development, automated testing. I think that's fun, but maybe that doesn't count as fun. So I thought I'd do something a bit different. And I saw Nikki from our team a moment ago, and she gave me the idea of building a game. And I never built a game before, so I thought that'd be fun for me as well.

So I started thinking of what games would work well in the browser and on our phones. And what do we all do in 2026? We ask AI. Interestingly enough, I didn't ask AI for ideas of games. Looking back, that probably would have been a good idea. I did that manually, went old school with that one. But when I found Whac-A-Mole, I thought, right, I'll get AI to MVP a client-side solution that I could play with. So this was me. I was really, really happy. But unfortunately, it didn't go to plan. So I asked AI to build MVP, and it came up with results, but it wasn't the result I was expecting. Initially, the mole was squashed, and the start button didn't have a pointer on it.

So on my computer, I didn't think I could click on it, but I could. And that wasn't the biggest problem I had. The biggest problem I had, the start button did nothing. It didn't work. There was probably a thousand lines of code in this project that AI had generated, but it didn't work. The start button didn't work. So I was going back and forth with AI and trying to get it to fix the problem. But unfortunately, it was just over-engineering this. I mean, has anyone had a similar challenge, a few hands going up? Yeah, it was saying, I'll take a screenshot. I was like, okay, go ahead, approved. I'll take a video.

There's no video. There's a button and nothing happens, and it was changing hundreds of lines of code. But yeah, it wasn't a good start to the MVP. I didn't think that would go so well. So what I did, I thought, I'll start again. This time, I wouldn't leave the model on auto. I would pick a specific model. So I picked a times three model, and it created a game. And it worked. And it needed a few tweaks, a bit rough around the edges, but it worked. And I was quite happy with it as a starting point.

Do you know what I realized that day? That a times three model is better. It burns tokens a lot faster. Funny enough, it burns them three times as fast. When I realized Whack-A-Mole was the game that I wanted to proceed with, I did then start to add super base and real-time features.

Let's briefly talk about the history of how we got to real-time. I don't know if anyone remembers back in the day, we used to press F5 a lot in local development or on the internet, just seeing, has a new message come in. So walking down memory lane, it all started off to be a request and a response. Well, it still is. But you had to keep asking, was there any new data or any new messaging, new information on there?

I want to stop that because that's making a bit, making me a bit dizzy. I'm sure it's making you dizzy as well. It was almost like, is there any new data yet? Is there any new data yet? Are we there yet? No, wait a second. That's when you're in the car with your parents on a long journey. But it kind of felt like that over and over. And it was very manual. And if you had a thousand people or 10,000 people doing that on some, you know, sale that's happening online, it's not very good.

The good thing to look at, it was free load testing, I suppose. Then after that came what I like to call the hack era, where we had AJAX. Who remembers AJAX? Yes. So the web was becoming more of an application platform. And engineers will always find a way. I think that that's true. So there was AJAX. It replaced parts of your page behind the scenes. And it kind of worked okay. It was still definitely a hack.

There was also Comet. Did anyone use Comet? No? A few people. Yes, a Comet would do this hanging connection. It would make a request. And if there was no data, it would just wait. And when it got data, it would close and open a new one. So it was hanging connections. And I didn't like that either. I remember that when that came out. And I was using AJAX. And a friend said, I'm using Comet. You should try it. They both sound not great. But it's what we had at the time. And there were other solutions. And don't get me started on different browsers. Who remembers, like, browser challenges, different versions of browsers. And it worked in this browser, but not that browser. I think most of us, right? Like, that was hard.

Luckily, people way smarter than me realized that we needed a standard for bidirectional data. And this is when the WebSockets became a standard. So we could have open communication between the browser and the server. This is all great, right? This is perfect. We're in a happy place. Unfortunately not. The spec was changing, as we expected. But the browser adoption was quite slow. And some browser adoptions were slower than others. We won't mention any names. So it was definitely challenging.

One last thing. I don't know if anyone's aware. But I remember also different browsers adopting the standard would interpret it very differently as well. So it was very difficult at the time. But then Socket.IO, the open-source project, Socket.IO came to the rescue. So I felt there was light at the end of the tunnel. Who's used this before? Yes, it's a great project, right? Really awesome. It really became the standard. I remember lots of projects I worked on, they used Socket.IO because it gave them that abstraction from all those complexities. It felt really, really nice to use. And it would even fall back to long polling if WebSockets were not supported in that browser. So it really covered all bases. At the time, Sockets as a service became quite popular.

A lot of companies started coming out trying to make the developer experience better again. Then there was native WebSockets in the browsers. We finally realized we needed it natively, and then Socket.IO was no longer needed. Sorry, Socket.IO. It was a great project, but it had a lot of overhead. It became bigger and bigger over time trying to cover all bases. So we moved away from making it work to how can we make it efficient and how can we improve the DX, the developer experience?

So I'm going to play this GIF while I just say a last few words on what is a WebSocket. I've mentioned it quite a few times. So HTTP was the request and response. It ended there and that was it. But with WebSockets it wanted to open a persistent bidirectional data flow that was fully duplex. And you can have secure and unsecure, just like with HTTP and HTTPS. It's still initiated by the client as a HTTP request and it gets upgraded to a WebSocket.

And now on to the project Superbase that I've used for the back end of this game. I really like Superbase. I want to focus on the real-time features. They do have many other features. They have database authentication, storage, lots of great stuff. But what I really like about the real-time features, it made it even easier to use, which I thought was brilliant. You've got database events. You don't have to think about sending the event. It's going to be sent for you already. You're just thinking about receiving the event. And then you've got presence, which we're going to go into more detail as well, and broadcast.

And you've seen these in my game. Actually, tell a lie. You've seen two. You've seen presence, which was how many people are playing right now. And you've seen the database events when how many total games played. Every time an insert was done, it would increment that one. There's one more to show you, the broadcast. And that's why I asked you to keep the browser open afterwards. If your phone's locked, that's fine. It should hopefully still all work.

So from these three real-time features, I actually think the Postgres changes is the easiest one to get into it. I mean, who's done real-time data before regularly? Like about 20%? Yeah, it's not used that much. And I think showing people how it's actually not that hard, we can make the user experience a lot better. So yes, with the Postgres changes, it is the total games played. So 41. And each time a new game was entered, that would increment. So we only have to subscribe to that. We don't need to send the event.

Let's have a look at the code. This is all the code that I need for that, with 5% lie. I'll come to the lie in a minute. So we specify the channel. And we'll do that always. That'll be a common theme. In this case, it can be any string that you want. But please use a constant and put it in a config. Otherwise, you're going to get into a mess. And then we have the on function. It takes three parameters. So the first one is the real-time that we want to listen to. So in this case, Postgres changes. But it could be presence or broadcast, which we'll cover next.

And then the next parameter is what we want our event handler to listen to. So in this situation, we want the public schema. And this is a required field. Most of the time, it will be public, I think, for most people. The event is not optional. But you could have it as a wild card. I'm only interested in inserts. I'm not interested in updates. So I specified inserts. But you could have a wild card. And the table, I'm only interested in game results. But that could be omitted if you wanted everything out of your database. And there are additional filters that you can add as well.

And the third parameter is my callback. I just want to increment each time there's an insert. That's it. And then we subscribe. So it registers our client with the server. Really simple, right? Who thinks that's pretty simple? Few more. Okay. Good. Cool. Does anyone see anything wrong with this, though? And it's not there's a missing semicolon or comma. This does work and run. But there is a scenario when this wouldn't work. Yeah, shut it out. Sorry. A lot of traffic. Yeah, that's a challenge with the realtime with the database. That's correct. Especially with security. Anything else?

So the problem is, if I lose internet, if I'm on a train and I lose a connection, then if I go back one, you will see that I have got 41 games played. So say I'm on the train, I lose internet, and four more games are completed. That won't increment. It's fire and forget. So when I get internet again, and a fifth game comes in, it will go to 42. But that's actually incorrect. It should be 46. So you could refresh the page to fix it. But that's not really a good solution. Because the WebSocket connection stays open indefinitely unless it's closed, or there's an interruption to the internet connection, as I mentioned. And it is, yeah, fire and forget. And I think that that helps with the performance and scalability. But then you do have challenges like this.

And we can solve it quite easily, really. In the subscribe, so when it reconnects, we just go and collect the latest data again. So it only happens when the page loads, or if we reconnect. And the great thing with this is you don't have to write much more code, because that function already existed in my code when the page first loads. So it's really, really straightforward because we don't want to refresh the page. And then it will just continue to get future events.

So let's talk about presence. This is my favorite real-time feature from Super Base because this used to be really, really hard to do. So the games in progress that you saw on the leaderboard, that was done by the presence features, how many people are actually playing the game right now. You've seen this in Google Docs with, at the top right, you see how many people are viewing this document with their profile picture. And you hover it, and you get their name. Here I'm just sending player name, and I'm just counting it. But you can customize it however you want. So presence allows us to track state between users. And it has two parts.

So this is on the player, so the people playing the game. So we have the channel, and this can be anything. We can specify it ourself. And then in subscribe function, we send the presence tracker when we subscribe. And again, this is not great for high volume of data. And by high volume, I mean mouse tracking. I don't mean a lot of people, but I mean the player trying to send lots and lots of data. There's another solution for that. But that's pretty straightforward. And then on my leaderboard, again, it's pretty straightforward as well. So this is part two.

But that's pretty straightforward. And then on my leaderboard, again, it's pretty straightforward as well. So this is part two. We connect to the same channel, so it's the same constant. And then we have three parameters again. So the first parameter is not postgres changes. It's presence. That's what we want to listen to. And then the second one, we want to listen to the sync event. There are three events for presence. Sync is if someone connects and disconnects. There's join and leave. I didn't want to increment and decrement as people joined. I wanted it to just always be all the events, and I would just count it every time because the number is not going to be that big. But you can have some performance improvements if you need to. There are ways to do that, and it is highly customizable. And the third is the callback where I count everyone that's playing at the moment, and I set it for the UI. Broadcast. So broadcast is the one you'll use the most. It's the most scalable. It's the most flexible. To use it for notification, custom events, high-frequency data like mouse tracking, if that's what you wanted to do. And this comes in two parts again, but I'm going to flip it around, and we're going to start on the leaderboard part because that's what's going to be sending the event, and receiving the event is your game page. So we specify the channel. Again, I've picked the channel here, and then I'm going to send you, type is the broadcast, and then there's an event, and this time I'm specifying the event. You can listen to all events or listen just to this one, and I've set obviously your game just to listen to this one. And then I set the payload, and the payload could be anything you want, but I'm just saying make the swag store true. One way to look at the channel and the event is, the channel could be the conferences, like there could be multiple conferences happening around the world. That could be the channel, and the event would be the tracks within the channel. That's how I would try and break it down. And Superbase has some really good features about, you can even send a real-time event via a HTTP request. If you don't want your client to connect via WebSocket, you can just make a HTTP request, and Superbase will do all the broadcasting for you. And on the player side, it's pretty straightforward. The same channel, the same first parameter on the on function, and the same event could put a wild card in there if I wanted to. And then I just check if it's set to true, and then I set it in the UI. I think that's pretty straightforward. I think that's pretty good. We should use it more, right? We should use it for everything. No, I'm joking. Don't use it for everything. Let's use it where it makes sense. I think it's time to show you the broadcast. So if you all look at your phones, and you should see a start button or a play button. Is that correct? Yep. Good. Awesome. So if I go back to this, people have already started clicking on the check out. Okay. Interesting. Right.

Okay. Where's my mouse? I lost it. Here we go. Okay. So your button should now change. If you saw a start button, it should now what does it say now? Start or play again. It should say swag. Yes. So if you click on that, you will go to the swag store. But before you do anything else in the swag store, let me say something. There is a dummy card at the top, and this is all happening within the sandbox. So please don't enter any real information. That's one. Two, if you scroll down on your phones, you see a PayPal button? Yeah. Everyone sees a PayPal button? Well, I can disable the PayPal button, so now you can't order any free swag. That's mean. You've all been good sports, so I will re-enable it. Okay. Perfect. So yes, I see people clicking on the check out. And it's covering my last button, but that's fine. Okay. Let me do a celebrate. Did anyone get confetti on their screen? Yes. Okay. Brilliant. So broadcast is working, and I'm just sending them to you, so that's great. Let me bring up my slides real quick. Go to the guest check out and use the dummy card that's at the top of the page, please. It is all happening in the sandbox. And then untoggle, don't create a PayPal account. It's all a sandbox, like I said, my sandbox. There's lots of users in there. And how I did this was with the React SDK. It's really straightforward, npm install, import the SDK, add the PayPal provider, and then I added a button. And then with create order, you saw at the top right of the leaderboard people clicking the check out. So in the function for create order, I put a toast message, and I also have a toast message when people approve and pay the order. And that's it. Thank you all so much for your time today and for playing my game. I really, really appreciate it. If you want to connect with us, our socials for PayPal developers is up top, and mine as well. Don't forget to come and collect your swag from the swag store at the booth. If you have any trouble, come to the booth, show them a picture of me that you were here, and they'll give you the extra swag that they have in addition to the booth. It is first come, first serve basis, so I'd head over there straight after this. And definitely come and chat with us about PayPal or about realtime or about anything else. Thank you all for your time. I really appreciate it. I look forward to your questions. Thank you. The first one is, how do you debug realtime bugs when they only happen live? Oh, that's an interesting question, actually.

I think that one, come and see me at the stand, because I've been playing with some tools. And that one I'm still trying to figure out, so I'd also love to hear people's thoughts on that. That is a tough one. And that's probably one of the reasons why we use it less, I think, because it is hard to debug those. So I think that's a bigger conversation, and I'm really interested in that. So please come and find me at the PayPal booth.

Have you tried a Convex? How does it compare to Superbase? Convex? Yes, Convex. They do real-time syncing. It's kind of similar. They have their own API, but you should check it out. I've tried quite a few, but I haven't heard of them. I've tried, you know, Firebase is another popular one, Apri, and a few others. I can't think of their names. But I haven't tried those, so I'll have to look it up and see what features they've got. It would be really interesting.

How do you handle real-time in a multi-container setup? Yeah, that is interesting because you have the same issue with like session-based, you know, you have a sticky load balance or something like that. And that is very, very true. Mm-hmm. Again, come see me afterwards or DM me. That is something that should be on my list of things to do. So yeah, these are great questions. I love these. Yeah. I remember when Meteor was really popular. I don't know if you used Meteor at all.

Again, come see me afterwards or DM me. That is something that should be on my list of things to do. So yeah, these are great questions. I love these. Yeah. I remember when Meteor was really popular. I don't know if you used Meteor at all. But Meteor, that was like the big thing people are often talking about, scalability of these real-time by default systems, right?

Can presence, throttle or aggregate metrics so the data is less frequent or noisy? Sorry, say that again. So, can presence throttle or aggregate metrics so that way the data isn't as noisy? You could think of like a lot of like maybe layout thrash from data coming in or things like that. Well, I have to see what the use case would be. I'd like to think of what the use case would be and then try and see what the solution would be. So, again, who asked that?

Love that question. Come and see me after my next Q&A at the booth. Because that is a good scenario. And there will be a way. But it's just do we use presence? Do we use something else? So, that is an interesting one. Yeah, we did a with Durable Objects, we did some live stuff at the Syntax event last night. And people just joining and exiting, joining and exiting. You could see the numbers thrashing in real time. It can be a little hectic, right? Yeah. All right, next one. Why don't you add the total of the leaderboard to the payload of the web socket?

All right, next one. Why don't you add the total of the leaderboard to the payload of the web socket? Why did I add the... The total of the leaderboard in the demo. Total of the leaderboard. Yeah. Why did I add it or why didn't I add it? You did. I need to look at my code. Yeah. I don't know. Come see me after. I can't remember. Yeah, I'm not sure about that one. So, next one here. Come and see me, though. I want to answer that.

Do you need to unsubscribe to avoid memory leaks? Yes. Yes, definitely. I kept the code very, very small. We are going to open source the game afterwards. So, I know there was a question there. So, thank you so much. Do collect your swag because I really appreciate that question. Sorry to spoil it. We will open source the code because people do want to make improvements. Yes, you'll see in the game code there is an unsubscribe. You do need to unsubscribe. Otherwise, it can get a bit memory heavy, let's say, and a bit messy. So, yes.

How do you handle malicious users who send 500 games played after they've gone offline? 500 games played? I'm not quite sure about that part. I guess a better question might just be how do you handle malicious users in real-time scenarios like this? So, you can still lock it down. You can still secure it. I had to keep, because no one was logging in, I had to keep everything open. So, I try to do certain coding, I guess, techniques, hacks, to limit the way people could cheat it. But obviously, there's always a way when it is public-facing. So, in hindsight, get people to log in and then I can lock it down. Superbase you can send it for authenticated users, specific users. You can get quite granular with how much you lock it down security-wise. Again, for today, would you all want to log in and register? Probably not. So, that's why I left it open. So, yeah. You can be sure that if you have a real-time demo of anything, people are going to be doing their very best to spam it or anything. It's part of the fun. It's okay. We're a tech conference. It still makes me laugh. Exactly, right?

It still makes me laugh. Exactly, right? How would you go about monitoring the events handling in such an app? True. So, you could then use the wildcards if you wanted to do something yourself, but Superbase has tools already. So, I was actually looking at the dashboard. You can see from 9 o'clock this morning, the real-time events really started jumping up. So, it has got some tools, but you might want something customizable. And then, instead of being really specific with what you listen to, you could keep it more wild and have, maybe, I don't know, a dashboard that has all the events coming through the system and see them. So, yes, it's definitely possible. That page would be interesting. I think you'd have to have a bit like with Vercel logs, where you can say real-time, but then you can pause it, and then you can play again. I think you have something like that because that would be quick. That might be something I might mock up tonight because it'd be quite interesting to see how that pans out tomorrow. Yeah. Yeah. Real-time, just a lot of fun in general, right?

And, likewise, how does PayPal use real-time in the main PayPal product? That's a mean question. Who asked that question? I'll tell you why that's a mean question because I started off my talk with I've just started at PayPal. So, I can't answer that, but there are people at the booth who can. So, yeah, go and chat to them. But I'll try and find out for next time. Okay. How does Superbase or other alternatives or does Superbase or other alternatives have something like Redis list where the list events persist until explicitly removed after process instead of send and forget? So, yeah. Ah, okay. So, Superbase does have replay. So, there are things you can do. They do affect your storage, affect your performance. I didn't include it in this because it would have been a much longer talk. But, yes, you can have it. So, for example, if you're joining a chat, you don't want to then...you won't have the historic messages, which I was just thinking some tools do have that. I'm trying to think like...I think with WhatsApp when you join, you don't see the historic messages. But with Slack, when you join a group chat or a channel, you do the historic messages. And that's where the replay feature would come in. And you would get those messages that you missed because you weren't there. So, it's possible. Awesome. Well, thank you so much, Eddie. And again, if you have any further questions for Eddie, you can ask them at the Q&A speaker spot right now after the talk. So, thank you, Eddie. Awesome. Yes. Look forward to it. Thank you all so much.