Meteor – das Fullstack JavaScript Framework

Warum ein Fullstack-Framework?

Client-Server WebApps bestehen üblicherweise aus dem Backend, das auf einem Server läuft, und dem Frontend, das auf dem Client-Browser läuft. Im Backend befindet sich meist die Datenbank zur Speicherung der Daten, im Frontend die Anzeigelogik, aber auch zunehmend die Applikationslogik.

Die heutigen Browser geben mit JavaScript (ECMAScript) die clientseitige Programmiersprache vor. Auf dem Server kommen oft Frameworks für PHP, .NET oder Java zum Einsatz. Entwickler finden sich dann in der Situation wieder, nicht nur zwischen verschiedenen Programmiersprachen, sondern auch zwischen unterschiedlichen Programmierparadigmen wechseln zu müssen, wenn ihr Feature im Frontend und Backend gleichzeitig implementiert werden muss.

Das OpenSource JavaScript Framework Meteor.js geht einen anderen Weg: Als sogenanntes Fullstack JavaScript Framework kommt im Client und im Server JavaScript zum Einsatz. Hierbei kann das Build-Tool Meteor auch moderne ES 2015 Sprachfeatures oder TypeScript für ältere Browser verständlich übersetzen. Client und Server teilen sich durchgängige Programmierparadigmen. Der Entwickler schreibt den Code für sogenannte „Meteor Methods“ nur einmal, er kommt aber auf dem Client und dem Server parallel zur Ausführung. Dies wird oft gemacht, wenn Daten zu speichern sind und Konsistenz- und Rechtsprüfungen am Client ein schnelles Feedback an den Nutzer geben sollen. Die abschließende, verlässliche Prüfung findet zeitversetzt am Server statt. Auf dem Server wird node.js zur Ausführung des Codes verwendet.

Mit 4Minitz haben Method Park-Mitarbeiter eine WebApp (25.000 Lines of Code) entwickelt und damit einige tiefergehende Erfahrungen mit Meteor gesammelt. 4Minitz ist eine OpenSource WebApp zum Vorbereiten und Protokollieren von Meetings. Diese App wird Gegenstand eines späteren Blog-Beitrages sein – hier schauen wir uns jetzt Meteor genauer an!

Meteor – Was ist in der Box?

Meteor sorgt durch den Fullstack-Ansatz für eine sehr flache Lernkurve und bereits nach Durchführung des sehr guten TODO-Tutorials hat man genug Wissen, um mit eigenen Ideen loslegen zu können. Sehr schnell wird man feststellen, dass das Meteor-Team einige sehr mächtige und praktische Features in ihr Framework eingebaut hat. Einige dieser Features wollen wir im Folgenden kurz beleuchten:

• Buildumgebung „Batteries Included“: das Meteor-Tool bringt beim Installieren eine passende Version MongoDB, node.js und npm mit. So kann man sofort mit dem Entwickeln loslegen und muss nicht erst noch eine Reihe abhängiger Werkzeuge bzw. Frameworks installieren.
• Serverseitige Persistenz: Meteor arbeitet mit der NoSQL Datenbank MongoDB zusammen und kümmert sich damit um das dauerhafte Speichern der Daten.
• Data-on-the-Wire: Zwischen Server und Client wird nicht serverseitig berechnetes HTML ausgetauscht, sondern typisierte Daten in Form von JSON (genauer: EJSON). Diese Daten werden auf dem Client mittels eines Template-Frameworks in HTML umgewandelt und dann am Bildschirm angezeigt.
• Flexibles Frontend: Für einfache Projekte kann man als Frontend-Framework das Meteor-eigene Blaze verwenden. Für komplexere Projekte fügt man  mit „einer Kommandozeile“ Unterstützung für Angular.js oder React.js zum eigenen Projekt hinzu.
• Gespiegelte Datenbank im Client: Die Elemente aus der Datenbank, die für den aktuellen View benötigt werden, sind in einer lokalen Datenbank im Client gespiegelt. Die clientseitige Datenbank wird mit derselben API angesprochen, wie die Datenbank auf dem Server. So schreibt man den Code zum Datenbankzugriff nur einmal und Meteor kümmert sich um die Ausführung auf Client UND Server.

Weitere Features

