Die Rückkehr des Client-Server-Computing?

Eines der Dinge, die ich in den letzten Monaten in der Entwicklungswelt interessant gefunden habe, ist, wie moderne Anwendungen dazu übergehen, mehr Intelligenz auf dem Client statt auf dem Server zu platzieren. Das Client-Server-Modell ist natürlich nichts Neues: Es ist die Art und Weise, wie traditionelle Anwendungen seit Jahren erstellt werden, wobei Rich-Client-Anwendungen mit serverseitigen Anwendungen kommunizieren. Im Zeitalter des Webs und sogar von Web 2.0 lag der Schwerpunkt jedoch auf Webanwendungen, bei denen sich der Großteil der Informationen auf dem Webserver befand (in der Regel auf Java-basierten Anwendungsservern) und der Client nur eine einfache Webseite war Ein Browser, in dem Sie bei jedem Klick eine neue Seite geladen haben.

In letzter Zeit haben HTML5, CSS und insbesondere JavaScript dazu geführt, dass Entwickler echte Intelligenz und echte Verarbeitung in die Webseite selbst integrieren. Insbesondere haben wir den Aufstieg einer Vielzahl clientseitiger JavaScript-basierter Frameworks erlebt, mit denen es einfacher ist, intelligente Frontends zu erstellen, die vollständig in einem modernen Webbrowser ausgeführt werden. Die beteiligten Browser basieren normalerweise auf der Webkit-Engine, einschließlich Chrome und Safari. Die meisten Apps scheinen jedoch auch in den aktuellen Versionen von Firefox und Internet Explorer einwandfrei zu funktionieren. Sie erhalten eine komplexere Webseite, die sich dynamisch ändert und bei Bedarf Daten vom Server abruft.

Insbesondere drei MVC-Frameworks scheinen die meiste Aufmerksamkeit auf sich zu ziehen: Backbone.js, Ember.js und Angular.js. (MVC steht für Model-View-Controller - es ist im Wesentlichen die Architektur hinter Web-Client-Computing. Das "js" steht für JavaScript.) Im Wesentlichen ist dies alles ein Ergebnis des AJAX-Ansatzes (Asynchronous JavaScript and XML), der im letzten Jahrzehnt oder in den letzten Jahren populär war so, aber viel reifer und fast standardisiert. Die Idee ist, mehr über den Status und die Informationen im Browser zu erfahren und den Browser dann mit den REST-APIs auf der Serverseite zu verbinden.

Das Backbone ist vielleicht das grundlegendste und minimalste dieser Frameworks. Es wird in unterschiedlichem Umfang von vielen beliebten Websites verwendet. Ember ist aus einem von Apple unterstützten Framework namens Sproutcore hervorgegangen und ist ein viel umfassenderes Framework, mit dem Sie Anwendungen im Desktop-Stil erstellen können. Es wird häufig mit Bootstrap verwendet - einer Reihe von Vorlagen für HTML und CSS, die ursprünglich von Twitter-Mitarbeitern erstellt wurden. Angular ist Googles Alternative, die irgendwo dazwischen zu liegen scheint - manche Leute denken, dass sie etwas flexibler oder zumindest weniger einfühlsam ist als Ember, aber umfassender als Backbone. (Beachten Sie, dass Google die Entwickler dazu drängt, Angular zu verwenden, um die Qualität der Codierung zu verbessern. Intern werden jedoch andere proprietäre Frameworks verwendet.) Sogar Microsoft hat Visual Studio Hooks für diese Frameworks hinzugefügt.

Da dies das Web ist, gibt es Dutzende von Alternativen. Eines der interessanteren, von denen ich in letzter Zeit gehört habe, ist Meteor, das sowohl auf der Client- als auch auf der Serverseite mit JavaScript arbeiten soll. Aber das ist noch sehr früh und ich kenne noch keine wirklichen Benutzer. In der Zwischenzeit spielen mehr Entwickler mit Node.js, die häufig für serverseitige JavaScript-Implementierungen verwendet werden.

Der Vorteil solcher Frameworks scheint klar zu sein. Rich-Web-Client-Anwendungen sind leistungsstärker als Thin-Client-Anwendungen, bei denen alles auf dem Server ausgeführt wird, sie bieten eine bessere Benutzeroberfläche und die Möglichkeit von Offline-Informationen. Mit diesen Frameworks können Sie Rich-Web-Client-Anwendungen viel schneller erstellen als mit der Möglichkeit, alles von Grund auf neu zu erstellen, und die sich aus ihnen ergebenden Communitys nutzen.

Am wichtigsten ist jedoch, dass Sie mobile Anwendungen erstellen können, die sich auf verschiedene Geräte skalieren lassen, ohne bestimmte native Anwendungen schreiben zu müssen. Es gibt immer noch ein gutes Argument für native Apps, mit denen die spezifischen Funktionen jeder Plattform direkter angesprochen werden können. Viele Entwickler haben jedoch festgestellt, dass solche Frameworks die plattformübergreifende Entwicklung erheblich beschleunigen können, insbesondere in Verbindung mit PhoneGap, einem Open-Source-Framework für Mobilgeräte, das von Adobe gekauft und in das Apache Cordova-Projekt integriert wurde.

Mobile bringt natürlich seine eigenen Einschränkungen mit sich, einschließlich der Geschwindigkeit der Prozessoren und, was vielleicht noch wichtiger ist, der Geschwindigkeit - und manchmal auch der mangelnden - Konnektivität. Ein Grund, warum Menschen Apps über Webseiten mögen, ist, dass Sie häufig die grundlegenden Funktionen über WLAN oder eine schnelle Verbindung herunterladen und nur die benötigten Daten herunterladen können, nicht das gesamte Design. Pakete wie PhoneGap lösen dieses Problem, indem JavaScript in eine heruntergeladene App eingefügt wird.

Es gibt jedoch andere Probleme mit solchen Frameworks. Per Definition erhöht mehr Computing auf der Client-Seite die Komplexität im Vergleich zu einer einfachen Nur-Server-App, und tatsächlich treten einige der Nachteile des alten Client-Server-Modells wieder auf. Entwickler müssen den Staat auf beiden Seiten verwalten. Code an zwei Stellen bedeutet, dass Sie sich an beiden Stellen auf die Sicherheit konzentrieren müssen. Da in einem Entwicklungsteam häufig einige Mitarbeiter am Client und andere am Server arbeiten, treten zusätzliche Kommunikationsprobleme auf. Auf der anderen Seite kehren einige der älteren Probleme von Client-Server nicht zurück, und Sie behalten stattdessen die Vorteile von Web-Software bei. Dies ist eine viel stärker auf Standards und Communitys ausgerichtete Welt, sodass Sie nicht so stark von einer einzigen proprietären Umgebung abhängig sind. Durch Aufteilen des clientseitigen und des serverseitigen Teils können Sie auch eine sauberere, einfachere serverseitige Implementierung erzielen, die nur die Verarbeitung und nicht die Benutzeroberfläche übernimmt und daher möglicherweise weniger Ressourcen benötigt. Sie haben dennoch den Vorteil, dass Sie alle Clients auf einmal aktualisieren können, da der Browser normalerweise den Code vom Server lädt, wenn die App aufgerufen wird.

Wir sehen eindeutig einen Trend zu intelligenteren Web-Clients - nicht in jedem Fall, aber in vielen neuen Anwendungen. Es ist viel schwieriger, ältere Anwendungen auf dieses Modell zu verschieben, aber wir sehen auch einige davon. Es ist nicht ganz das alte Client-Server-Modell, aber es rückt viel näher.