SocketStream

A talk about SocketStream, given at Node.js Cambridge November 2013

Transcript

2. A web framework for single page apps
3. Created by Owen Barnes @temporalwave ! ! (my boss at a former company)
4. About me Paul Jensen @paulbjensen ! ! (I’m the new lead developer)
5. Where to begin?
6. Why Single Page Apps?
7. With a traditional web app, the user has to refresh the page to see new information
8. Time Server Client
9. Time Server Client GET/football/live HTTP/1.1
10. Time Server Client HTTP/1.1 200 OK
11. Time Server Client 20 seconds later…
12. Time Server Client I wonder what the latest score is… Let’s reload the page
13. Time Server Client GET/football/live HTTP/1.1
14. Time Server Client HTTP/1.1 304 Not Modified
15. Time Server Client
16. Time Server Client The user had to press F5 to get at any new information
17. Time Server Client Even though there was no new information, the server still had to serve the HTTP request
18. This is not a fun experience
19. How do we make this better?
20. Time Server Client
21. We could use AJAX to update the page
22. We’d save the user having to press the F5 key
23. What else can we do?
24. Time Server Client
25. Optimise the response
26. GZIP the response data, and …
27. Avoid sending data we already have on the client
28. We could also separate the HTML from the data
29. Reuse the HTML on the client
30. …and use the server to provide you with just data
31. And the web site becomes a client Server Web App Native App API User
32. The server is just an API
33. A beautiful separation of concerns
34. Overview • The server becomes a REST API serving JSON • HTML compilation is done on the client • As a result, less processing & bandwidth is consumed by the server
35. Why Realtime?
36. Time Server Client
37. Polling the server every [n] seconds for new data is redundant
38. There has to be a better way
39. What if the server could send its client(s) new data as soon as it came about?
40. We can, thanks to WebSockets
41. WebSockets allows data to be sent both ways
42. Time Server Client
43. Time Server Client Goal
44. Time Server Client Goal The server sends a message to the client that an action has occurred
45. We eliminate the need to poll the server for new data
46. Overview • We can replace AJAX polling with WebSockets, and provide a better user experience as a result • We also remove the need to make redundant polling requests back to the server. • We use WebSockets for sending/receiving JSON
47. Single Page Apps + The Realtime Web
48. There are many ways to build this kind of app
49. You could build it mostly from scratch, and use Express + Socket.io
50. Or alternatively, you could use a web framework like Meteor or Firebase
51. SocketStream is somewhere in-between these 2 approaches
52. It provides tools to help with building realtime single page apps...
53. ... Whilst trying not to restrict what technologies you can use with your app
54. For example, we don't provide an ORM. Instead, you choose the database & the ORM
55. Also, we don't mandate using a specific client-side framework ! You can use BackBone, Angular, Ember, or something else, that is entirely your choice.
56. What we focus on instead are these things:
57. Building RPC APIs Live Reload WebSocket Management Minifying CSS/JS for production use Client-side code organisation Building PubSub APIs HTML / CSS / JS code preprocessing Session Management Building custom APIs on top of WS HTML Templates Web Workers Connect middleware compatibility
58. I'll run through each of these, 1-by-1. But first, let's look at how to use SocketStream
59. Getting started npm install -g socketstream ! socketstream new my_app
60. Getting started Success! Created app 'my_app' with: ! ✓ Basic chat demo (-m for minimal install) ✓ Javascript example code (-c if you prefer CoffeeScript) ✓ Plain HTML for views (-j if you prefer Jade) Next, run the following commands: ! cd my_app [sudo] npm install ! To start your app: ! node app.js

