Select Page

NETWAYS Blog

Asynchrone Kommunikation im Web: Eine kleine Übersicht

Während das Web in den meisten Fällen mit dem klassischen Request-Response Modell funktioniert, benötigen heutzutage immer mehr Applikationen (spätestens wenn es um Kollaboration geht) die Möglichkeit, vom Server unaufgefordert Informationen zu bekommen. Mittlerweile gibt es dafür einen Wulst voller Bibliotheken und Schnittstellen.
Mein heutiger Blogpost soll gar nicht genau auf eine (oder alle) der Technologien vorstellen, sondern nur eine kurze Übersicht und Anregung geben, wenn man mal auf der Suche ist:

  • HTTP Polling oder lange blockierende HTTP Requests (Comet): Diese gehen immer und brauchen auch keine spezielle Bibliothek. Man stellt entweder sehr oft Anfragen und der Server sagt dann schon wenn etwas passiert, ansonsten nichts (Polling eben) oder der Server blockiert bis etwas passiert und sendet in diesem Falle die Antwort für den Request. Blockiert allerdings in älteren Browsern immer eine der häufig benötigten Verbindungen und ist (egal in welcher Variant) nur noch als Fallback für ältere Browser geeignet (Comet). Davon gibt es viele Varianten, im IFrame oder um Streaming zu ermöglichen, letzten Endes ists aber immer eine Krücke. Da das keine ‘offizielle Technik’, sondern eher ein Hack ist gibts als weiterführende Literatur nur die Wikipedia Seite.
  • Websockets: Ein eigenes Protokol das eigens für persistente bidirectionale Kommunikation mit dem Server gedacht ist. Läuft auch auf vielen Mobilgeräten und kann für ältere Browser (wenn man den Technologiebruch verkraften kann) über ein Flash Fallback wie websocket-as nachgerüstet werden. Bei Websockets läuft die Kommunikation über einen anderen Port als 80, daher kann eine restriktive Firewall hier den Spaß verderben. Die exzellente Mozilla Developer Network Seite weist den Weg, ein Blick in den Standard kann aber auch nicht schaden. Größter Nachteil: Der mangelnde Browsersupport und die z.T. auf Drafts aufbauende Implementierung in älteren Browsern.
  • Server-Sent Events: Eine W3C Recommendation, die es einem Server erlaubt, Events über einen offenen Kanal an Clients (!= Internet Explorer) zu senden. Das Protokoll ist extrem einfach und kommt mit HTTP Bordmitteln aus, im Gegensatz zu Websockets kann der Server aber über den gleichen Kanal keine Events empfangen (dafür muss man dann wieder neue Requests senden). Einen Vorteil gegenüber Websockets sehe ich darin, dass die Kommunikation über den HTTP Port geschieht, ich würde im Zweifel jedoch eher auf Websockets setzen. Die sind mittlerweile ein Standard und haben heute schon besseren Browsersupport. Die W3C Recommendation fängt mit guten Beispielen an, und Mozilla hat ein Beispiel in PHP.

Es gibt hiervon noch einige Varianten, bei der Auswahl einer Technologie muss man sich aber für Performance vs. Kompatibilität entscheiden. Meine klare Empfehlung ist daher, eine Bibliothek wie SockJS zu verwenden. Diese wählt für die aktuelle Platform das effizienteste Protokoll heraus und abstrahiert dessen Verwendung für den Nutzer. Durch die große Auswahl an Adaptern für verschiedene serverseitige Technologien ist es damit kinderleicht, asynchrone Nachrichten zwischen Browser und Server auszutauschen.
Ich hoffe zwar in Zukunft direkt mit Websockets arbeiten zu können, allerdings wird es wohl noch eine Weile dauern bis der Internet Explorer 10 in jeder Firma angekommen ist.

Chrome Devtools: CSS Helfer

Wer kennt das nicht: Man baut ein wenig an einer HTML Seite/Webanwendung (wohlmöglich einer, die man nicht selbst entwickelt hat) herum und möchte das Styling eines Elementes anpassen. Doch egal was man macht und wie laut man brüllt: Der Browser übernimmt die Änderungen einfach nicht. Grund sind meist irgendwelche zusätzliche CSS Regeln die die eigenen Überscheiben, oder sonstiger CSS Voodoo der (scheinbar) keinen Sinn ergibt.
Oft rutscht man dabei in ein iteratives Try & Error Prinzip:

  1. CSS Anpassen
  2. Seite neu aufrufen
  3. Fluchen
  4. CSS Anpassen

