[? Music ?]

[Code/Racer] [Creating the Socket Connection]

With just a couple of lines of code, we were able to get

Socket.io both installed and listening on our server,

and we were able to see that we’re able to retrieve the client js file,

and we actually connected using the developer’s tools.

The next step is to actually start writing some code.

Now, we don’t want to just do this inside of our console.

We actually want to create a JavaScript file for our application, or at least our testing page.

Later on we’re going to be integrating something called Spine.js,

which will be a client-side application framework that will manage a lot of our JavaScript code.

But for now, we'll just use a normal JavaScript or CoffeeScript file

that we'll just experiment with to see how we can get

connections going back and forth over our sockets.

What I want to do is create an application.js,

but actually I am really comfortable in CoffeeScript right now,

so what I want to do is actually be able to write

a client JavaScript file in CoffeeScript and have it

compile over our application.

Now, Express is really an extension to something called "Connect,"

and Connect is a way of writing servers with middleware,

and we've seen different middleware like our less here,

which manages how we serve our CSS file, which is actually backed

by a less file.

And another middleware is our express.static.

And we can use another one that's included

that's called "express.compilers," and this is actually

part of Connect, but Express serves it out of its own directory as well,

so we could have included Connect and called connect.status,

but Express will provide it through its own middleware.

We're going to use a middleware called the "Compiler,"

and this will allow us to compile a few different things, but most notably,

we can compile CoffeeScripts into JavaScripts.

We'll do "app.use," and we'll do "express.compiler."

And now we need to pass it some options.

Basically what we need to do is we're going to pass it an object

with a source attribute, and this is going to be

where we're going to be serving it out of, and we're going to

store our files out of the public directory, so we'll do "__dirname"

for our current dirname "/public."

And we could also put a destination, but by default,

it's going to rewrite a JavaScript file in the same place that

the CoffeeScript file was found.

And all we need to do now is pass it the enable,

and this is an array of what type of compilers

we want to support, and the name of the compiler we want to add

is "coffeescript," all one word there.

Now what we should be able to do is in a public directory, we have this app.js.

I'm going to remove that one, and let's create a new one,

and we'll call it "application.coffee."

Now, we're going to name it application.coffee,

but since we have the compiler middleware, if we request

application.js, it should compile the coffee

into js and serve that.

Let's test it out, and let's just do a simple alert,

passing hello, and this will very quickly tell us

if we have our application up and running.

The next step is to add that into our layout.eco file.

We'll create another script,

and this should be served out as "/application.js."

And if we close the script tag, save it,

and our server should have restarted, so if we go back here,

if everything is working, we should get an alert.

And we're getting a 404 Not Found, so let's take a look and see

if everything is working right.

I'm going to go ahead and just stop the server really quick.

It doesn't look like it restarted, but maybe I forgot

to actually save our server.coffee, so let's double check and go back.

We have one there,

and it looks like we've got a couple of starts there,

so hopefully everything is up and running.

Again, if we refresh, we just got this message popping up

saying "Hello," so now our CoffeeScript file is being compiled

into a JavaScript file.

Let's go back and make sure it's really working.

If we go back in here, we can see there's now an application.js,

so this is what got compiled.

This is our CoffeeScript compiled into JavaScript.

Let's go back to our Coffee.

We're only ever going to worry about this.

And let's do "Hello World."

If we refresh, we've still got "Hello" showing up,

so let's try that again.

As many times as we save it, we still get "Hello" instead of "Hello World."

Let's double check and make sure everything is working.

But I think we have a little error.

We certainly do.

Now, why is this happening?

Well, let's take a look at our application because it really matters

how we define our middleware.

We're back here in our server.coffee,

and the way middleware works is every time it gets a request,

Express or Connect is going to pass the request

through every piece of middleware we have.

And if that middleware is able to accept it,

it will serve whatever it needs to serve.

Otherwise it will pass it on.

For instance, when we go to /,

instead of just going to this application get handler here,

it checks with express.static.

Can you handle /? No.

And then it goes to this one. Can you handle /?

And it can only handle application.css, so it passes on.

Then it goes to the compiler and says can you handle just this /?

And since there's nothing in the directory that we gave it that would handle it,

it passes it on, so up to the router here,

where the router says hey, I've got something for /.

I'm going to return it.

So every time we go through a request, it goes through all of our middleware

in the order we defined it, so the first thing it goes through is express.static,

and then our less, and then compiler, and there are a few middleware

that we don't see in here, but that's the idea of it.

What's happening is what the compiler does is when it gets a request,

it checks inside this public directory to see if there's an application.coffee

that it could compile to the js, and it did,

and it saved it into our public directory.

But when we do our next request, what happens?

Well, the first thing it hits is express.static,

and it says can you find an application.js?

And it can, so the express.static

returns right away because there's already an application.js stored in it.

What we would need to have happen is have our static be checked

after our compiler because we always want the compiler

to handle it whenever available.

Because it's already stored in there, the express.static is just going to say

I already have a version.

Even though our application.coffee is there and the compiler could create a newer version,

the static just stops the request right there and says I already have a file

