Node.js Now Q & A

SPEAKER 1: All right. So I've got a couple questions over here. If you have a question, just line up over there. I see a couple people already there. So go for it. Take it away. AUDIENCE: Hi. This question's probably for Guellermo, but anybody else maybe if they have some opinions too. So I have a pretty large application which has users and communities and things like that. Once in awhile, a user will go onto the page where it says, like, list all the users in this community which in the novice sense emits a whole lot of get XHR's like one for each user.

I've turned that into a batch request to get all of them at the same time. But it still is going over the regular HTTP connection. But I also have Socket.IO running for real time updates. And I was thinking about it earlier today. I was wondering if it made sense in any way if the socket.IO connection was actually websocket connection to route some of these XHR request that would normally go through the regular HitUp connection. Is that a sort of thing that would be stupid? GUILLERMO RAUCH: Yeah, definitely.

I've seen a lot of people-- I mean, if you're using socket, A, you're doing it right. So definitely. No, I've see a lot of people do this HTTP over websocket. I think when it comes out to specific optimization like the one you're mentioning, there's a lot of things to consider. One of them is, if you're making tons of XHR requests in parallel, SPDY solves this problem really well. Because it allows you to push resources. It allows you to multiplex.

It also does compression. So by turning on SPDY, you might get an immediate win there. The other thing to consider is of course on the other extreme, which is ditching HTTP requests and just requesting them through some sort of event or RPC call sorts. So I think the thing that's most important there kind of goes back to what I was managing earlier is on that page, you sort of know what requests are going to come.

And it's optimizing around that. Maybe not so much optimizing around the client requesting, but the server sending without a client requesting itself. Does that make sense? OK. Anyone want to add something? Maybe say definitely? DAN SHAW: Definitely. Yeah, and I Guillermo touched on the point that I was going to add there that the routing for the returned responses could-- you could find a lot of efficiency by having those be routed back to your app with socket.IO.

So you would have response events and sort of dynamic events all coming through the same channel. AUDIENCE: All right. Probably for Erik and Dan, excluding some of the optimizations that Trevor talked about, I would like to know the ratio of front end programmers who become fully functional full stack programmers versus

the more server side Java C++ .NET whatever sort of experts who then become functional front end people. So it's the ratio of one to the other. DAN SHAW: Very complex question. All right, so there's two questions there. The-- huh? 0%? OK. 0%. Present AUDIENCE: [INAUDIBLE].

DAN SHAW: No one needs to be full stack. I wanted to highlight that on this panel here, there are at least two front end developers who've become back developers. And that would be myself and Trevor. TREVOR NORRIS: 50%. DAN SHAW: 50%, right? And then were you back end first? GUILLERMO RAUCH: I don't remember. DAN SHAW: Full stack. GUILLERMO RAUCH: I was-- I was front end and back end. But Javascript got me interested in, I think,