Spätestens ab Punkt 4. sollte man merken, dass hier etwas Ineffizient ist. Tools wie die eingebaute Entwicklerkonsole im Chrome können hier den totalen Nervenzusammenbruch (ungefähr bei der zehnten Iteration) verhindern. Natürlich gibt es ähnliche Features auch für die anderen Browser. Die Chrome Entwicklertools sind meiner Meinung nach nur am umfangreichsten und effizientesten, darum gehe ich hier nicht auf andere Tools ein.
Ruft man die Tools auf (Ctrl-Shift-i,  Cmd-Shift-I (Mac) oder Tools->Developer tools) und geht in den Elements Dialog, begrüßt einen folgendes Fenster (hier habe ich eine Seite des W3C CSS Tutorials aufgerufen) :

Chrome developer tools

Developer tools


Während die linke Seite den aktuell gerenderten DOM Baum anzeigt (also mit dynamisch hinzugefügten/geänderten Elementen) gibt die rechte Spalte Auskunft über das aktuelle ausgewählte Element (CSS Regeln, Maße, Eventlistener, etc).
Das 'Computed style' Feld zeigt alle Regeln, die angewendet werden

Das ‘Computed style’ Feld zeigt alle Regeln, die angewendet werden


Interessant für die CSS-Fehlersuche sind eigentlich nur die ersten drei Sektionen :

  • Computed Style gibt an, welche Regeln für dieses Element letztenendes wirklich angewendet werden, also in das Rendering einfliessen
  • Style gibt an, welche Regeln im ‘style=’ Attribut des Objektes hinterlegt sind
  • Matched CSS Rules zeigt alle CSS-Regeln und deren Quelldateien an, die für den aktuellen Knoten gelten. Dabei ist die Reihenfolge gleich der CSS Hierarchie, d.h.
    weiter oben liegende Regeln unterschreiben die generischen Regeln aus der Ebene darunter (Ausnahme: Regeln mit !important)

Sollte etwas nicht gehen muss der Blick zuerst auf die Computed Style Sektion gehen: Ist meine Regel hier vorhanden?
Wenn ja sollte die Regel überprüft werden: Passt das CSS auf das angegebene Element? Gibt es spezielle Bedingungen für die Regel? Passt der Kontext (z.B. bei Problemen mit float, hier müssen auch andere Knoten berücksichtigt werden).
Wenn die Regel nicht im Computed Style steht, kann man in dem Matched CSS Rules Feld hoffentlich sehen warum das so ist:

Kein tingting.mp3 für mich - nicht unterstützte Regeln zeigt Chrome netterweise an

Kein tingting.mp3 für mich – nicht unterstützte Regeln zeigt Chrome netterweise an

  • Erscheint die Regel nicht ist das CSS schlicht und ergreifend nicht korrekt (ist das CSS geladen? Passt die CSS Query auf den Knoten?)
  • Erscheint die Regel, jedoch durchgestrichen, lohnt sich ein Blick auf das gelbe Ausrufezeichen: Dann ist die Regel entweder invalide (hat z.b. einen Tippfehler) oder wird nicht unterstützt.
  • Ist die Regel vorhanden, aber der Wert im Computed Style ein anderer, sollte man schauen ob die Regel irgendwo überschrieben wird: Gibt es Regeln die über der eigenen liegen? Ist die Regel mit !important definiert?

Zum Experimentieren ausserdem sehr nett: Click man auf eine Regel kann man neue Attribute hinzufügen oder bestehende Attribute verändern. Chrome greift einem mit den Eigenschaften und Werten ein wenig unter die Arme. Kleinere CSS Experimente oder Wertänderungen kann man so direkt im Browser ausprobieren.
Man darf aber nicht vergessen dass einem die Tools nur helfen können Fehler zu finden – ein Blick in die Doku sollte bei Problemen immer als erstes Erfolgen. Wer nicht weiß, was sein CSS bewirkt wird auch mit den besten Tools nicht weit kommen (spätestens wenn ein anderer Browser das Dokument anders rendert).

Webprogrammierung: Welche Architektur ist die richtige für mich?

