zurück zum Artikel

Einstieg in die Entwicklung von Web-Apps mit Meteor

Werkzeuge
Einstieg in die Entwicklung von Web-Apps mit Meteor

JavaScript-Webframeworks gibt es wie Staub auf dem Mond. Jedoch ist jedes nur auf dem Gebiet gut, für das es geschaffen wurde. Meteor versteht sich als eine Plattform, die eine Auswahl der besten Frameworks mit MongoDB und Node.js kombiniert und Entwicklern so das Zusammensuchen abnehmen möchte. Ihre Hauptmerkmale sind eine einheitliche Basis in JavaScript-Code für Client und Server, das automatisches Propagieren der Änderungen von Code und Daten, ein vergleichsweise einfaches API-Design und intelligentes Packaging und Deployment von Applikationen.

Meteor [1] ist eine JavaScript-Plattform, die von der Datenbank über den Server bis hin zum Client alles abdecken möchte und dabei den Schwerpunkt auf das Aktualisieren von Daten in Echtzeit über alle Clients hinweg legt. Als Datenbank kommt MongoDB [2] zum Einsatz, während auf dem Server Node.js [3] Verwendung findet – alle Ressourcen lassen sich folglich mit einer einzigen Sprache nutzen.

Weiterhin setzt Meteor auf viele bekannte JavaScript-Bibliotheken, wie Amplify, AppCache, Backbone.js, Handlebars, jQuery und Underscore.js, und kombiniert sie unter einer eigenen API. Auch die Verwendung von CoffeeScript in Meteor-Applikationen ist möglich. Zurzeit liegt das Framework in der Version 0.6.5 vor, ein genauer Termin für eine Version 1.0 ist noch nicht bekannt. Die Entwickler selbst sagen "mehr als einen Monat, weniger als ein Jahr", was ihnen viel Spielraum lässt.

Grundsätzen folgen

Die Meteor-Entwickler beschreiben die Plattform mit folgenden sieben Prinzipien:

  1. Data on the Wire: Es werden nur Daten über das Netzwerk gesendet, kein HTML. Zudem entscheidet der Client, was er mit den Daten macht und wie er sie darstellt.
  2. One Language: JavaScript wird als einzige Sprache verwendet, für den Code sowohl in Client- als auch in Server-Anwendungen.
  3. Database Everywhere: Die Datenbank steht sowohl dem Server als auch dem Client zur Verfügung und beide greifen mit einer einheitlichen API darauf zu.
  4. Latency Compensation: Vorauswahl und Modellsimulationen auf dem Client ermöglichen es, eine latenzfreie Datenbankverbindung zu simulieren.
  5. Full Stack Reactivity: Live-Daten und reaktive Programmierung werden zum Standard. Möglichst alle Schnittstellen, von der Datenbank bis zu den Client-Templates, werden Event-getrieben ausgelegt (passend dazu: das reaktive Manifest [4]).
  6. Embrace the Ecosystem: Meteor selbst ist quelloffen und integriert andere Open-Source-Frameworks, statt sie zu ersetzen oder nachzubilden.
  7. Simplicity equals Productivity: Einfachheit steht an erster Stelle. Der beste Weg, etwas einfach aussehen zu lassen, ist, es einfach zu machen. Erreicht wird dies durch leichtgewichtige und klassische APIs. (Erinnert an einen Werbeslogan eines einfachen Mobilfunk-Providers und ist sicherlich das Marketing-lastigste aller sieben Prinzipien, aber dennoch wahr.)

QuickStart und Scaffolding

Zurzeit unterstützt Meteor die Betriebssysteme Mac OS X und Linux. Für Windows gibt es inoffizielle Binaries, offizielle Unterstützung steht für die Zeit nach dem 1.0-Release auf dem Plan [5]. Der Einsatz der bisherigen Versionen kann noch zu Abstürzen führen. Deshalb wird in den folgenden Beispielen von einer Unix-Shell ausgegangen.