• Realtime Reactivity: Als Entwickler legt man fest, welche Daten am Browser wo angezeigt werden sollen. Meteor kümmert sich ab diesem Zeitpunkt automatisch darum, die Anzeige der Daten im Browser-DOM zu aktualisieren, wenn sie sich in der Datenbank geändert haben – ggfs. auch durch die Bearbeitungen von anderen Benutzern.
• Optimistic Rendering: Bei CRUD-Operationen (Create, Read, Update, Delete) im Client werden die Datenänderungen zuerst in der clientseitigen Schattenkopie der Datenbank aktualisiert, was ein automatisches Updates des Browser-Views bewirkt. Dieser „optimistische“ Ansatz führt zu einer gefühlten sofortigen Änderung am Bildschirm. Parallel dazu werden die Änderungen über den Server veranlasst und nach Roundtrip im Client nachgezogen, falls der Server zu einer anderen Sicht der Dinge kam (z.B. wegen fehlender Rechte).
• Hot Code Push: Eine Meteor App merkt, wenn sich auf dem Server neuerer Applikations-Code befindet als auf dem Client. Dann werden alle Clients benachrichtigt und laden automatisch die neueste Version der App nach. So sind garantiert immer alle verbundenen Clients auf dem neuesten Stand – ohne dass die Benutzer die Seite neu laden müssen.
• TypeScript: Meteor unterstützt (optional) die Entwicklung in TypeScript. Man kann seine WebApp aber auch klassisch mit JavaScript entwickeln.
• Umfangreiches Paketsystem: Auf AtmosphereJs findet man mehr als 12.000 für Meteor entwickelte  oder angepasste Hilfs-Pakete, die einfach zum eigenen Projekt hinzugefügt werden können. Dazu gehört ein produktiv abgehärtetes Paket zur Benutzer-Kontoverwaltung (Passwörter, Rechte, Verifizierungs-EMails, etc.), um nur ein Beispiel zu nennen. Die meisten node.js Pakete können via npm/yarn hinzugefügt werden.

Was ist nicht in der Box?

Neben den oben gelisteten Features auf der „Haben-Seite“, gibt es aber auch ein paar Dinge, die wir vermisst haben. Und nicht alle waren auf den ersten Blick offensichtlich.

Wir waren nicht überrascht, dass keine Frontend Layout-Klassen (CSS, LESS) enthalten sind. Wenn die Entwickler ihre App schön machen wollen, müssen sie Frameworks wie Bootstrap oder Semantic UI einbinden oder selbst Hand an das CSS Styling legen.

Es ist allerdings überraschend, dass essentielle Dinge wie ein client-seitiger Router fehlen und dass die Entwickler hier auf Projekte wie IronRouter oder FlowRouter verwiesen werden, die von der Community entwickelt wurden. Zumal beide Projekte nicht mehr aktiv weiterentwickelt werden.

Nicht alle Anwendungsfälle lassen sich mit einer NoSQL Dokumenten-Datenbank wie MongoDB abdecken. Wenn das Datenmodell tausende kleine, normalisierte Informationseinheiten hat, die man per JOIN zu größeren Objekten zusammenbauen möchte oder wenn auf den Daten komplexe statistische Untersuchungen gemacht werden sollen, dann sind Dokumenten-Datenbanken ggfs. nicht das richtige Werkzeug. Lange gab es keinen offiziellen Support für klassische SQL-Datenbanken innerhalb von Meteor. Mittlerweile existiert mit Appollo aber eine GraphQL-Implementierung, die eine Meteor-App an beliebige Datenquellen anbinden kann.

Aktueller Trend im Webapp-Umfeld

Ein aktueller Trend im WebApp-Umfeld sind sogenannte PWAs (Progressive WebApps), also WebApps, die auch bei schlechter oder nicht vorhandener (mobiler) Datenverbindung die App aus einem intelligenten Client-Cache heraus am Leben erhalten und das „Startverhalten“ auch bei guter Datenverbindung intelligent beschleunigen. Meteor hat bisher noch keinen speziellen Support für PWAs und die Entwickler sind hier auf sich alleine gestellt, eine Meteor-App „offline first“ zu machen.

Für das Produktiv-Hosting einer Meteor-WebApp benötigt man einen Server mit MongoDB und node.js (minimal Version 4.4.x). Weitere Abhängigkeiten hat Meteor nicht. Trotzdem scheiden damit die meisten „Web Hosting Dienste“ schon aus. Es braucht also einen dedizierten Server – gerne auch eine VM. Die Firma Meteor bietet mit Galaxy einen eigenen auf Meteor-Apps zugeschnittenen container-basierten Hosting-Dienst an, der sich vor allem auf Meteor-Apps spezialisiert hat, die mit steigenden Nutzerzahlen skalieren müssen. Anders als das Meteor-Framework ist diese Dienstleistung nicht mehr kostenlos. Die Preise können aber als branchenüblich bezeichnet werden.

Fazit

Meteor eignet sich aufgrund seines Fullstack-Ansatzes sehr gut, um schnell Prototypen für WebApps zu entwickeln. Während andere Teams noch ihren Web-Stack zusammenbauen, kann ein Meteor-Team nach Minuten schon loslegen. Die Tatsache, dass es Codeblöcke gibt, die auf dem Client und auf dem Server identisch zur Ausführung kommen, ist zuerst gewöhnungsbedürftig, aber dann sehr praktisch. Begeisterung erzeugt immer wieder die sogenannte Meteor Magie, wenn sich durch die Reaktivität ein Datensatz in einem Client „in Echtzeit“ ändert, weil ein anderer Client ihn gerade bei sich bearbeitet hat.

Meteor hat (fast) alle wichtigen Komponenten für eine moderne WebApp integriert. Kommt die Anwendung mit dokumenten-basierten Datenbanken klar, kann man die App auch in den Produktiv-Einsatz bringen. In unserem 4Minitz-Projekt waren wir von der Leistungsfähigkeit von Meteor sehr positiv überrascht und einige größere Meteor-Anwendungen (RocketChat, WeKan) zeigen, dass das Framework auch bei gesteigerten Nutzerzahlen gut skaliert.