Extreme Frontend Modularisierung

Die Modularisierung wird fast einhellig als gute Strategie zur Realisierung komplexer Systeme anerkannt. Meiner Erfahrung nach bleibt es aber oft ein Lippenbekenntnis. Oder die Modularisierungsbemühungen werden zugunsten anderer kurzfristiger Ziele zurückgestellt.

Hier versuche ich ausgehend von Frontend-Funktionalität das Thema Modularisierung extrem aggressiv anzugehen. Diese kleine Demo-App vereint mehrere Micro-Apps. JEDE dieser Micro-Apps funktioniert alleine ohne die Mitwirkung anderer Apps. Selbst die Existenz anderer Apps ist nicht erforderlich. Auf Grund der Unabhängigkeit dieser Micro-Apps ist es völlig egal in welcher Reihenfolge, auf welchen Geräten, in wie vielen verschiedenen Browser-Instancen und mit welchen IP-Adressen diese Micro-Apps gestartet werden (gerne auch mehrfach oder gar nicht). Die Demo-App funktioniert davon völlig unbeeindruckt.

Jede Micro-App besitzt eine eigene URL.
http://spintag.de:7777/board.html startet ein Canvas mit SVG-Kreisen (eine Metapher um Objekte mit Attributen zu visualisieren). http://spintag.de:7777/bar.html startet eine Button-Leiste zum Triggern umfangreicher Änderungen an den SVG-Kreisen.
http://spintag.de:7777/jobs.html zeigt ein Job-Listing der letzten Jobs an. Zum Ausprobieren am besten diese URLS in verschiedenen Browsern (PC, smartphones, smart-TV, …) starten.

Natürlich sprichts nichts dagegen eine „Echte Applikation“ auf der Basis dieser Micro-Apps zu bauen ohne auch nur einen einzigen Vorteil der völlig losgelösten Micro-Apps zu verlieren. Siehe hier: http://spintag.de:7777/ Bitte Source-Code anschauen!. Tatsächlich werden nur die Micro-Apps in IFRAMEs geladen. Der Sourcecode der „kompletten App“ enthält keine Zeile Javascript, d.h. auch kein Framework, keine Dispatcher, keine globalen Eventhandler, keine Callbacks, einfach keinerlei Interaktionen im Frontend. Natürlich kann bei der Umsetzung der Micro-Apps das volle Arsenal an Frontend-Technologien in jeder denkbaren Ausprägung benutzt werden. Hier kommt bunt gemischt jquery, d3.js, socket.io, can.js zum Einsatz.

Ok, wo ist der Haken?

Ohne serverseitiges Objektmodell läuft nichts. Jede Micro-App kommuniziert unter Nutzung von websockets mit einer Instanz des Objekt-Modells (in dieser Demo gibt es nur eine globale unbenannte Session, ließe sich aber leicht ändern)

 

d3.js scene controlled by remote data using node.js and socket.io

d3.js is cool. So is node.js. Hence, doing something with both technologies is almost a logical consequence.

Start the Demo at least in two browser instances/devices (tested with Firefox, Chrome, IE9+, iPad, iPhone). Then click to create and to burst bubbles. Drag the bubbles around and try the action buttons to force larger changes to the d3.js scene.

This demo maintains a pool of “circles” on the server and implements the distributed MVC pattern. The Model is kept on the server. Each instance of the browser keeps a copy of the View and the Controller. Furthermore, a lightweight version of the model is used for data presentation and is processed by the d3 engine. The node.js based server is responsible for synchronization of all models via push messages. All user interaction triggers a change on the server model first. This holds true even for the initiating client. An example scenario follows:

  1. user clicks on a bubble
  2. the event handler reads the „id“ of the SVG-circle element and calls the server side function remove(id)
  3. the server updates the model
  4. the server calls the removeData(id) function for each connected client (including the initiating one)
  5. the data structure in the client is updated (in this example the object with the specified id is removed)
  6. d3.js scene is updated

The static files (index.html, CSS, templates and Javascript files) are served using express.js. The socket.io library is used as a convenience layer on top of websockets and provides a reliable permanent server/client connection.

Remarks regarding performance issues:

  • the good news: node.js and websockets are blazingly fast, playing with the demo for some minutes in three browser instances generates a CPU usage time for the node.js process of about 5 seconds, i.e. there is plenty of room for more serious stuff
  • advice: use SVG opacity styles instead of HTML opacity styles whenever possible, this reduces the SVG render time and enables larger SVG scenes (10 fold improvement in Firefox)

The source code for the server application is as follows:

The server model:

The client code:

complete source code as tar file

Lupe mit Kamerafunktion

Ein jQuery-Beispiel aus der Kategorie Fingerübungen. In dieser Kategorie werde ich in unregelmässigen Abständen Code-Schnippsel oder Mini-Applikationen veröffentlichen die es wahrscheinlich nie zu eigenen Projektstatus schaffen werden, aber trotzdem einige Aspekte enthalten die es Wert sind aufgeschrieben zu werden.

Dieses kleine Demo ist ein gutes Beispiel für die Ausdruckskraft von Javascript in Kombination mit jQuery.

Interessant an der Umsetzung ist der Fakt das keinerlei Pixel berechnet werden, es wird nicht mit Canvas oder Image-Transformationen gearbeitet, sondern einfach ein DIV-Tag clever mit CSS kombiniert. Die Basisideee (die nicht von mir ist) besteht darin die CSS-Property background-position dieses DIV-Tags zu manipulieren. Außerdem wird das quadratische DIV-Tag mittels der CSS-Property border-radius „Rund“ gemacht.

Alles was Sie in diesem Demo sehen ist mit 77 Zeilen Javascript erledigt. Dazu kommen noch 20 Zeilen HTML und 60 Zeilen CSS.