Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Let's get real (time): SSE, WebSockets and WebR...

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

A guided tour on modern browser networking.

Swanand Pagnis

March 22, 2014
Tweet

More Decks by Swanand Pagnis

Other Decks in Technology

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 [email protected]
  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. 1. Why bother ? 2. The Zen of Real Time

    Communication What’s in store for us
  6. 1. Why bother ? 2. The Zen of Real Time

    Communication 3. Concepts and app Integration with: What’s in store for us
  7. 1. Why bother ? 2. The Zen of Real Time

    Communication 3. Concepts and app Integration with: 1. SSE What’s in store for us
  8. 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
  9. 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
  10. 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
  11. 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
  12. • Escape from Request-Response cycle • Do not be bound

    to HTTP • It may or may not always REST
  13. Server-Sent Events : Introduction 1. Designed for Server to Client

    communication 2. Single long lived connection; hence low latency
  14. Server-Sent Events : Introduction 1. Designed for Server to Client

    communication 2. Single long lived connection; hence low latency 3. Simple cross browser API
  15. Server-Sent Events : Use cases • Activity feeds like Twitter,

    Facebook, Stock Tickers • Analytics, Dashboards, Monitoring • Chats, Instant Messaging *, Collaborative editing like Google Docs
  16. 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
  17. 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
  18. 1. ActionController::Live 2. Sinatra’s Streaming API 3. Faye 4. Cramp

    5. Pusher Server-Sent Events : App Integration
  19. 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
  20. 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
  21. 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
  22. 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
  23. 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
  24. WebSockets : Introduction 1. Standalone Bidirectional protocol 2. Message oriented,

    supports events by design 3. Reliable text and binary transfers
  25. WebSockets : Introduction 1. Standalone Bidirectional protocol 2. Message oriented,

    supports events by design 3. Reliable text and binary transfers 4. HTTP Compatible
  26. 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
  27. 1. Faye + Your app 2. Cramp + Your app

    3. websocket-rails 4. em-websocket, em-websocket-rails 5. Pusher WebSocket WebSockets : App Integration
  28. • HTML5Rocks ( it’s a website, not a collection of

    rocks ) • http://studio.html5rocks.com/ • WebRTC official website • Mozilla Developer Network • http://simpl.info/ Websites
  29. • Ilya Grigorik • Sam Dutton • Paul Irish •

    Eric Bidelman • Your own blog, one year from now Blogs
  30. • 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 )
  31. • 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