Real-Time with Flowdock
-
Upload
flowdock -
Category
Technology
-
view
1.451 -
download
3
description
Transcript of Real-Time with Flowdock
Real-Time with
I’m going to talk about the most prominent aspect in our single page app.
@lautisWear funny hats and have a messy desk at Flowdock. Occasionally write code. Spend much time in backend these days.
“There’s no time like real-time”
Real-time is necessary for a chat app. Interval polling wouldn’t work.Big part of our app, no Backbone etc.
Demo
Stream changes from backend
And send messages
* stream and apply changes* send some messages to server=> To achieve this, some kind of transport channel between server and client is necessary.
Long-pollingXHR-streamingHTMLFile
WebSocketServer-Sent Events
JSONP streamingXHR multipart
Each have their shortcomings, work on different browsers, and some work cross-domain, others not.
3 implementations with 7 transports
We couldn’t really decide what to use. There isn’t really a one-size fits all option, but you definitely could do with less.
Long-polling
HTTP/1.1 200 OKContent-Type: application/json;
[{'content': 'json'}]
The most obvious choice, works on every browser. Wait until you have something to tell to client. Rinse, repeat.
XHR-streaming
HTTP/1.1 200 OK
{'content': 'json'}{'content': 'json'}{'content': 'json'}
Streaming: multiple chunks in one response. Widely used, not much advertised.XHR-streaming works by parsing the response after each onReadyStateChange.ResponseText will be huge if your HTTP request runs for long time, so periodic reconnection is needed. Flowdock uses 60 seconds, requests have payload about user activity.
Server-Sent EventsHTTP/1.1 200 OK
Content-Type: text/event-stream
data: {'content': 'json'}
id: 2
data: {'content': 'json'}Sent to server on reconnect
SSE aka ES is standardization of XHR streaming pattern. ID attribute allows seamless reconnections from client point-of-view.Hopefully will be in FD mobile soon.
In JavaScript
var es = new EventSource('/events');es.onmessage = function (e) { console.log(JSON.parse(e.data));};
There’s actually something worth showing. Simple, bind message event listener.Other events too
Built-in in modern browsers
Good news: Chrome, Safari 5, FF6, Opera 11
No IE
Even IE10 seems unlikely
No Android
Unlike iOS, Andriod doesn’t have ES. Even Android 4.0 is missing this. Maybe Chrome for Android will fix this.
Use shim insteadhttps://github.com/Yaffle/EventSource
Because SSE are “just” HTTP, you can implement it in JavaScript, today. And many have done it. Use some available shim.
Streams are unidirectional
XHR requests are needed to post data
Sockets are bidirectional
Some kind of socket interface would be nice. Luckily for us, WebSockets are part of HTML5.
WebSocketsvar socket = new WebSocket('/socket');socket.onmessage = function (e) { console.log(JSON.parse(e.data));};
socket.onopen = function() { var m = {'content': 'json'}; socket.send(JSON.stringify(m));}
I’m not going to exaplain the WebSocket protocol here, the standardized version is a bit more complicated than what we saw previously. The JavaScript API is more interesting.Receiving messages with websockets is pretty similar to EventSource. Sending messages is trivial as long as you have received onopen.
Caveats
•Limited browser support
•Proxy problems
•Safari crashes when used with Proxy Auto-Configuration
Safari has different protocol than others, IE 10 will be the first IE to support WS. NO SHIMSWebSockets require full HTTP 1.1.No way to detect if user has PAC. Rare.
Socket.IO“It's care-free realtime
100% in JavaScript.”
Abstraction layer on top of different transports. NO SSE. Server-side and client-side.We’ve been rolling Socket.IO out slowly for last month or so (bugs!).
•Reconnection race-conditions
• Infinite loops with XHR-polling
•DOM Exception 11
Bugs
*Socket.IO didn’t know that there already was a reconnection attempt on going and established multiple connections.* XHR-polling transport client could get in state where it didn’t handshake properly but only hammered the XHR-polling endpoint.* INVALID_STATE_ERR, send data with unopened websocket. Yet another race-condition.
Socket.IO“It's care-free realtime
100% in JavaScript.”care-free
Why bother?
If it’s so horrible, why even bother?
Science!It Works, Bitches.
Let’s look at the numbers.
Latency matters
We knew websockets would be fastest, but by how much?Benchmark by sending a message and test how long it took to receive it
Round-trip latency
0
75
150
225
300
Ping XHR-streaming WebSocket
Baseline: ping to our servers in Germany was 52msXHR: 240ms. TCP and especially SSL handshake is expensive. Streaming part doesn’t add much penalty.WebSockets came pretty close to ping, about 61ms. Node proxy in test setup + our backend server added latency.
Real-world metrics from Flowdock
How many can use websockets? Clients as guinea pigs.
96% use WebSockets
No Flash fallback
Over 80% have up-to-date Webkit based browsers.
3% have obsolete browsers
IE users are minority.
1% have network issues
(or have disabled WebSockets)
We don’t really know.
Network still sucksCan’t just wait for reply even with websockets.Network latencies vary, we have clients all around the world.
Render optimistically
You have two basic choices, either use loading indicator or render users changes optimistically. Needless to say, we try to be on the optimistic end of the road.
1.Post new stuff2.Receive new stuff3.Modify existing stuff
Basic operations in Flowdock
Post new stuff: send messagesReceive: simple, just append to the stream. unless conflictsModify: mostly tag edits, but can also be message deletion. Highlights and unread handling are tags.
•Clients process messages as much as possible
•Server adds unique ID and timestamp to data
•Message echoed to client
Posting messages
Client processes messages. In our case, this basically means that tags are parsed and message rendered to DOM. Later, if necessary, these changes can be reverted.Server adds some information to messages, which is needed to add new tags. Client uses this information to complete the message.Last, message is echoed to all clients, including sender. This causes duplication, but data is needed to “complete” outgoing messages.
SUP
LOL
FOOBAR
FOO
Order sync
"Undo" pending operationsApply operation from networkRe-apply pending opsA bit like git rebase, but cheat a little
Modifying stuff
•Add/remove tag to message
•Mark message as deleted
"Operation, which can be applied multiple times without changing the result beyond the
initial application."
Idempotent changes
Tags are good fit for this. You can add the same tag to a message multiple times. This is used as our event-stream contains messages the client has sent.
Error handling is tricky
Handling errors becomes quickly quite tricky. Good MVC would make it easier, but also it’s not easy to know when some operation has failed because of poor network with WebSockets and Socket.IO.UX implications!
Protips
•Socket.IO will bite you
•SSE is safe choice for streaming
•Design for broken internet
People put laptop to sleep, live with it. Important for single page apps. Avoid reloading.
Thanks!