on the disk that I can send.

No need to go any further, so one way we can switch this around--

and we'll just pull the express.static line

and put it last, and this has another opportunity too.

If we had an application.css file in our public directory,

if static came first, it would serve that file.

But since now it comes last, application.css

will always be handled by less.

You want your static to come pretty low if you have some things

that are going to be handled by something more dynamic

like our less middleware or our compiler.

If we save it out and we refresh,

we get a Hello World, and everything works out just great.

So now how do we communicate back and forth between our client and server?

Let's take a look right now.

The way we can do this is we'll open up our application.coffee here,

and we're going to store a variable into a variable called "socket."

And this will be done by taking io.connect and calling it with no arguments.

If our server was in a different place, we could pass in

a URL to where we want to connect to, but by default,

it will do our local host on a port that we are currently on, which is what we want,

our local host 3000.

We have our socket here, and now in our socket,

we can listen for events, and events are how we're going to communicate back and forth.

We'll create different event names for different types of things

that are going to happen, and they will go in both directions.

Let's say we have an event that's going to be coming from the server

to the client called "server-update."

We can say our "socket.on," and this first takes the name of an event

we're going to listen for that's going to come from our server,

and we can arbitrarily call it "server-update."

It doesn't matter what we call it, and so that's our event name.

And the next argument is a handler function, and the handler function

is going to pass in some arbitrary data that will come along with that event,

and we'll just say that it's going to pass a message.

Again, this is what we're defining, and what we're going to do

is on the server side create a complementary piece of code

that will actually send a server update with a message.

What do we want to do when we get a server update?

Well, we can do "console.log."

"We have an update."

And then we can do another console.log of "message,"

so we have that saved out.

So now what we want to do is figure out how we're going to

receive that connection from the server.

Remember, we stored an IO connection here from when we listened to our app.

This has a sockets object on it that can also listen

to incoming connections.

Underneath where I defined my routes here,

I'm going to call "io.sockets," and this represents

all of our sockets, because the server is listening for

sockets of any browser to come in,

so the first thing we're going to look for is a connection.

Because the client will initiate a connection by calling .connect,

we need to be listening for new connections, so an event is going to be called,

so we can listen for that event.

And that event is called "connection,"

and this is an actual event, so it does matter what we call it.

This is not something that we define.

This is something that socket.io provides us.

And what this event provides us in the callback function

we're about to define here is it will pass in the actual connection,

or I like to call it the socket.

This is the individual socket that's coming in from a browser.

If 10 browsers connect, this callback function is going to be called

10 different times, each time with a different connection

to a different browser in our socket variable,

and this is where we can set up our actual information

sending stuff back and forth.

So what can we do?

Well, now that we have this socket inside of this callback function,

we could call something like "socket.emit,"

and this is the complement to the on method.

On listens for events, and emit sends them.

We'll remember that in our application.coffee,

we're listening for an event called server-update,

so we can do "socket.emit 'server-update.'"

And these are the only 2 things that have to match up,

and anything after the first argument, which is the name of our event,

we can have as parameters, and remember,

the parameter that server-update has is a message,

so we can say, "Here is a message from the server."

Now, these could be things like objects, numbers,

or any other thing that could be easily turned into

a JavaScript object notation or a basic object.

But we know strings are easy to send,

so what we have here is as soon as a client tries to connect,

io.sockets is going to call its connection and pass us

that reference to that socket representing that 1 client.

And as soon as we get that, we're going to call emit,

sending a server-update message with a string.

And on our client side, here is the connect call that will trigger it,

and we're calling "socket.on," and we'll see "server-update,"

so when we receive that message, we're going to take it in,

do a couple of console.logs, and now we can see the server

being able to send a message to the client.

Let's refresh.

And when we refreshed, we see it immediately says we have an update,

and here is a message from the server.

Now, that's great, but that's pretty much just like in normal requests.

We made a request, and the server immediately sent something back.

But what we could do is we could actually postpone that message whenever we want.

Instead of immediately calling "socket.emit,"

I'm going to call "setTimeout."

And setTimeout takes a function which we'll call later.

And so by indenting this code, we say we're going to call this code,

and the option we're going to pass is how long we want

to wait before we send this code.

Let's say 3 seconds, so 3000 milliseconds.

As soon as we get the connection, we're setting up a time out,

so in 3 seconds we're going to call "socket.emit 'server-update.'"

So now we just see a slight gap from when we connect

to when we actually get the message.

And you'll notice as I was editing,

we now have a few more of these events being called,

and that's because socket.io will try to reconnect

the socket any time we disconnect,

and every time we save that file, our server actually restarts

disconnecting our connection, so our page has been sitting here

listening to the server, but the server has died a couple of times and come back.

Every time it reestablishes that connection,

the logic of our server sends out that information.

Let's just get a fresh session going by refreshing.

So we've connected, and if we wait about 3 seconds,

here is a message from the server.

Now, we'll see a little bit more interesting use of this in a little bit,

but right now we can kind of see that we have our socket open,

and whenever something interesting happens,

we're able to send a message from the server to the client.