Um Meteor einsetzen zu können, ist es zunächst mit dem Befehl

$ curl https://install.meteor.com | /bin/sh

zu installieren. Alle Meteor-Kommandos beginnen mit dem Schlüsselwort meteor, dem dann der gewünschte Befehl folgt. Einen Überblick aller verfügbaren Anweisungen erhält man mit

$ meteor --help

Hängt man diesem Kommando den Befehlsnamen selbst an, erscheinen detailliertere Informationen und mögliche Optionen.

Das erste Projekt ("myapp") lässt sich mit

$ meteor create myapp

erstellen. Meteor erzeugt als Folge ein Unterverzeichnis namens myapp und darin einen weiteren Ordner .meteor, der Konfigurationsdaten für die Anwendung enthält.

Die erste App

Im myapp-Ordner werden je eine HTML-, CSS- und eine JS-Datei angelegt, die, bis auf die CSS-Datei, bereits erste Code-Fragmente enthalten. Wechselt man in den myapp-Ordner, lässt sich dort die Anwendung mit

$ meteor run

starten (der Befehl run ist der Default-Befehl und kann entfallen). Die eigene erste Meteor-Anwendung lässt sich im Browser nach Eingabe von http://localhost:3000 anschauen.

Die erste eigene Meteor-Anwendung im Terminal...(Abb. 1)
Die erste eigene Meteor-Anwendung im Terminal...(Abb. 1)
...und im Browser. (Abb. 2)
...und im Browser. (Abb. 2)

Ein Blick in die generierte JavaScript-Datei zeigt, dass Funktionen für Client und Server enthalten sind:

if (Meteor.isClient) {
someFunction = function() {
// your code goes here
};
...
}

if (Meteor.isServer) {
Meteor.startup(function() {
// code to run on server at startup
});
...
}

Bei kleinen Anwendungen ist dies noch überschaubar, allerdings schwindet die Übersichtlichkeit mit wachsender Codelänge, weshalb ein derartiger Aufbau nicht von Vorteil ist. Nachteilig ist außerdem, dass serverseitiger Code an den Client ausgeliefert wird, was eigentlich vermieden werden sollte.

Um eine bessere Trennung des Quellcodes zu gewährleisten, lassen sich die Dateien nach folgenden Konventionen aufteilen: Alle Dateien im Ordner client werden an den Client ausgeliefert, alle im Ordner server verbleiben auf dem Server. Dateien in lib-Ordnern werden in ihrer jeweiligen Umgebung immer zuerst geladen (hier lassen sich zum Beispiel andere JavaScript-Bibliotheken ablegen und von dort laden). Dateien, die dem Muster "main*.js" entsprechen, werden zuletzt geladen, alle anderen in alphabetischer Reihenfolge. Für statische Inhalte wie Bilder gibt es den public-Ordner, dessen Inhalt Meteor beim Deployment nicht komprimiert.

Im Folgenden sind einige Funktionen und Eigenschaften von Meteor an einer Demo-Applikation namens "Poker-Quiz [6]" erklärt. Ihr Quellcode ist auf GitHub [7] zu finden. Allein spielen ist nicht besonders spannend, erst zusammen mit mehreren Spielern lassen sich das automatisch ändernde Ranking und das Aktivitäten-Log in Aktion beobachten.

Snapshot der "Poker-Quiz"-Demo
Snapshot der "Poker-Quiz"-Demo

MongoDB und Collections

Meteor nutzt MongoDB für die Persistenz, wobei der Zugriff auf die serverseitigen Daten transparent erfolgen soll. Hierfür bietet die Datenbank-API auf dem Client vergleichbare Befehle wie die auf dem Server. Das Meteor-Team hat die Implementierung "Minimongo" getauft. Der Abgleich der Daten zwischen Client (Minimongo) und Server (MongoDB) ist für den Entwickler versteckt.