Die Messlatte von Webanwendungen und Webseiten hat sich in den letzten 10 Jahren stark erhöht, was nicht zuletzt dem erhöhten Einsatz von clientseitiger Logik geschuldet ist.
Daraus zu interpretieren JavaScript, Dynamik und Eyecandy hat alles besser gemacht ist allerdings ein falscher Schluss: Über die Funktionalität und Qualität will ich hier keine Aussage machen – es gab auch früher und gibt heute noch sehr viele statische Site-per-Site Anwendungen an denen sich neue Tools eine Scheibe abschneiden können.
Was aber auf der Hand liegt: Wer heute eine erfolgreiche Webanwendung entwickeln will muss sich mit dem Desktop messen (z.T. ist das heute auch schon umgekehrt so). Ein ‘das ist halt im Browser, das geht nicht anders’ frisst heute niemand mehr als Ausrede wenn sich eine Anwendung nicht so anfühlt wie erwartet. Und gleichzeitig ist man als Entwickler wie ein Kind im Süßigkeitenladen: Überall gibt es feine Sachen, will man aber alles auf einmal naschen wird man sich früher oder später übergeben.
Und damit wäre dieser epische Prolog auch schon am Knackpunkt: Wie entscheide ich mich für das ‘richtige’ Architekturmodell für meine Webanwendung? read more…

Web Notifications – bald für (fast) alle

Screen Shot 2013-06-13 at 10.18.20 AM
Zugegeben, Web Notifications sind an sich ein etwas alter Hut – Google Chrome kann das schon lange und wer das Webinterface von GMail nutzt, kennt sicher auch die ‘Notify me about incoming mails’ Funktion. Dennoch habe ich mich bisher immer zurückgehalten einen Blogpost darüber zu schreiben, denn lange Zeit war das eine WebKit (und z.T. Chrome) Insellösung mit dem ‘webkit’ Prefix und ohne w3c Standard.
Web Notifications sind an sich nichts besonderes: Man erlaubt einer Webanwendung einfach, eine Notification am Desktop anzuzeigen, auch wenn der Browser gerade nicht aktiv ist. Google Mail ist da wohl auch gleich eines der logischen Beispiele: Wenn eine neue Mail kommt, will man darüber informiert werden, aber nicht andauernd auf das Fenster schauen.
read more…

Release: EDBC 0.1.0beta & EventDB 2.0.5beta

Unsere EventDB gehört ja mittlerweile bei vielen Monitoringsystemen zur Grundausstattung sobald Syslog oder SNMP Traps ins Spiel kommen. Oft kam hier die Frage: “Kann ich damit auch gleiche Events zusammenfassen und automatisch Acknowledgen sobald ein passendes Clear Event kommt?”. Bisher musste ich immer beschämt sagen, dass wir so etwas geplant, aber noch nicht umgesetzt haben.
Ab heute ändert sich das – der EDBC ist in der ersten Beta da. Und mit ihm wird nicht ‘nur’ oben genanntes Szenario abgedeckt, sondern ein sehr mächtiges Werkzeug bereitgestellt um Nachrichten und Traps in ein Monitoringsystem einzubinden.
Die Hauptfeatures, die der EDBC derzeit bietet:

  • Empfangen von Ereignissen via Pipe, SNMP Handler und/oder Mail
  • Persistieren von Ereignissen in die EventDB, ggf. Vorfiltern der Ereignisse nach beliebigen Merkmalen (u.a. Netzwersegmente, OIDs, Teilstrings)
  • Erkennen logisch gleichartiger Events anhand von Feldwerten, Netzwerksegmenten, Teilstrings (via Regexp Gruppen), etc.
  • Zusammenfassen logisch gleichartiger Events
  • Erkennen von Clear Events und ggf. Acknowledgen aller zugehörigen Problemevents in der EventDB
  • Senden von Icinga/Nagios Kommandos bei bestimmten Events (…auch abhängig davon ob es ein neues Problem, ein bereits bekanntes Problem oder ein Clear event ist)
  • Einfache Erweiterbarkeit mit rudimentären Python Kenntnissen

read more…

Veranstaltungen

Tue 27

GitLab Training | Online

October 27 @ 09:00 - October 28 @ 17:00
Tue 27

Graylog Training | Online

October 27 @ 09:00 - October 28 @ 17:00
NETWAYS Headquarter | Nürnberg
Nov 04

Vorstellung der Monitoring Lösung Icinga 2

November 4 @ 10:30 - 11:30
NETWAYS Headquarter | Nürnberg
Nov 24

Elastic Stack Training | Online

November 24 @ 09:00 - November 26 @ 17:00
Dec 01

Foreman Training | Nürnberg

December 1 @ 09:00 - December 2 @ 17:00
NETWAYS Headquarter | Nürnberg