This course has been updated! We now recommend you take the AWS for Front-End Engineers (ft. S3, Cloudfront & Route 53) course.

Check out a free preview of the full Zero to Production Node.js on Amazon Web Services course:
The "Exercise 7: Real Time Features" Lesson is part of the full, Zero to Production Node.js on Amazon Web Services course featured in this preview video. Here's what you'd learn in this lesson:

In this exercise, you will update the TodoMVC++ application so the todo list for new todo items is updated using web sockets. The task for this exercise is located in the Issues area of the Github repository and labeled “exercise7”.

Get Unlimited Access Now

Transcript from the "Exercise 7: Real Time Features" Lesson

>> [MUSIC]

>> Kevin Whinnery: The issue that I have right now with the application, which will be labeled exercise seven, is to update the TODO list when a new TODO is added via web socket. The way that the view application works right now is it appears that TODO items are added to the database in real time.

[00:00:26] But really what happens is we add them to an array. The array gets rendered in our interface and then we make a request of the server which actually persists it onto the database. So the challenge that I would like to pose for all of you is to create a socket connection between the TODO client and the server.

[00:00:46] And whenever a new TODO is added, and right now we just do it for, we can do it for an ADD. If you want to try to implement it for an update too that's totally fine. But we won't immediately add the TODO list item to the array associated with the view component.

[00:01:04] We'll actually make a request to the server, save it in the database like we are right now and then when the TODO list item has been successfully saved, we will omit from the server to the client. Containing the saved to do list item which then will be added to the array and then represented in our user interface.

[00:01:24] So what it'll be only when the TODO list item has actually been persisted that it will be displayed in the user interface, which hopefully should be pretty close to pretty close to real time. So after lunch we're going to take a crack at that. And yeah, that should be a good time and give you a chance to dig into Socket IO a little bit.

[00:01:46] The challenge here is going to be how you structure your Socket IO code. So right here we kind of have everything in the same file and access to the HTP server and all that jazz. But generally speaking that's not the way you're gonna wanna handle it in your application.

[00:02:04] So much as we have this web app.js file which kind of creates a reusable express application, we're probably gonna wanna create another file which manages Socket.IO related data. As a little bit of a spoiler probably what you're gonna wanna do is in a module, create an object which exports one function which is a connection handler which will be used by the socket server.

[00:02:37] So if I bring up this simple connection or the simple example, you probably wanna create a module which has this function which will be called every time a new socket connects to the application. That module, for the sake of argument should probably create like a global registry of sockets, of all the sockets there are currently connected to the system.

[00:03:01] And then that module should probably have another function which will allow the controllers to omit messages to all the currently connected sockets. So you're gonna be creating a common JS module that exports two functions. One is going to handle incoming socket connections and the other is gonna be used by controllers to emit messages to the currently connected sockets.

[00:03:25] And again, because that's a decent amount of code I thought I would at least prime the pump a little bit with what I think would probably be a reasonable implementation. So I will break now for lunch and then we'll take another half hour on top of that to tackle the challenge.

[00:03:42] And then we'll come back and look at the solution at 1:30 along with the UJS solution.
>> Speaker 2: I've got a kinda quick question.
>> Kevin Whinnery: Yeah.
>> Speaker 2: It seems like the whole socket IO kind of a template is much cleaner than messaging then a restful interface. What's the tradeoff between them.

[00:04:04] I know in socket I was a lot faster.
>> Kevin Whinnery: Between a restful interface and a socket connection I mean, it's kind of about the kind of client that you expect to connect. It's possible to do authentication with web socket connections, if that's something you wanna do. But yeah, I mean there's other than exposing an API that can be used by all kinds of clients like not every kind of client can create a socket connection to your server.

[00:04:35] And like do create read update to the operations that way having a restful interface is probably more accessible. But yeah you could certainly architect your system in such a way where most of your average credit operations happen over a Web socket.
>> Speaker 2: If you're controlling both ends of the pipe sockets would be more efficient.

>> Kevin Whinnery: Potentially yeah. It's certainly is faster. But the support for like authentication especially is a little more fit only with web sockets than it is with Rest. With Rest you have cookies where you can store authentication tokens and by default you don't get that with a web socket connection.

[00:05:21] There are other modules you can use to get that type of functionality. There's no reason why you couldn't implement a lot of your services over WebSockets if you wanted to.