Für MongoDB üblich, werden Daten in Kollektionen abgebildet, deren Definition vergleichsweise einfach ist. Im Beispiel sind solche für den Punktestand der Spieler und ihre Statusmeldungen (Logs) in der Datei common/Collections.js definiert. Damit stehen die beiden Kollektionen sowohl auf dem Client als auch auf dem Server zur Verfügung, und Meteor synchronisiert automatisch. Die Quizfragen existieren in der Questions-Kollektion hingegen nur auf dem Server.

Jede Kollektion erhält einen eindeutigen Namen als Argument und ist damit automatisch persistent:

Players = new Meteor.Collection("players");
Logs = new Meteor.Collection("logs");

Soll nicht persistiert werden, übergibt man keinen Namen. Dieses Vorgehen eignet sich gut, um Daten temporär einem Template zur Verfügung zu stellen.

Um mit den Kollektionen zu arbeiten, lehnt sich Meteor eng an die existierende MongoDB-API an und kapselt wichtige Datenbankfunktionen wie find() beziehungsweise findOne(), insert(), update() und remove(). Beispiele für den Einsatz sind in der Dokumentation [8] von Meteor aufgeführt.

Standardmäßig ist eine neue Meteor-Applikation mit dem "insecure"-Flag versehen, was es erlaubt, jeden Client beziehungsweise jeden Nutzer (auch anonyme, nicht authentifizierte und nicht autorisierte) auf die Datenbank zugreifen und jede beliebige Operation ausführen zu lassen. Für Entwicklungszwecke ist das zunächst sinnvoll und erleichtert die Arbeit. Im produktiven Einsatz ist es allerdings sinnvoller, das Flag zu deaktivieren und die Zugriffe auf die Collections/MongoDB durch sogenannte Allow-and-Deny-Mechanismen abzusichern.

Die Allow-Konfiguration beschreibt, wer welche Operation auf welcher Kollektion ausführen darf, die Deny-Konfiguration entsprechend, wem etwas nicht erlaubt ist.

Messages.allow({
insert: function (userId, msg) {
// only logged-in users can insert a new message that they own
return (userId && msg.owner == userId);
},
fetch: ['owner']
});

Messages.deny({
remove: function (userId, msg) {
//can't remove locked messages
return msg.locked;
},
fetch: ['locked']
});

Mechanismen und Methoden

Publish/Subscribe und Methodenaufrufe

Um dem "Überall-Datenbank"-Gedanken entgegenzuwirken und nicht die gesamte Datenbank automatisch allen Clients zugänglich zu machen (autopublish-Flag), lassen sich sensible oder rechenintensive Operationen auch auf dem Server durchführen und die aktiven Clients über das Ergebnis benachrichtigen. Ähnlich wie beim allgemein bekannten Messaging-Verfahren mittels Topics heißt hier der Mechanismus "Publish/Subscribe". Der Server veröffentlicht (publish) das Ergebnis einer Datenbank-Abfrage beziehungsweise Berechnung in Form einer Kollektion, und alle interessierten Clients abonnieren (subscribe) die Events der Veröffentlichung. Auf diese Weise lässt sich verhindern, dass alle Änderungen einer Kollektion an alle Clients propagiert werden und alle Felder öffentlich sind.

Meteor.publish("players", function() {
return Players.find({}, {limit: 10, sort: {score: -1, name: 1}});
});

Das Selektor-Objekt als zweiter Parameter in der find-Anweisung filtert die zehn höchsten Punktstände und liefert die Spieler nach Punkten absteigend sowie nach Namen aufsteigend als Ergebnis zurück. In der Datei server.js ist der Befehl Meteor.publish für die Bekanntgabe der Kollektion an die Clients verantwortlich.

Der Client abonniert die mit dem Bezeichner players ausgestattete Kollektion via

Meteor.subscribe("messages");

Positiver Nebeneffekt: Es werden weniger Daten ausgetauscht. Änderungen im Highscore auf den Plätzen größer zehn spielen keine Rolle für die Darstellung im Client.

