Fallstudie – Echtzeit-Updates in Stream Congress

Luigi Montanez
Luigi Montanez
X Startseite

Einleitung

Über WebSockets und EventSource ermöglicht HTML5 Entwicklern, Webanwendungen zu erstellen, die in Echtzeit mit einem Server kommunizieren. Stream Congress (verfügbar im Chrome Web Store) bietet Live-Updates zur Arbeit des US-Kongresses. Dort werden Schlagzeilen aus dem Repräsentantenhaus und dem Senat, relevante Nachrichten, Tweets von Kongressmitgliedern und andere Social-Media-Updates gestreamt. Die App soll den ganzen Tag geöffnet bleiben, da sie die Geschäftstätigkeit des Kongresses widerspiegelt.

Mit WebSockets beginnen

Die WebSockets-Spezifikation hat für das, was sie ermöglicht, viel Aufmerksamkeit erhalten: einen stabilen, bidirektionalen TCP-Socket zwischen dem Browser und dem Server. Der TCP-Socket hat kein Datenformat. Der Entwickler kann ein Messaging-Protokoll definieren. In der Praxis ist es am bequemsten, JSON-Objekte als Strings zu übergeben. Der clientseitige JavaScript-Code zum Überwachen von Live-Updates ist übersichtlich und einfach:

var liveSocket = new WebSocket("ws://streamcongress.com:8080/live");

liveSocket.onmessage = function (payload) {
  addToStream(JSON.parse(payload.data).reverse());
};

Während die Browserunterstützung für WebSockets unkompliziert ist, befindet sich die serverseitige Unterstützung noch in der formativen Phase. Socket.IO auf Node.js bietet eine der ausgereiftesten und robustesten serverseitigen Lösungen. Ein ereignisgesteuerter Server wie Node.js eignet sich optimal für WebSockets. Für alternative Implementierungen können Python-Entwickler Twisted und Tornado verwenden, während Ruby-Entwickler EventMachine verwenden.

Jetzt neu: Cramp

Cramp ist ein asynchrones Ruby-Web-Framework, das auf EventMachine ausgeführt wird. Er wurde von Pratik Naik verfasst, einem Mitglied des Ruby on Rails-Kernteams. Mit einer domainspezifischen Sprache (DSL) für Echtzeit-Web-Apps ist Cramp die ideale Wahl für Ruby-Webentwickler. Wer bereits mit dem Schreiben von Controllern in Ruby on Rails vertraut ist, wird auch den Stil von Cramp wiedererkennen:

require "rubygems"
require "bundler"
Bundler.require
require 'cramp'
require 'http_router'
require 'active_support/json'
require 'thin'

Cramp::Websocket.backend = :thin

class LiveSocket < Cramp::Websocket
periodic_timer :check_activities, :every => 15

def check_activities
    @latest_activity ||= nil
    new_activities = find_activities_since(@latest_activity)
    @latest_activity = new_activities.first unless new_activities.empty?
    render new_activities.to_json
end
end

routes = HttpRouter.new do
add('/live').to(LiveSocket)
end
run routes

Da Cramp auf der nicht blockierenden EventMachine verwendet wird, sind einige Aspekte zu berücksichtigen:

  • Nicht blockierende Datenbanktreiber wie MySQLPlus und em-mongo müssen verwendet werden.
  • Es müssen ereignisgesteuerte Webserver verwendet werden. Dünne und Regenbogen werden unterstützt.
  • Die Cramp-App muss getrennt von der Rails-App ausgeführt werden, die Stream Congress nutzt. Sie muss unabhängig neu gestartet und überwacht werden.

Aktuelle Einschränkungen

WebSockets erlitt am 8. Dezember 2010 einen Rückschlag, als eine Sicherheitslücke veröffentlicht wurde. Sowohl Firefox als auch Opera haben die Browserunterstützung für WebSockets eingestellt. Es gibt zwar keinen reinen JavaScript-Polyfill, aber es gibt ein Flash-Fallback, das sich inzwischen weit verbreitet hat. Die Verwendung von Flash ist jedoch alles andere als ideal. Obwohl Chrome und Safari weiterhin WebSockets unterstützen, wurde klar, dass WebSockets ersetzt werden mussten, um alle modernen Browser ohne Flash nutzen zu können.

Rollback auf AJAX-Polling durchführen