61. Here's what the initial file/ folder structure looks like
62. Building RPC APIs Live Reload WebSocket Management Minifying CSS/JS for production use Client-side code organisation Building PubSub APIs HTML / CSS / JS code preprocessing Session Management Building custom APIs on top of WS HTML Templates Web Workers Connect middleware compatibility
63. Client code is organised into 5 sub-folders
64. Client side code organisation • CODE stores client side JavaScript files and libraries • CSS stores CSS files • STATIC stores public files like images, font files, and other assets • TEMPLATES stores HTML templates for the single page app to render on the client • VIEWS stores HTML files that are rendered from the server for the initial page
65. Those sub-folders have sub- folders, but are optional
66. This is how we load them // My SocketStream 0.3 app ! var http = require('http'), ss = require('socketstream'); ! // Define a single-page client called 'main' ss.client.define('main', { view: 'app.html', css: ['libs/reset.css', 'app.styl'], code: ['libs/jquery.min.js', 'app'], tmpl: '*' }); ! // Serve this client on the root URL ss.http.route('/', function(req, res){ res.serveClient('main'); });
67. // My SocketStream 0.3 app ! var http = require('http'), ss = require('socketstream'); ! // Define a single-page client called 'main' ss.client.define('main', { view: 'app.html', css: ['libs/reset.css', 'app.styl'], code: ['libs/jquery.min.js', 'app'], tmpl: '*' }); ! // Serve this client on the root URL ss.http.route('/', function(req, res){ res.serveClient('main'); });
68. // My SocketStream 0.3 app ! var http = require('http'), ss = require('socketstream'); ! // Define a single-page client called 'main' ss.client.define('main', { view: 'app.html', css: ['libs/reset.css', 'app.styl'], code: ['libs/jquery.min.js', 'app'], tmpl: '*' }); ! // Serve this client on the root URL ss.http.route('/', function(req, res){ res.serveClient('main'); });
69. // My SocketStream 0.3 app ! var http = require('http'), ss = require('socketstream'); ! // Define a single-page client called 'main' ss.client.define('main', { view: 'app.html', css: ['libs/reset.css', 'app.styl'], code: ['libs/jquery.min.js', 'app'], tmpl: '*' }); ! // Serve this client on the root URL ss.http.route('/', function(req, res){ res.serveClient('main'); });
70. // My SocketStream 0.3 app ! var http = require('http'), ss = require('socketstream'); ! // Define a single-page client called 'main' ss.client.define('main', { view: 'app.html', css: ['libs/reset.css', 'app.styl'], code: ['libs/jquery.min.js', 'app'], tmpl: '*' }); ! // Serve this client on the root URL ss.http.route('/', function(req, res){ res.serveClient('main'); });
71. // My SocketStream 0.3 app ! var http = require('http'), ss = require('socketstream'); ! // Define a single-page client called 'main' ss.client.define('main', { view: 'app.html', css: ['libs/reset.css', 'app.styl'], code: ['libs/jquery.min.js', 'app'], tmpl: '*' }); ! // Serve this client on the root URL ss.http.route('/', function(req, res){ res.serveClient('main'); });
72. // My SocketStream 0.3 app ! var http = require('http'), ss = require('socketstream'); ! // Define a single-page client called 'main' ss.client.define('main', { view: 'app.html', css: ['libs/reset.css', 'app.styl'], code: ['libs/jquery.min.js', 'app'], tmpl: '*' }); ! // Serve this client on the root URL ss.http.route('/', function(req, res){ res.serveClient('main'); });
73. SocketStream uses Browserify to handle requiring JS files
74. Browserify allows us to use a Node.js style of requiring JS files
75. // This file automatically gets called first by SocketStream and must always exist ! // Make 'ss' available to all modules and the browser console window.ss = require('socketstream'); ! ss.server.on('disconnect', function(){ console.log('Connection down :-('); }); ! ss.server.on('reconnect', function(){ console.log('Connection back up :-)'); }); ! ss.server.on('ready', function(){ ! // Wait for the DOM to finish loading jQuery(function(){ // Load app require('/app'); ! }); ! });
76. // This file automatically gets called first by SocketStream and must always exist ! // Make 'ss' available to all modules and the browser console window.ss = require('socketstream'); ! ss.server.on('disconnect', function(){ console.log('Connection down :-('); }); ! ss.server.on('reconnect', function(){ console.log('Connection back up :-)'); }); ! ss.server.on('ready', function(){ ! // Wait for the DOM to finish loading jQuery(function(){ // Load app require('/app'); ! }); ! });
77. Building RPC APIs Live Reload WebSocket Management Minifying CSS/JS for production use Client-side code organisation Building PubSub APIs HTML / CSS / JS code preprocessing Session Management Building custom APIs on top of WS HTML Templates Web Workers Connect middleware compatibility
78. Over the years, developers have come up with new languages to generate HTML, CSS, and JavaScript
79. SocketStream allows developers to use these code preprocessors in their apps
80. Adding a preprocessor is simple // Code Formatters ss.client.formatters.add(require('ss-stylus'));
81. For Javascript • SS-COFFEE - supports using CoffeeScript • SS-GORILLA - supports using GorillaScript
82. For CSS • SS-STYLUS - supports using Stylus • SS-LESS - supports using Less
83. For HTML Views • SS-JADE - supports using Jade
84. For HTML Templating • SS-HOGAN - supports using Twitter's Hogan.js • SS-COFFEEKUP - supports using CoffeeKup
85. Setting a Templating engine // Use server-side compiled Hogan (Mustache) templates. Others engines available ss.client.templateEngine.use(require('ss-hogan'));
86. Building RPC APIs Live Reload WebSocket Management Minifying CSS/JS for production use Client-side code organisation Building PubSub APIs HTML / CSS / JS code preprocessing Session Management Building custom APIs on top of WS HTML Templates Web Workers Connect middleware compatibility
87. Having to press F5 to reload the page in order to view changes to HTML/CSS/JS...
88. ... is not a fun experience
89. In development mode, SocketStream will watch the client files for changes, and reload the page when they occur
90. In the case of CSS, SocketStream will apply the changes without reloading the page
91. Building RPC APIs Live Reload WebSocket Management Minifying CSS/JS for production use Client-side code organisation Building PubSub APIs HTML / CSS / JS code preprocessing Session Management Building custom APIs on top of WS HTML Templates Web Workers Connect middleware compatibility
92. Client-side HTML templates are made available to the browser via the ss.tmpl object
94. Building RPC APIs Live Reload WebSocket Management Minifying CSS/JS for production use Client-side code organisation Building PubSub APIs HTML / CSS / JS code preprocessing Session Management Building custom APIs on top of WS HTML Templates Web Workers Connect middleware compatibility
95. When you're building a single page app, you'll have a lot of JS files, and maybe a few CSS files
96. But serving a HTML page with lots of these files can take time, and is inefficient
97. SocketStream provides a way to concatenate, minify, and GZip these files into 1 JS and 1 CSS file
98. This saves bytes being transferred, as well as reducing the number of HTTP requests you make
99. Also, you can tell SocketStream to load these files from a CDN
100. Setting a Templating engine // Minimize and pack assets if you type: SS_ENV=production node app.js if (ss.env === 'production') ss.client.packAssets();
101. Building RPC APIs Live Reload WebSocket Management Minifying CSS/JS for production use Client-side code organisation Building PubSub APIs HTML / CSS / JS code preprocessing Session Management Building custom APIs on top of WS HTML Templates Web Workers Connect middleware compatibility
102. Web Workers are handy for intensive client-side JS operations
103. SocketStream provides support for using Web Workers in your app
104. First, create a folder
105. Next, put your web worker files in that folder
106. Then, load the worker in a client code file, and enjoy
107. Building RPC APIs Live Reload WebSocket Management Minifying CSS/JS for production use Client-side code organisation Building PubSub APIs HTML / CSS / JS code preprocessing Session Management Building custom APIs on top of WS HTML Templates Web Workers Connect middleware compatibility
108. SocketStream uses Connect middleware to support HTTP features
109. SocketStream uses the following middleware by default: • compress - for GZipping assets • cookieParser - for handling user tracking • favicon - for serving a favicon.ico file • session - for handling sessions • static - for serving static assets
110. SocketStream uses the following middleware by default: • compress middleware is loaded first, before all other middleware • static middleware is loaded last, after all other middleware
111. SocketStream provides a way to load custom middleware into the connect stack
112. ss.http.middleware.prepend() ss.http.middleware.append()
113. This allows you to use all of the connect middleware out there today, i.e. EveryAuth
114. Building RPC APIs Live Reload WebSocket Management Minifying CSS/JS for production use Client-side code organisation Building PubSub APIs HTML / CSS / JS code preprocessing Session Management Building custom APIs on top of WS HTML Templates Web Workers Connect middleware compatibility
115. We use connect’s session middleware, so authentication can be done with either EveryAuth, PassportJS, or you can roll your own.
116. We also recommend using connect-redis
117. Both HTTP and WebSocket interfaces can get/set the session data
118. Via HTTP // app.js ss.http.router.on('/updateSession', function(req, res) { req.session.myVar = 4321; res.end('req.session.myVar has been updated to', req.session.myVar); });
119. Via WebSockets
120. Building RPC APIs Live Reload WebSocket Management Minifying CSS/JS for production use Client-side code organisation Building PubSub APIs HTML / CSS / JS code preprocessing Session Management Building custom APIs on top of WS HTML Templates Web Workers Connect middleware compatibility
121. RPC is a common pattern for clients requesting data from the server
122. SocketStream provides a way to construct RPC APIs with flexibility
125. Building RPC APIs Live Reload WebSocket Management Minifying CSS/JS for production use Client-side code organisation Building PubSub APIs HTML / CSS / JS code preprocessing Session Management Building custom APIs on top of WS HTML Templates Web Workers Connect middleware compatibility
126. PubSub is a great pattern for Single Page Apps
127. SocketStream handles this in various ways:
128. 1 - Publishing to everyone viewing the app right now ss.publish.all('newMessage', message); // Broadcast the message to everyone Server // Listen out for newMessage events coming from the server ss.event.on('newMessage', function(message) { // do something with the message }); Client
129. 2 - Sending to private channels // in a /server/rpc file after calling req.use('session') middleware ! req.session.channel.subscribe('disney') ! req.session.channel.unsubscribe('kids') ! req.session.channel.reset() // unsubscribes the session from every channel ! req.session.channel.list() // shows what channels are subscribed to Server (subscribe/unsubscribe the session )
130. 2 - Sending to private channels // in a /server/rpc file ss.publish.channel('disney', 'chatMessage', {from: 'jerry', message: 'Has anyone seen Tom?'}); Server (publish to channel) // in a /client/code file ss.event.on('chatMessage', function(msg, channelName){ console.log('The following message was sent to the ' + channelName + ' channel:', msg); }); Client (receive channel message)
131. 3 - Sending to users // in a /server/rpc file ss.publish.user('fred', 'specialOffer', 'Here is a special offer just for you!'); Server
132. 4 - Sending to a browser tab // in a /server/rpc file ss.publish.socketId('254987654324567', 'justForMe', 'Just for one tab'); Server
133. Building RPC APIs Live Reload WebSocket Management Minifying CSS/JS for production use Client-side code organisation Building PubSub APIs HTML / CSS / JS code preprocessing Session Management Building custom APIs on top of WS HTML Templates Web Workers Connect middleware compatibility
134. On top of RPC and PubSub, SocketStream provides you with a way to create custom request responders
135. Request Response is basically a WebSocket message handler
136. It allows you to write message handling for games, where every byte matters
137. Building RPC APIs Live Reload WebSocket Management Minifying CSS/JS for production use Client-side code organisation Building PubSub APIs HTML / CSS / JS code preprocessing Session Management Building custom APIs on top of WS HTML Templates Web Workers Connect middleware compatibility
138. WebSockets are not immortal…
139. They are mangled by mobile networks…
140. Blocked by firewalls…
141. Routed to dead ends by proxy servers
142. And severed by train tunnels
143. Also, browser support for WebSockets isn’t guaranteed
144. You need a transport strategy
145. Originally, SocketStream used Socket.io
146. But Socket.io asserted that if a browser supported WebSockets, then it would work
147. They learned from this, by building Engine.io
148. I created the transport wrapper for Engine.io in SocketStream for Bechtel & Dashku
149. And designed it to reconnect the client when severed
150. Months later, it made it’s way into SocketStream’s core.
151. SocketStream let’s you use this, alongside SockJS
152. …and that is SocketStream in a nutshell. Whew!
153. Let’s look at some SocketStream apps in the wild
154. Hollow hollowdocumentary.com
155. Vmux vmux.co
156. Dashku dashku.com
157. SocketStream plugins
158. SS-BACKBONE
159. SS-ANGULAR
160. SS-CUCUMBER
161. Tips for deploying SocketStream in production
162. 1 - Check your server’s ulimit configuration (This can bite you hard)
163. I learned this when Dashku went #1 on Hacker News in 45min
164. 2 - Use HTTPS, but handle it at the load balancer level rather than at the app level
165. HTTPS helps to improve the stability of WebSocket connections, especially on mobile devices
166. But Node’s HTTPS implementation is noticeably slower than using HAProxy or Nginx
167. Where is SocketStream going next?
168. We’re in the process of getting SocketStream’s test coverage up
169. We’re also trying to close some ancient bugs
170. We also need better documentation
171. We’re giving the web site an overhaul
172. And we want to document how SocketStream’s internals function, to help build 0.4
173. but what about 0.4?
174. …0.4 is starting to look like these:
175. I promise you all, it’s coming in June 2014
176. Thank You