Let's get real (time): SSE, WebSockets and WebRTC for the soul

A guided tour on modern browser networking.

Transcript

1. Let’s get real (time): Server-Sent Events, WebSockets and WebRTC for the soul A guided tour of modern browser networking Swanand Pagnis swanand@pagnis.in
2. Yours truly • Originally from Krypton, often mistaken as the last survivor • Sent to earth in a spaceship while still a baby • A few useful superpowers • Suspiciously good at hiding in plain sight
3. Yours truly • Originally from Krypton, often mistaken as the last survivor • Sent to earth in a spaceship while still a baby • A few useful superpowers • Suspiciously good at hiding in plain sight
4. Yours truly • Bangalore RUG, Mysore RUG, Garden City RubyConf • Hack code at Simplero for a living • Twitter @_swanand • Github @swanandp
5. What’s in store for us
6. 1. Why bother ? What’s in store for us
7. 1. Why bother ? 2. The Zen of Real Time Communication What’s in store for us
8. 1. Why bother ? 2. The Zen of Real Time Communication 3. Concepts and app Integration with: What’s in store for us
9. 1. Why bother ? 2. The Zen of Real Time Communication 3. Concepts and app Integration with: 1. SSE What’s in store for us
10. 1. Why bother ? 2. The Zen of Real Time Communication 3. Concepts and app Integration with: 1. SSE 2. WebSockets What’s in store for us
11. 1. Why bother ? 2. The Zen of Real Time Communication 3. Concepts and app Integration with: 1. SSE 2. WebSockets 3. WebRTC What’s in store for us
12. 1. Why bother ? 2. The Zen of Real Time Communication 3. Concepts and app Integration with: 1. SSE 2. WebSockets 3. WebRTC 4. Further reading and open source opportunities What’s in store for us
13. Problems with traditional approaches Why Bother ?
14. 1. Poor performance because of high latency 2. Neither truly async nor truly real time, often limited to Text transfer only 3. Either additional complexity and inconvenience or hacky methods
15. Problems with traditional approaches The Zen of Real Time Communication
16. • Escape from Request-Response cycle • Do not be bound to HTTP • It may or may not always REST
18. Also known as the EventSource API Server-Sent Events
19. Server-Sent Events : Introduction
20. Server-Sent Events : Introduction 1. Designed for Server to Client communication
21. Server-Sent Events : Introduction 1. Designed for Server to Client communication 2. Single long lived connection; hence low latency
22. Server-Sent Events : Introduction 1. Designed for Server to Client communication 2. Single long lived connection; hence low latency 3. Simple cross browser API
23. Server-Sent Events : Use cases • Activity feeds like Twitter, Facebook, Stock Tickers • Analytics, Dashboards, Monitoring • Chats, Instant Messaging *, Collaborative editing like Google Docs
25. Server-Sent Events : The Server
26. Server-Sent Events : Summary 1. Simple Protocol that builds on top of HTTP 2. Truly async 3. Perfect for “notifying” the client 4. Great cross browser support, but no binary support
27. 1. Traditional Rack based app are a slight misfit because of response buffering ( Remember our first Zen ? ) 2. Evented architecture works in our favour ( Think of EM::Deferrable or Thin ) 3. Long running connection means long running process on the server Server-Sent Events : App Integration
28. 1. ActionController::Live 2. Sinatra’s Streaming API 3. Faye 4. Cramp 5. Pusher Server-Sent Events : App Integration
29. 1. Streaming and SSE support baked right into Rails ( > 4.0 ) 2. You keep the full context ( current_user etc ) 3. Integration friendly, almost a drop-in feature into existing Rails apps ActionController::Live
30. EDGE ActionController::Live
31. Sinatra’s Streaming API
32. 1. You only need Sinatra, Thin and some Javascript 2. So simple, you will cry with happiness 3. No app context 4. So simple, you will beg for more features Sinatra’s Streaming API
33. 1. You only need Sinatra, Thin and some Javascript 2. So simple, you will cry with happiness 3. No app context 4. So simple, you will beg for more features Sinatra’s Streaming API
34. 1. Running a separate process that acts as a server, and your server and client act as clients to this server 2. Pub / sub model, drop-in integration with your app 3. Graceful degradation 4. No app context Faye + Your App
35. Faye + Your App
36. Apps that have more traditional components than real time 1. Use a separate process / service / app for the real time part ( e.g. Faye or Pusher or BYOT ) 2. Use existing infrastructure for non real time aspects of the app Recommended approach Rant
38. WebSockets When Server-Sent Events are just not enough
39. WebSockets : Introduction
40. WebSockets : Introduction 1. Standalone Bidirectional protocol
41. WebSockets : Introduction 1. Standalone Bidirectional protocol 2. Message oriented, supports events by design
42. WebSockets : Introduction 1. Standalone Bidirectional protocol 2. Message oriented, supports events by design 3. Reliable text and binary transfers
43. WebSockets : Introduction 1. Standalone Bidirectional protocol 2. Message oriented, supports events by design 3. Reliable text and binary transfers 4. HTTP Compatible
44. 1. All the use cases of SSEs, plus: 2. Multiplayer games, Multi-media chat * 3. Remote pair programming, Online contests, Live interviews, Screen sharing, Remote Desktop etc. WebSockets : Use Cases
45. WebSockets : The Browser
46. WebSockets : Upgrade Handshake
47. 1. Faye + Your app 2. Cramp + Your app 3. websocket-rails 4. em-websocket, em-websocket-rails 5. Pusher WebSocket WebSockets : App Integration
48. Cramp + Your App
49. Cramp + Your App
50. Recommended approach
52. http://www.personal.psu.edu/afr3/blogs/siowfa13/yawning.jpg
54. Modern Day Kazaa, in an Iron Man Suit WebRTC
55. WebRTC : Introduction
56. WebRTC : Introduction
57. WebRTC : Introduction
58. WebRTC : Introduction
59. WebRTC : Typical Workflow - Phase 1
60. WebRTC : Typical Workflow - Phase 1
61. WebRTC : Typical Workflow - Phase 1 Incomplete Code
62. WebRTC : Typical Workflow - Phase II
63. WebRTC : Typical Workflow - Phase II
64. WebRTC : Typical Workflow - Phase II
65. – Oscar Wilde “Consistency is the last refuge of the unimaginative”
66. WebRTC : Use Cases
67. WebRTC : Dive in
68. Further Reading
69. • HTML5Rocks ( it’s a website, not a collection of rocks ) • http://studio.html5rocks.com/ • WebRTC official website • Mozilla Developer Network • http://simpl.info/ Websites
70. • Ilya Grigorik • Sam Dutton • Paul Irish • Eric Bidelman • Your own blog, one year from now Blogs
71. • High Performance Browser Networking • Getting Started with WebRTC • HTML5: Up and Running Books
72. Open Source Opportunities
73. • Help out Faye, Cramp and other libraries mentioned so far • Open source all your throw-away code written during learning ( Mine is on Github ) • Async-proof versions of commonly needed ruby gems ( e.g. github.com/rkh/async-rack )
74. • Helper Libraries for Cramp, e.g. • To easily build simple board games • To write calendar based real time apps • Augment the testing libraries to test real time stuff • Write and make your benchmarks available
75. Thank You !
76. Questions ?