it-swarm.com.de

Vor- und Nachteile von "getrennten" Webanwendungen

Ich bin gerade dabei, eine (in Kürze) ziemlich große PHP/MySQL-Webanwendung zu entwerfen. Ich bin zu einer Weggabelung in Bezug auf die innere Architektur gekommen; Ich kann die Website als "traditionelle" Webanwendung erstellen, bei der der Server bei einer Anforderung eine HTML-Seite erstellt, die gesamte Seite sendet und der Browser sie wiedergibt, oder ich kann sie als "separate" Webanwendung erstellen "Webanwendung, bei der die gesamte HTML - Struktur und der gesamte Code der Anwendung beim ersten Laden dem Browser zur Verfügung gestellt werden und die Anwendung JavaScript - Rückrufe verwendet, um bestimmte Daten abzurufen oder Befehle über eine einheitliche API auszugeben. Außerdem habe ich vor, dass es mehrere Versionen der Website gibt (Desktop, Handy, iPhone/Android-Handy, suchmaschinenfreundlich usw.) und irgendwann sogar eigenständige Handy- oder Desktop-Apps.

Welche Vor- und Nachteile haben Sie als Webentwickler bei jeder dieser Architekturen? Gibt es einen klaren Grund, warum ich übereinander gehen sollte? Ist es eher eine Sache der Entwicklerpräferenz?

3
Adam Maras

Zunächst einmal hat die Entscheidung, ob Sie mit einer asynchronen Website arbeiten oder nicht, keinen großen Einfluss auf Ihre Fähigkeit, iPhone/Mobile- und Desktop-Apps zu erstellen, da diese nichts damit zu tun haben. In beiden Fällen können Sie Ihren Code nicht wiederverwenden.

Asynchrone Sites können ebenso langsam oder langsamer als normale Sites sein. Normalerweise wird diese Art von Funktionalität aus einem bestimmten Grund hinzugefügt, um das Benutzererlebnis zu verbessern. Die Verwendung von JavaScript kann Sie bei der Suchmaschinenoptimierung verletzen, da Webcrawler die Absicht des JavaScript nicht vollständig verstehen und es daher meistens ignorieren.

Ich denke, was Sie suchen, ist eine Möglichkeit, Ihren Entwicklungsaufwand zu reduzieren, indem Sie Ihre funktionale (mittlere) Schicht nur einmal schreiben und für alle Ihre Apps dieselbe verwenden. In diesem Fall denke ich, dass es einen Wert gibt, aber ehrlich gesagt ist es schwieriger, solche Architekturen einzurichten, und es kostet viel Zeit. Ich bin der Meinung, dass Sie Ihre Website so gut wie möglich entwickeln und Ihren Middle Tier-Code so stark wie möglich halten sollten. Auf diese Weise können Sie, wenn Sie eine iPhone-App oder etwas anderes hinzufügen möchten, einfacher zu einem Modell mit einer gemeinsamen mittleren Ebene wechseln

Was ich hier wirklich befürworte, sind kleine Schritte. Versuchen Sie nicht, jetzt Code zu schreiben, um Dinge zu handhaben, die Sie noch nicht kennen. Schreiben Sie einfach den Code, den Sie benötigen, und gestalten Sie ihn so flexibel wie möglich.

4
Ben Hoffman

Ich denke, die Idee einer "getrennten" Anwendung, die sich stark auf JavaScript/AJAX stützt, wird Sie in große Schwierigkeiten bringen. Ein paar Dinge aus meinem Kopf:

  1. Es wird schlecht für SEO sein, da es für Google schwierig sein wird, irgendetwas zu indizieren.
  2. Es wird schwer, es "bookmarkable" zu machen
  3. Sie werden Schwierigkeiten mit Mobilgeräten haben, da viele von ihnen nur sehr eingeschränkten (oder defekten) Javascript-Support haben.
5
Eric Petroelje

Erstens, keine Beleidigung, wenn diese Antwort zu offensichtlich oder grundlegend ist. Ihre Verwendung von "Separated" anstelle von Begriffen wie Ajax oder jQuery lässt mich weniger Erfahrung mit diesem Thema vermuten. Natürlich könnte ich die Frage falsch verstehen, also entschuldige ich mich, wenn das der Fall ist.

Verwenden Sie beide, aber mit Bedacht

Überlegen Sie sich, wo und wie eine Aufgabe am effizientesten erledigt wird, und wählen Sie dabei serverseitige oder clientseitige Aufgaben aus. Auf diese Weise können Sie Seiten schnell (auf dem Server) rendern, aber die Arbeit in den Browser verlagern, wo dies sinnvoll ist. Und es wird Grauzonen geben, in denen Sie nur ein Urteil abgeben müssen. Ihre Aufgabe ist es, eine kluge Arbeitsteilung zu finden.

Was gehört zur Serverseite?

(Dies ist ein extremes Beispiel, um den Punkt zu veranschaulichen.) Angenommen, Sie schreiben eine Web-App, die eine Art von Suche ausführt. Sie schreiben kein browserseitiges Javascript, um einen serverseitigen PHP Webservice aufzurufen, um eine gesamte 2-GB-Datenbank abzurufen, um "Ihren Server freizugeben" und die Suche auf den Computer des Benutzers zu verlagern. Sie erhalten die Suchbegriffe vom Benutzer mit einem Formular, POST das an den Server zurückgesendet wird, um die Datenbank direkt abzufragen, und senden die Ergebnisse vom Server an den Browser zurück.

