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 realtime data.

But first, let's play a game. I'm super excited to see how this goes. As mentioned, the game is Whack-A-Mole. Who knows the game Whack-A-Mole? Oh, 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 realtime 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. 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. Let's play. So, if you scan this QR code. This is a great photo. Can I get a photo with 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 afterwards 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 5pm today. So, you'll need to be at the booth at 5pm 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 realtime 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. Like, 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, 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. I hope someone's taking a screenshot of this. I think I need to. Hopefully that worked. 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? Okay. Perfect. We're ready to move on. Did anyone manage to get the PayPal logo? A few people. One of them, two or three of them? Two? Anyone get three? A few of you. The game is 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, you know, count as fun. So, I thought I'd do something a bit different. And I saw Nikki from my 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 Whack-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 an MVP, and it came up with results. But it wasn't the result I was expecting. Initially, the mole was, like, 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, like, 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.

It was saying, I'll take a screenshot. And 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.

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 I wanted to proceed with, I did then start to add super base and realtime features.

Let's briefly talk about the history of how we got to realtime. I don't know if anyone remembers, back in the day, we used to press F5 a lot. Local development or on the internet just seeing has a new message come in. So, walking down memory lane, it started off to be a request and a response. It still is. But you had to keep asking, was there any new data or any new message or new information on there? I want to stop that because that's 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 1,000 people or 10,000 people doing that on some 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 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'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, 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.

But then Socket.IO, the open source project, Socket.IO came to the rescue. Who has used this before? Yes, it's a great project, right? Really awesome. It really became the standard. I remember that lots of projects that I had 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.

I think most of us, right? Like, that was hard. So, 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 can 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.

And one last thing, I don't know if anyone is 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. Who has used this before? Yes, it's a great project, right? Really awesome. It really became the standard. I remember that lots of projects that I had 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, Socket 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 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 say the last few words on what is a WebSocket. I've mentioned it quite a few times. HTTP was the request and response. And 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 could have and you can have, sorry, 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 backend 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. So 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 result 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. So 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, 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. Hey, shout out. Sorry, a lot of traffic. Yeah, that's a challenge with the real time 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 a 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.

Let's talk about presence. This is my favorite real-time feature from SuperBase, 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. At the top-right, you see how many people have a view in 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 before, the previous example, I had one part. This 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 ourselves. In the subscribe function, we send the presence tracker when subscribing. This approach is not suitable for handling a high volume of data, particularly for intensive mouse tracking. However, there are alternative solutions for handling high data volumes. On the leaderboard, we connect to the same channel with three parameters focusing on presence and sync events. The sync event tracks connections and disconnections, while the callback counts the total players. Broadcast is the most scalable and flexible option, ideal for notifications and high-frequency data processing like mouse tracking.

For broadcast, we set up the channel and specify the type as broadcast. The event parameter allows customization for specific events. The payload can be tailored to any desired information. Channels can be likened to conferences, while events represent tracks within those channels. Superbase offers the ability to send real-time events via HTTP requests for clients not connected via WebSocket.

And then we have three parameters again. The first parameter is not Postgres changes but presence. Sync events include connections, disconnections, join, and leave events. Customization is highly possible for performance improvements. The callback counts all current players for UI display. Broadcast is the most scalable and flexible option for various purposes like mouse tracking.

Broadcast involves setting up a channel with customized event types and payloads. Superbase allows real-time event transmission via HTTP requests. Channels are like conferences, and events are the tracks within them. Broadcasting via HTTP is possible for clients not using WebSocket.

On the player side, the process is similar: specifying the channel and event. Wildcards can be used for flexibility. Utilize broadcast strategically, not universally, for optimal results. Superbase's broadcasting capabilities extend to HTTP requests for real-time event delivery without WebSocket connections.

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 that 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 a 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 off to 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 that 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 could even send a realtime 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 same 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.

Well, 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, oh, people have already started clicking on the checkout. 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, 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, do you see a PayPal button? Yeah? Everyone sees a 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 checkouts. 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 checkout and use the dummy card that's at the top of the page, please. It is all happening in a sandbox. And then untoggle, don't create a PayPal account. It's all...yeah, sandbox. Like I said, my sandbox.

But I want 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 checkout. 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.

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, just 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-served basis, so I'd head over there straight after this. And definitely come and chat with us about PayPal or about real time or about anything else. Thank you all for your time.

The first one is, how do you debug real-time 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 different 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 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 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'd be really interesting. My question to that person who asked that question is, is it open source though? Because I really like how with Superbase, I can temporarily host it myself for a production app.

I wouldn't, but at least maybe just with a prototype getting started, I could host it myself and then move over to their hosted solution. So yeah, I'd be interested to know if Convex is open source or not. Yeah. All right, next one here. How do you handle real-time in a multi-container setup? Yeah, that is interesting because you have the same issue with session-based. You have a sticky load balance or something like that, and that is very, very true. 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. Can presence throttle or aggregate metrics so that way the data isn't as noisy? You could think of a lot of 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? I 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. 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?

Why don't you add the total of the leaderboard to the payload of the WebSocket? 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. No. Come see me after. I can't remember. I'm not sure about that one. So next one here. Come and see me though. 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.

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 and you can still secure it. I had to keep, because no one was logging in, I had to keep everything open. So I tried 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.

How would you go about monitoring the events handling in such an app? True. So you could then use the wild cards 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 then 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.

It's okay. We're at a tech conference. 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 wild cards 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.

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. It'll be quite interesting to see how that pans out tomorrow. Yeah. Yeah. Real-time, just a lot of fun in general, right?

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. Okay. 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 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 and A speaker spot right now after the talk. So thank you, Eddie. Awesome. Yes. Look forward to it. Thank you all so much.