Eine weitere Methode, um Berechnungen beziehungsweise Logik vom Client auf den Server zu verlagern und über eine Art "Remote Procedure Call" (RPC) aufzurufen, sind Meteors sogenannte "Method Calls". Mit ihnen lassen sich auf dem Server eine oder mehrere Methoden definieren und als per Remote aufrufbar registrieren. Beispiele hierfür sind das zufällige Selektieren einer neuen Frage oder das Aktualisieren des Punktestandes:

Meteor.methods({
getRandomQuestion: function() {
var q = Questions.find().fetch();
q = _.shuffle(q);
return q[0];
},

updateScore: function(playerId, points) {
Players.update(playerId, {$inc: {score: points}});
}
});

Der Client benötigt keine weitere Konfiguration oder Bekanntmachung der Server-Methoden und kann sie direkt erreichen:

// async call
Meteor.call("getRandomQuestion", _onQuestionReceive);

Im Falle eines asynchronen Aufrufs wird als letzter Parameter eine Callback-Funktion übergeben, die nach dem Abarbeiten der eigentlichen Funktion aufzurufen ist. Ihr lässt sich entweder ein Ergebnis-Objekt (mit den Ergebnissen der Berechnung) oder im Fehlerfall ein Error-Objekt übergeben. So kann die Anwendung auf Fehler in der asynchronen Berechnung reagieren. Ein synchroner Aufruf ist ebenfalls möglich, es wird dann auf die Callback-Funktion verzichtet und der Rückgabewert der Funktion direkt einer Ergebnisvariablen zugeordnet.

Registriert man die rechnerferne Methode nicht nur auf dem Server, sondern mit gleichem Namen auch auf dem Client, lässt sich das Prinzip der "Latency Compensation" ganz leicht umsetzen. In dem Fall wird zwar die Methode auf dem Server aufgerufen und abgearbeitet, gleichzeitig aber ebenfalls die clientseitige Methode aufgerufen und ihr vorläufiges "Ergebnis" (zum Beispiel ein Platzhalter wie "Ihre Daten werden berechnet") an den Aufrufenden geliefert. Sobald das Ergebnis vom Server vorliegt, ersetzt Meteor automatisch das Client-Ergebnis mit diesem. So lassen sich pseudolatenzfreie Anwendungen simulieren und für den Anwender ist ein flüssigeres Arbeiten möglich.

Den Meteor lenken

Für das Implementieren von Views hat sich im JavaScript-Bereich das Arbeiten mit Templates in Verbindung mit dem MVVM-Entwurfsmuster (Model, View, ViewModel) etabliert. Meteor bringt Handlebars [9]für diese Aufgaben mit. Laut Dokumentation ist es allerdings auch möglich, andere Templating-Engines einzubinden.

Handlebars-Templates werden in Dateien mit der Endung "html" abgelegt und mit den Tags <template name="..">..</template> definiert, innerhalb welcher normales HTML zu verwenden ist. Mit der Anweisung {{> name}} lassen sich Templates über ihren Namen an verschiedenen Stellen einbinden. In der Beispiel-Applikation sind sie in thematische Dateien organisiert, so liefert die wichtigste Vorlage mit dem Namen "pokerquiz.html" beispielsweise das Grundgerüst und ruft die anderen Bereiche auf.

Das Zusammenspiel zwischen Server, Client und der Template-Engine lässt sich gut am Ranking-Template, das einen Highscore darstellt, beobachten. Das Propagieren der Daten auf den Client wurde oben bereits angesprochen. Im Client steht die Kollektion zur Verfügung und lässt sich mit der Anweisung Template.ranking.players unter dem Namen players für das Template bekannt machen. Die Sortierung innerhalb der Kollektion ist analog zu der auf dem Server, damit sich Änderungen unmittelbar auswirken, noch bevor die Daten an ihn weitergereicht wurden.