Die Logik hier ist, dass die Datenbank selbst weiß, wie die Abfrage am besten ausgeführt wird, der Server näher an den Quelldaten ist und weniger Daten zwischen Komponenten verschoben werden müssen. Der Browser benötigt nur das, was er anzeigt, also senden Sie nicht alles an den Browser. (Ganz zu schweigen von der relativen Sprachleistung.)

Was gehört zum Browser?

Browser-Code ist Ihr "getrenntes" Szenario (wenn ich richtig verstehe). Damit der Browser jedoch die meisten intelligenten Funktionen ausführen kann, muss er über eine Serverkooperation verfügen.

Okay, deine Such-App funktioniert, aber du willst sie mit ein paar schicken Ajax-Hosen aufpeppen. Schreiben Sie einen PHP Webservice, um ein paar Buchstaben aufzunehmen und passende Suchbegriffe zurückzugeben, a la die "Suchvorschlag" -Funktion von Bing , Google usw. Schreiben Sie Ihren Browser-Code, um nur Begriffe vorzuschlagen, nachdem der Benutzer drei oder vier Buchstaben eingegeben hat, sodass Ihre Vorschlagsliste klein ist. Indizieren Sie Ihre Datenbank auf dem Server in diesem Feld, damit die Suche schnell und schnell vonstatten geht.

Hier denkt man, dass "Suchvorschlag" eine Funktion ist, die zwischen Server und Client aufgeteilt werden muss . Der Browser kann schnell mit gezielten, kleinen Datenmengen umgehen. Der Server kann diesen gezielten, kleinen Datenstapel abrufen und an den Client weitergeben. Eine schlechte Unterteilung besteht darin, dass der Server eine Monsterliste (z. B. 500.000 Elemente) möglicher Feldwerte als XML-Insel in die HTML-Seite einbettet und den Browser nach diesen Angaben suchen lässt. (a) das Senden all dieser Daten an den Browser ist langsam, (b) das Durchsuchen in Javascript ist niemals so schnell wie das Durchsuchen durch die Datenbank, und (c) Sie können den Computer eines Benutzers in die Luft jagen, indem Sie all diese Daten in den Anwendungsbereich seines Browsers stopfen. Andererseits müssen Sie sicherstellen , dass der Ajax-Aufruf an den Server und die anschließende Abfrage und Rückgabe superschnell sind . Kein Dilly-Dallying.

Wo ist die Grauzone?

Auch hier ist es ein Urteilsspruch. Oben habe ich über den Server gesprochen, der die Suche durchführt, und dann die Ergebnisse an den Browser gesendet. Es stellt sich jedoch die Frage, ob Sie den Browser die Suchbegriffe mit dem Formular senden lassen und den Server die Ergebnisseite rendern lassen oder ob Sie clientseitig Ajax/Javascript verwenden, um die Suchbegriffe zu senden und die Ergebnisse abzurufen, und sie dann rendern in einem DIV, um eine Seitenaktualisierung zu vermeiden? Beides ist gültig. Ressourcenseitig gibt es keinen wirklichen Vorteil. Die Ajax-Methode kann eine bessere Benutzererfahrung bieten, kann jedoch abhängig von Ihrer App und den Umständen einige andere Herausforderungen mit sich bringen (z. B. Sicherheit).

Endeffekt

Verwenden Sie beide entsprechend. Denken und lernen Sie nicht nur über die Leistung und Effizienz der Architektur nach. Bewegen Sie weniger Daten, weniger Male. Sie entlasten Ihre Server, Ihre Datenbanken und die Browser Ihrer Benutzer.

2
b w

Um den Code wiederverwenden zu können, können Sie immer XSLT für die Generierung von Zielseiten betrachten und dann über XML/JSON-Schnittstellen für AJAX (unter Verwendung der XML-Schnittstelle für die XSLT-Zielseiten) verfügen.

Sie würden normalerweise zulassen, dass der Inhalt und die Interaktion auf einer RESTful-Schnittstelle mit einem Präfix/json/... und/xml/... funktionieren und Ihren Hauptinhalt hosten, der über XSLT auf/... in Markup konvertiert wird.

Auf diese Weise können Personen auf jeder Seite landen und plötzlich die vollständige AJAX Website anzeigen. Spinnen können Ihre Website crawlen und Sie haben sich in erster Linie auf die Inhalte/Schnittstellen konzentriert - scheint ein Gewinn zu sein.

Mobile Websites erfordern manchmal unterschiedliche Layouts (nur für iPhone bestimmte Websites?). Eine einfache XSLT-Konvertierung hier oder da für verschiedene Benutzerclients kann alles, was Sie bisher getan haben, wiederverwenden.

Denken Sie daran, für eine einfache HTML-Ausgabe und Navigation zu sorgen. Die AJAX -Vereinfachungen können folgen.

PS - Führen Sie die XSLT-Transformationen serverseitig durch

1
Metalshark