Check out a free preview of the full Complete Intro to Real-Time course

The "Wrapping Up" Lesson is part of the full, Complete Intro to Real-Time course featured in this preview video. Here's what you'd learn in this lesson:

Brian concludes the course by discussing some related technologies like WebRTC and SignalR. Resources and questions about sending data in a WebSocket versus over HTTP are also included in this segment.


Transcript from the "Wrapping Up" Lesson

>> You did it, congratulations, you now know realtimy things. I obviously didn't show you all of the techniques that could have been done for this. But I showed you, the ones that I would use, these are the primary tools that I would reach for if I had to do some sort of realtime application.

We spoke a bit about WS, we spoke about HTTP2. Two of the more interesting ones that we didn't talk about, one's WebRTC, which is like peer to peer connections. So if you want to have a chat room, but the traffic is actually going from you to another user and it doesn't go through a server, maybe for privacy reasons, maybe for scaling reasons, many reasons like that.

There's a spec built into the browser called WebRTC that allows peer to peer communication. A good example that I was informed of is Twitch uses it quite a bit to get their latencies down for a variety of reasons. And they have a pretty impressive web scaling from peer to peer so that they can have users be able to watch the stream sooner with less bandwidth overhead, both for themselves and for other people.

So WebRTC, web realtime communication, right, that's what it stands for. But we weren't talking about peer to peer today. For the most part, I don't do a lot of things that have peer to peer communication. So, but it's nonetheless a very cool piece of technology, you should definitely check it out.

And then there's a new one from Microsoft called SignalR. It's actually not available for Node yet. There's obviously a JavaScript library so you can use it with ASP.NET and things like that. I will say that again, I used to work at the part of Microsoft that developed SignalR and I'm very impressed by it.

I wish they had a Node library for it. And if there had been a Node library, I would have shown it to you. But it's like Socket.IO taken even further, there's more features built into it. It's even more resilient. It has more transport options, it's a very, very cool piece of technology.

So if you're a C Sharp developer or something like that, definitely something that's worth your time and to check out. If you've ever heard of Blazor, which again, I'm not a C Sharp person, I never written it, but Blazor is the idea that you can write C sharp basically for the frontend.

And then they use web assembly to compile it, so that it can run in the browser. The connection layer between a Blazor backend and a Blazor frontend is done through SignalR frequently. What's really cool about that is they can basically shift where the code is being executed. So if you have a really slow client, you can move all of that code being executed to the server, it does all the processing on the server, and then sends the results down to the client.

And it can kind of move that skill, let's say, one person has a low-end Android phone, one person has a brand new iPhone, the brand new iPhone can do all of the processing so it sends all of the code to the iPhone to do it. On the low-end Android phone, all processing will be done on server and the results are sent down to the client.

And that's how they are communicated over something like SignalR. So it's cool, you should check it, especially if you are a C Sharp developer. In theory, they should someday release a Node client or a Node library for it, but that day is not today. Cool and that's it.

That is the complete intro to realtime. Before we wrap up, does anyone have any questions about any realtime things and/or dating advice that's, it's good form for that too? Yeah.
>> Just a recommendation of a resource, High Performance Browser Networking, this book helped with browser APIs.
>> Yeah, yeah, I think it's an O'Reilly book.

I'm sure they talk about a lot of that kind of even even lower level stuff that I talked about today. So, that is a good recommendation.
>> Let's say we have some data to send from server to browser, let's say an array of 200 objects. What solution is better?

Sending a signal of some kind of event to the browser, and expose this data on standard HTTP endpoint, or just send data in the WebSocket message. I saw different solutions on the Internet and I don't know which one is correct. Sending via WebSockets looks much simpler, is there any reason why not to?

>> Good question. So the question largely revolves around this idea of the hybrid approach, which is basically, and which is a super valid approach by the way of like, you have very large payloads. Or maybe just intensive payloads is probably a better way of putting it. Is it better to immediately push the entire payload onto the client?

Or is it better to just inform the client with a very lightweight event? There are resources available for you to pull. So I had a couple of thoughts on it and there's not a right answer here. There's not just a hard and fast rule, it's gonna depend on your implementation.

The hybrid model is really nice for maybe the client doesn't want it. So let's say it's maybe you have a friend list that's like 1,000 people long. It's really expensive to send you the complete list of all your friends online, offline, not available, be right back, right, all that kind of stuff.

Well, if the user is paying, like friend paying is not open, it's not super useful to send them all their friend information. Then maybe you wanna show them a little tick mark that says like, hey, stuff changed, right? In which case that kind of hybrid model of, hey, let the client know something's different but wait for them to pull the actual information, right?

So I guess kind of the rules that I'm getting out here would be more around really how expensive is it to send that large package of data. If it's not expensive in terms of computation, usually the transport's not the biggest deal there. But in terms of computation, if it's not that expensive, just send it, right?

Simplicity almost always makes things better. So the fact you don't have to do this hybrid push pull model, it's much better if you just make it simple and just push it and let the client do whatever they want with it. If it's not that easy, then it makes sense to do more of the hybrid push pull models of like send the event and wait for the client to try and pull it out.

That can make some sense. So yeah, when you can err on the side of simplicity, always go for simplicity in terms of code, in terms of user experiences, all of that. When that doesn't work, then make it a little bit more complicated to solve your problem, right?

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now