Template.ranking.players = function () {
return Players.find({}, {sort: {score: -1, name: 1}});
};

In der Template-Datei ranking.html ist zuerst das Subtemplate ranking definiert, das im Haupt-Template eingebunden ist. Wesentliches Element ist die each-Anweisung in der Tabelle:

{{#each players}}
{{> player}}
{{/each}}

Sie iteriert über die oben definierte Players-Kollektion und ruft für jede Zeile das Subtemplate player auf. Es füllt die Tabelle mit Inhalt und baut für jeden Spieler eine Zeile mit dem Namen des Spielers und dessen aktuellen Punktestand auf.

<template name="player">
<tr>
<td>{{name}}</td>
<td class="text-right">{{score}}</td>
</tr>
</template>

Neben Schleifen sind Bedingungen sinnvoll, die Template-Bereiche je nach Zustand ein und ausschalten. Im Template "pokerquiz.html" findet sich ab Zeile 19 eine Verzweigung: Nur angemeldete Benutzer sehen Highscore, Quizfragen und Statusmeldungen. Im else-Zweig wird die Aufforderung zum Anmelden präsentiert:

{{#if currentUser}}
<div class="row-fluid">
<div class="span4">
{{> ranking}}
</div>
<div class="span8">
{{> questions}}
</div>
</div>
...
{{else}}
<div class="container"><div class="hero-unit">
<p>Please login in order to get in the play!</p>
</div></div>
{{/if}}

HTML live erleben

Meteor geht mit seinen "Live-HTML"-Features allerdings noch einen Schritt weiter. Mit der Funktion Meteor.render() erzeugt man HTML-Fragmente, die sich automatisch aktualisieren, sobald sich die Daten ändern, von denen sie abhängen (reaktives Vorgehen). Das folgende Beispiel zeigt den Einsatz:

var fragment = Meteor.render(
function () {
var name = Session.get("name") || "Anonymous";
return "<div>Hello, " + name + "</div>";
});
document.body.appendChild(fragment);

Meteor.render() wird eine anonyme Funktion übergeben, die definiert, wie ein HTML-Fragment aufgebaut ist. Die Daten liegen in diesem Fall in einer Session-Variablen vor, appendChild() fügt das Fragment dem aktuellen HTML-Dokument hinzu. Ändert sich nun der Inhalt der Variablen, aktualisiert sich das Fragment automatisch, denn die Session-Funktionen get() und set() sind reaktiv ausgelegt:

Session.set("name", "Bob");

Der Entwickler baut lediglich die Verknüpfung auf und erhält die Aktualisierung der Darstellung vom Framework geschenkt.

Absichern und verteilen

Sicherheit und Authentifizierung

Meteor definiert nicht nur die Applikationsstruktur, sondern bietet auch eine Reihe vordefinierter Basisdienste. Ein gutes Beispiel hierfür ist das Log-in-System. Es stellt eine vordefinierte Benutzeroberfläche und alle wichtigen Grundfunktionen für eine Benutzer-Authentifizierung bereit:

Beeindruckend ist ebenfalls die Liste der zusätzlichen externen Log-in-Provider. Entwickler haben die Qual der Wahl: Von GitHub über Twitter und Facebook bis zu Google sind fast alle namhaften Anbieter vertreten, ihre Verwendung und Integration in die eigene Anwendung lässt sich vergleichsweise einfach konfigurieren. Weitere Provider, die den OAuth2-Standard unterstützen, lassen sich ebenfalls im Handumdrehen einbinden.

Das Meteor-Package nutzt das "Secure Remote Password"-Protokoll (SRP [10]) für die Kommunikation mit den externen Providern: Passwörter werden nur verschlüsselt, nie im Klartext übertragen. Über die Meteor-Konsole fügt der add-Befehl das Package dem Projekt hinzu:

$ meteor add accounts-ui
$ meteor add accounts-*
(* = password, facebook, twitter, google, github, ...)

Für die Applikation ist es notwendig, die Provider in der Datei clients.js zu konfigurieren. Das Beispiel definiert GitHub und Google als alternative Log-in-Provider, wobei je nach Anbieter weitere Einstellungen möglich sind:

Accounts.ui.config({
requestPermissions: {
github: ['user', 'repo']
},
requestOfflineToken: {
google: true
},
passwordSignupFields: 'USERNAME_AND_OPTIONAL_EMAIL'
});

Als letzter Schritt soll der Log-in-Button in der Maske erscheinen. Hierfür definiert das Accounts- UI-Package eine Funktion, die sich leicht in den Templates nutzen lässt:

{{login-buttons}}

Handlebars rendert damit einen vordefinierten Anmeldebereich, in dem alle Log-in-Provider aufgelistet sind, die in der Konfiguration auftauchen. In den Views ist es meist notwendig, einen Bereich nur für bestätigte Benutzer sichtbar zu machen. Dafür kann man in den Templates prüfen, ob ein Benutzer angemeldet ist. Das Abfragen des Nutzerstatus zeigte das oben aufgeführte Beispiel im Bereich Templating.

Vor dem Einsatz muss man die eigene Applikation beim gewünschten Provider anmelden. Am leichtesten geht das, indem man den Provider wie in der Meteor-Dokumentation konfiguriert und erstmalig aufruft. Daraufhin erscheint ein Pop-up mit Schritten zur Konfiguration des Dienstes. Typischerweise erhält man eine Client-Identifikation und einen Schlüssel, die die eigene Applikation identifizieren und beim ersten Login anzugeben sind. Nach der erstmaligen Einstellung erscheint beim Anmelden die typische Log-in-Seite des gewählten Anbieters, oder man wird, sofern man bereits beim entsprechenden OAuth2-Provider angemeldet ist und seine Applikation autorisiert hat, direkt eingeloggt.

Deployment und Packaging

Genauso einfach wie das Installieren und Erzeugen des ersten eignen Projekts, ist die Veröffentlichung einer Applikation. Meteor stellt hierzu seine eigene Infrastruktur zur Verfügung und erlaubt das Deployment eines Projekts unter einer Subdomain von meteor.com mit nur einer Kommandozeile:

$ meteor deploy pokerquiz.meteor.com

Weitere Optionen, wie einen Passwortschutz für das Deployment oder das Löschen der Applikation, stehen mit verschiedenen Kommandozeilen-Parametern zur Verfügung.

Möchte man nicht unter *.meteor.com sondern unter der eigenen Domain erreichbar sein, ist das ebenfalls unter der Nutzung der Meteor-Infrastruktur möglich. Hierzu muss in der Domain-Konfiguration der eigenen Domäne nur der DNS-A-Eintrag auf die IP-Adresse von origin.meteor.com zeigen.

Sind der Nutzung der Meteor-Infrastruktur Riegel vorgeschoben oder möchte man ein gänzlich eigenes System betreiben, benötigt man zunächst einen regulären Node.js-Server und MongoDB. Mit dem bundle-Kommando packt Meteor alle zum Betrieb einer Meteor-Applikation notwendigen Ressourcen in ein Tarball-Verzeichnis zusammen, das sich dann in der eigenen Infrastruktur installieren lässt.

$ meteor bundle pokerquiz.tgz

Im Anschluss sind allerdings weitere Einstellungen zum Betrieb des Servers hinsichtlich Logging, Monitoring, Performance et cetera notwendig.

Was gibt es sonst noch?

Im Node.js-Umfeld haben Entwickler über Node Packaged Modules (npm [11]) Zugriff auf scheinbar unbegrenzte Mengen an Bibliotheken, die teils mehr, teils weniger nützlich sind. Doch wie sieht es bei einer noch recht jungen Plattform wie Meteor aus?

Da Meteor auf Node.js aufsetzt, ist es theoretisch möglich, jede für Node.js zur Verfügung stehende
Bibliothek in Meteor zu nutzen. Hierzu ist für den offiziellen Weg die Bibliothek nur neu zu packen und eine Smart- beziehungsweise Package-JSON-Konfigurationsdatei für die Nutzung in Meteor zu integrieren. Inoffiziell [12] gibt es eine Möglichkeit, npm-Packages direkt in Meteor zu verwenden: Mit der Kommandozeilenerweiterung Meteorite [13] lassen sich eigene Packages von einem GitHub-Verzeichnis in Meteor integrieren. Meteorite schrumpft das Schlüsselwort der Befehle der Plattform auf mrt und stellt ansonsten alle Meteor-Kommandos und noch ein paar zusätzliche, eigene Befehle zur Verfügung.

Ein ständig wachsendes und von der Meteor-Community unterstütztes Verzeichnis ist zudem unter dem Namen Atmosphere [14] verfügbar und bietet interessante und nützliche Erweiterungen. Teilweise haben es einzelne Atmosphere-Packages auch schon in den Meteor-Core-Code geschafft.

Trotz der erst kurzen Zeit, die Meteor verfügbar ist, gibt es zahlreiche Websites mit Tipps und Tricks rund um die Plattform. Die Dokumentation auf der Meteor-Website kann sich sehen lassen und gibt eine gute Hilfestellung bei der täglichen Arbeit. Wem das immer noch nicht genügt oder wer weitere Fragen hat, wird häufig auf der Mailing-Liste [15] fündig oder erhält dort Antwort aus der Meteor-Entwicklergemeinde. Auch bei Stackoverflow sind unter dem Tag "meteor" zahlreiche Einträge zu finden.

Fazit

Auf jeden Fall ist Meteor einen zweiten Blick wert. Die Einarbeitung in die Plattform geht vergleichsweise schnell und dank der Möglichkeit, die Meteor-Infrastruktur zum Deployment der eigenen Anwendung nutzen zu können, lassen sich erste Projekte ohne viel Aufwand der Allgemeinheit zur Verfügung stellen.

Ganz egal, ob man ganze (Web-)Anwendungen oder Erweiterungen für Meteor entwickeln möchte, die Plattform bietet von der Datenbank bis zum Client alles aus einer Hand. Entwickler müssen sich die benötigten Frameworks folglich nicht einzeln zusammensuchen und auf eventuell auftretende gegenseitige negative Beeinflussungen Rücksicht nehmen, sondern können sich auf die Anforderungen ihrer Anwendung konzentrieren.

Niko Köbler
ist freiberuflicher Softwarearchitekt, Entwickler und Coach für (Java-)Enterprise-Projekte, Integrationen und Webentwicklung. Er schreibt regelmäßig für Fachmagazine, ist Co-Organisator der JUG Darmstadt und als Sprecher auf Fachkonferenzen anzutreffen.

Heiko Spindler
ist als Software-Entwickler, Projektleiter und Software-Architekt in vielen Projekten unterschiedlicher Branchen tätig. Er ist seit 2007 Dozent an der Fachhochschule Gießen-Friedberg (für MDA/MDSD).


URL dieses Artikels:
http://www.heise.de/-1949891

Links in diesem Artikel:
[1] http://www.meteor.com
[2] http://www.mongodb.org
[3] http://nodejs.org
[4] http://www.reactivemanifesto.org/
[5] http://roadmap.meteor.com
[6] http://pokerquiz.meteor.com
[7] http://github.com/brainbrix/PokerQuiz
[8] http://docs.meteor.com/#meteor_collection
[9] http://handlebarsjs.com/
[10] http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol
[11] http://npmjs.org
[12] http://meteorhacks.com/complete-npm-integration-for-meteor.html
[13] http://oortcloud.github.io/meteorite/
[14] http://atmosphere.meteor.com
[15] http://groups.google.com/forum/#!forum/meteor-talk