Es wurde beschlossen, WebSockets wieder als klassisches AJAX-Polling einzusetzen. AJAX-Polling ist zwar im Hinblick auf Laufwerks- und Netzwerk-E/A wesentlich weniger effizient, doch vereinfachte AJAX-Umfragen die technische Umsetzung von Stream Congress. Besonders bedeutend war, dass auf eine separate Cramp-App verzichtet werden konnte. Der AJAX-Endpunkt wurde stattdessen von der Rails-App bereitgestellt. Der clientseitige Code wurde geändert, um jQuery-AJAX-Abrufe zu unterstützen:

var fillStream = function(mostRecentActivity) {
  $.getJSON(requestURL, function(data) {
    addToStream(data.reverse());

    setTimeout(function() {
      fillStream(recentActivities.last());
    }, 15000);
  });
};

AJAX polling, though, is not without its downsides. Relying on the HTTP request/response cycle means that the server sees constant load even when there aren't any new updates. And of course, AJAX polling doesn't take advantage of what HTML5 has to offer.

## EventSource: The right tool for the job

Up to this point, a key factor was ignored about the nature of Stream Congress: the app only needs to stream updates one way, from server to client - downstream. It didn't need to be real-time, upstream client-to-server communication. 

In this sense, WebSockets is overkill for Stream Congress. Server-to-client communication is so common that it's been given a general term: push. In fact, many existing solutions for WebSockets, from the hosted [PusherApp](http://pusherapp.com) to the Rails library [Socky](https://github.com/socky), optimize for push and don't support client-to-server communication at all.

Enter EventSource, also called Server-Sent Events. The specification compares favorably to WebSockets in the context to server to client push:

- A similar, simple JavaScript API on the browser side.
- The open connection is HTTP-based, not dropping to the low level of TCP.
- Automatic reconnection when the connection is closed.

### Going Back to Cramp

In recent months, Cramp has added support for EventSource. The code is very similar to the WebSockets implementation:

```ruby
class LiveEvents < Cramp::Action
self.transport = :sse

periodic_timer :latest, :every => 15

def latest
@latest_activity ||= nil
new_activities = find_activities_since(@latest_activity)
@latest_activity = new_activities.first unless new_activities.empty?
render new_activities.to_json
end
end

routes = HttpRouter.new do
add('/').to(LiveEvents)
end
run routes

Ein wichtiges Problem bei EventSource ist, dass domainübergreifende Verbindungen nicht zulässig sind. Das bedeutet, dass die Cramp-App über dieselbe streamcongress.com-Domain bereitgestellt werden muss wie die Rails-App. Dies kann über ein Proxy auf dem Webserver erreicht werden. Wenn die Cramp-App von Thin unterstützt und auf Port 8000 ausgeführt wird, sieht die Apache-Konfiguration so aus:

LoadModule  proxy_module             /usr/lib/apache2/modules/mod_proxy.so
LoadModule  proxy_http_module        /usr/lib/apache2/modules/mod_proxy_http.so
LoadModule  proxy_balancer_module    /usr/lib/apache2/modules/mod_proxy_balancer.so

<VirtualHost *:80>
  ServerName streamcongress.com
  DocumentRoot /projects/streamcongress/www/current/public
  RailsEnv production
  RackEnv production

  <Directory /projects/streamcongress/www/current/public>
    Order allow,deny
    Allow from all
    Options -MultiViews
  </Directory>

  <Proxy balancer://thin>
    BalancerMember http://localhost:8000
  </Proxy>

  ProxyPass /live balancer://thin/
  ProxyPassReverse /live balancer://thin/
  ProxyPreserveHost on
</VirtualHost>

Mit dieser Konfiguration wird ein EventSource-Endpunkt auf streamcongress.com/live festgelegt.

Stabiles Polyfill

Einer der bedeutendsten Vorteile von EventSource gegenüber WebSockets besteht darin, dass das Fallback vollständig JavaScript-basiert ist und keine Abhängigkeit von Flash besteht. Mit dem polyfill von Remy Sharp gelingt dies durch die Implementierung von Long Polling in Browsern, die EventSource nativ nicht unterstützen. Daher funktioniert EventSource derzeit in allen modernen Browsern, in denen JavaScript aktiviert ist.

Fazit

HTML5 eröffnet viele neue und interessante Möglichkeiten der Webentwicklung. Mit WebSockets und EventSource verfügen Webentwickler nun über saubere, klar definierte Standards, um Web-Apps in Echtzeit zu ermöglichen. Aber nicht alle Nutzer verwenden moderne Browser. Bei der Entscheidung für die Implementierung dieser Technologien muss Graceful Degradation berücksichtigt werden. Und die serverseitigen Tools für WebSockets und EventSource befinden sich noch in der Anfangsphase. Es ist wichtig, diese Faktoren bei der Entwicklung von Echtzeit-HTML5-Apps zu berücksichtigen.