Hallo Bewohner! Erstellen Sie dynamische Webanwendungen mit Express, einer Schlüsselkomponente des Node / JavaScript-Entwicklungsstapels. Ethan Brown beschreibt die Arbeit mit Express 5 durch Erstellen einer vollständigen Anwendung. Das Buch behandelt alle Phasen und Komponenten - vom Server-Rendering bis zur API-Entwicklung für die Arbeit mit Single-Page-Anwendungen (SPA). Express ist der Mittelweg zwischen einem etablierten Framework und keinem Framework, sodass Sie bei Ihren architektonischen Entscheidungen einige Freiheiten haben. Dieses Buch bietet die besten Lösungen für Front-End- und Back-End-Entwickler, die Express verwenden. Lernen Sie, die Webentwicklung aus einem neuen Blickwinkel zu betrachten! - Erstellen Sie ein Template-System zur Anzeige dynamischer Daten. Weitere Informationen zu Anforderungs- und Antwortobjekten, Middleware und URL-Routing.- Erstellen Sie eine Simulation der Produktionsumgebung und testen Sie diese. - Lernen Sie die Langzeitspeicherung von Informationen in Dokumentendatenbanken mit MongoDB und in relationalen Datenbanken mit PostgreSQL. - Teilen Sie Ihre Ressourcen dank der API mit anderen Programmen. - Erstellen Sie sichere Anwendungen mithilfe von Authentifizierung, Autorisierung und HTTPS. - Integration in soziale Netzwerke, Aktivierung der Geolokalisierung und vieles mehr. - Implementieren Sie einen Plan zum Starten und Verwalten Ihrer Anwendung. - Beherrschen Sie kritische Debugging-Fähigkeiten.- Erstellen Sie sichere Anwendungen mithilfe von Authentifizierung, Autorisierung und HTTPS. - Integration in soziale Netzwerke, Aktivierung der Geolokalisierung und vieles mehr. - Implementieren Sie einen Plan zum Starten und Verwalten Ihrer Anwendung. - Beherrschen Sie kritische Debugging-Fähigkeiten.- Erstellen Sie sichere Anwendungen mithilfe von Authentifizierung, Autorisierung und HTTPS. - Integration in soziale Netzwerke, Aktivierung der Geolokalisierung und vieles mehr. - Implementieren Sie einen Plan zum Starten und Verwalten Ihrer Anwendung. - Beherrschen Sie kritische Debugging-Fähigkeiten.
Content Delivery-Netzwerke
Wenn Sie Ihre Site zur Produktion bringen, sollten die statischen Assets irgendwo im Internet hochgeladen werden. Möglicherweise sind Sie es gewohnt, sie auf demselben Server abzulegen, auf dem Ihr gesamtes dynamisches HTML generiert wird. In unserem bisherigen Beispiel wurde auch dieser Ansatz verwendet: Der vom Befehl node meadowlark.js gestartete Node / Express-Server bedient sowohl alle Arten von HTML als auch statische Ressourcen. Wenn Sie jedoch die Leistung Ihrer Website optimieren (oder in Zukunft beibehalten) möchten, müssen Sie in der Lage sein, statische Ressourcen in einem Content Delivery Network (CDN) zu hosten. CDN ist ein Server, der für die Bereitstellung statischer Ressourcen optimiert ist. Es werden spezielle Header verwendet (über die wir in Kürze mehr erfahren werden), die das Zwischenspeichern von Browsern ermöglichen.
Darüber hinaus kann ein CDN eine geografische Optimierung (häufig als Edge-Caching bezeichnet) enthalten. Dies bedeutet, dass statische Inhalte von dem Server bereitgestellt werden, der Ihrem Client am nächsten liegt. Obwohl das Internet sehr schnell ist (natürlich funktioniert es nicht mit Lichtgeschwindigkeit, sondern in der Nähe), werden Daten aus einer Entfernung von Hunderten von Kilometern noch schneller als von Tausenden geliefert. Die Zeitersparnis ist in jedem Einzelfall unbedeutend, aber wenn sie mit der Anzahl der Benutzer, Anforderungen und Ressourcen multipliziert wird, wird sie schnell beeindruckend.
Die meisten Ihrer statischen Ressourcen werden in HTML-Ansichten referenziert
<link> CSS-, <script> — JavaScript, <img> ,
Es ist üblich, statische Links in CSS zu haben, normalerweise in der Eigenschaft "Hintergrundbild". Schließlich wird in JavaScript manchmal auf statische Ressourcen verwiesen, z. B. kann JavaScript-Code Tags dynamisch ändern oder einfügen.
<img>
oder die Eigenschaften des Hintergrundbildes.
Machen Sie sich bei der Verwendung eines CDN keine Sorgen über die domänenübergreifende gemeinsame Nutzung von Ressourcen (CORS). In HTML geladene externe Ressourcen unterliegen nicht den CORS-Regeln: Sie müssen CORS nur für über Ajax geladene Ressourcen aktivieren (siehe Kapitel 15).
Entwerfen für ein CDN
Wie Sie ein CDN verwenden, hängt von der Architektur Ihrer Site ab. In den meisten Content Delivery-Netzwerken können Sie Routing-Regeln festlegen, um zu bestimmen, wohin eingehende Anforderungen gesendet werden sollen. Während Sie ziemlich komplexe Routing-Regeln festlegen können, läuft es normalerweise darauf hinaus, statische Ressourcenanforderungen an einen Speicherort (normalerweise von Ihrem CDN bereitgestellt) und dynamische Endpunktanforderungen (dynamische Seiten oder API-Endpunkte) an einen anderen zu senden.
Das Auswählen und Konfigurieren eines CDN ist ein umfangreiches Thema, das ich hier nicht behandeln werde, aber ich werde Ihnen einige grundlegende Informationen geben, die Ihnen beim Einrichten des CDN Ihrer Wahl helfen.
Der einfachste Ansatz zur Strukturierung Ihrer Anwendung besteht darin, dynamische und statische Ressourcen leicht unterscheidbar zu machen. Dadurch werden Ihre CDN-Routing-Regeln so einfach wie möglich gehalten. Dies kann zwar mithilfe von Subdomains erreicht werden (z. B. werden dynamische Ressourcen von meadowlark.com und statische Ressourcen von static.meadowlark.com bereitgestellt), dieser Ansatz erhöht jedoch die Komplexität und erschwert die lokale Entwicklung. Eine einfachere Möglichkeit ist die Verwendung von Anforderungspfaden: Alles, was mit / public / beginnt, sind statische Ressourcen, und alles andere ist dynamisch. Der Ansatz kann anders sein, wenn Sie Inhalte mit Express generieren oder Express verwenden, um eine API für eine einzelne Seitenanwendung bereitzustellen.
Serverseitige Rendering-Website
Wenn Sie Express zum Rendern von dynamischem HTML verwenden (mit anderen Worten, alles, was mit / static / beginnt), sind statische Ressourcen, und alles andere ist dynamisch. Bei diesem Ansatz werden alle Ihre (dynamisch generierten) URLs so sein, wie Sie es möchten (es sei denn, sie beginnen natürlich mit / static /!). Allen statischen Ressourcen wird / static / vorangestellt:
<img src="/static/img/meadowlark-logo-1.png" alt="Meadowlark Logo">
<a href="/about">Meadowlark Travel</a>.
Bisher haben wir in diesem Buch statische Middleware verwendet, als ob alle statischen Ressourcen im Stammverzeichnis angeordnet wären. Wenn Sie also die statische Ressource foo.png im öffentlichen Ordner ablegen, verweisen wir auf sie unter dem URL-Pfad /foo.png, nicht auf /static/foo.png. Natürlich ist es möglich, ein statisches Unterverzeichnis innerhalb des vorhandenen öffentlichen Verzeichnisses zu erstellen, und die URL für /public/static/foo.png lautet /static/foo.png, aber das ist nicht sehr klug. Glücklicherweise können wir dies mit der statischen Middleware vermeiden, indem wir beim Aufrufen von app.use einen anderen Pfad angeben:
app.use('/static', express.static('public'))
In der Entwicklungsumgebung können wir jetzt dieselbe URL-Struktur wie bei der Ausnutzung verwenden. Wenn der Inhalt des öffentlichen Ordners und des CDN synchron sind, können Sie an beiden Stellen auf statische Ressourcen verweisen und nahtlos zwischen Entwicklung und Produktion wechseln.
Wenn Sie das Routing für das CDN einrichten (Sie müssen sich auf Ihre CDN-Dokumentation beziehen), sieht das Routing folgendermaßen aus.
Einzelne Seite Anwendungen
Einzelne Seite Anwendungen im Allgemeinen das Gegenteil von dem serverseitigen gerenderte Webseiten sind: nur die API werden an den Server übergeben werden (zum Beispiel jede Anforderung ab / api), alles andere ist auf statische Dateispeicher übergeben.
In Kapitel 16 haben Sie gesehen, dass Sie eine Assembly zum Betreiben Ihrer Anwendung erstellen können, die alle statischen Ressourcen enthält, die in das CDN geladen werden. Dann müssen Sie nur noch sicherstellen, dass Ihr API-Routing-Setup korrekt ist. Auf diese Weise erhalten Sie das folgende Routing.
Nachdem wir nun gelernt haben, wie eine Anwendung strukturiert wird, um nahtlos von der Entwicklung zur Produktion überzugehen, schauen wir uns an, was beim Caching tatsächlich passiert und wie die Leistung optimiert wird.
Zwischenspeichern statischer Ressourcen Unabhängig davon,
ob Sie Express oder CDN zum Bereitstellen statischer Ressourcen verwenden, sollten Sie die HTTP-Anforderungsheader kennen, mit denen der Browser bestimmt, wann und wie statische Ressourcen zwischengespeichert werden.
- Läuft ab / Cache-Kontrolle. Diese beiden Header teilen Ihrem Browser mit, wie lange eine Ressource maximal zwischengespeichert werden kann. Der Browser nimmt sie ernst: Wenn sie ihm sagen, dass er etwas für einen Monat speichern soll, wird er es einfach einen Monat lang nicht erneut herunterladen, solange es im Cache verbleibt. Es ist wichtig zu verstehen, dass der Browser möglicherweise ein Bild vor dem Ablaufdatum aus Gründen aus dem Cache löscht, die Sie nicht kontrollieren können. Beispielsweise kann der Benutzer den Cache manuell leeren oder der Browser kann Ihre Ressource löschen, um Platz für die Ressourcen zu schaffen, die der Benutzer häufiger besucht. Sie benötigen nur einen dieser Header. Expires wird in größerem Umfang unterstützt, daher ist es vorzuziehen, es zu verwenden. Wenn sich die Ressource im Cache befindet und noch nicht abgelaufen ist,Der Browser führt die GET-Anforderung überhaupt nicht aus, was die Leistung insbesondere auf Mobilgeräten verbessert.
- Zuletzt geändert / ETag. Stellen Sie eine Art Versionskontrolle bereit: Wenn der Browser eine Ressource auschecken muss, überprüft er diese Tags, bevor er den Inhalt lädt. Die GET-Anforderung an den Server wird weiterhin ausgeführt. Wenn die in diesen Headern zurückgegebenen Werte dem Browser jedoch zeigen, dass sich die Ressource nicht geändert hat, fährt der Browser nicht mit dem Herunterladen der Datei fort. Wie der Name schon sagt, können Sie mit "Zuletzt geändert" das Datum festlegen, an dem ein Asset zuletzt geändert wurde. Mit ETag können Sie eine beliebige Zeichenfolge verwenden, normalerweise eine Versionszeichenfolge oder einen Inhalts-Hash.
Verwenden Sie beim Ausgeben statischer Ressourcen den Expires-Header und entweder Last-Modified oder ETag. Die in Express integrierte statische Middleware installiert Cache-Control, verarbeitet jedoch weder Last-Modified noch ETag. Daher ist es für die Entwicklung geeignet, aber nicht für den Betrieb.
Wenn Sie Ihre statischen Assets auf einem CDN wie Amazon CloudFront, Microsoft Azure, Fastly, Cloudflare, Akamai oder StackPath hosten, erhalten Sie einen Bonus: Die meisten dieser Details werden für Sie verarbeitet. Sie können Feineinstellungen vornehmen, obwohl die Standardeinstellungen in einem dieser Dienste ebenfalls in Ordnung sind.
Statischen Inhalt ändern
Durch das Zwischenspeichern wird die Leistung Ihrer Website erheblich verbessert, jedoch nicht ohne Konsequenzen. Insbesondere wenn sich eine der statischen Ressourcen ändert, sehen Clients die Änderung möglicherweise erst, wenn die im Browser zwischengespeicherten Versionen abgelaufen sind. Google empfiehlt, das Caching für einen Monat, vorzugsweise für ein Jahr, durchzuführen. Stellen Sie sich einen Benutzer vor, der Ihre Website jeden Tag über denselben Browser besucht: Er kann Ihre Updates erst nach einem Jahr sehen!
Dies ist natürlich keine wünschenswerte Situation, aber Sie können Ihren Benutzern nicht sagen, dass sie den Cache leeren sollen. Die Lösung für dieses Problem besteht darin, das Cache-Busting zu deaktivieren. Mit diesem Trick können Sie steuern, wann der Browser die Ressource neu laden soll. Diese Methode fügt dem Dateinamen einfach einige Versionsinformationen hinzu. Wenn Sie eine Ressource aktualisieren, ändert sich der Name der Ressource und der Browser kann sie herunterladen. In der Regel ist dies gleichbedeutend mit der Steuerung der Versionen der Ressource (main.2.css oder main.css? Version = 2) oder dem Hinzufügen einer Art Hash (main.e16b7e149dccfcc399e025e0c454bf77.css). Unabhängig davon, welche Methode Sie beim Aktualisieren einer Ressource verwenden, ändert sich ihr Name und der Browser kann sie laden.
Sie können dasselbe mit Multimedia-Ressourcen tun. Nehmen wir unser Logo (/static/img/meadowlark_logo.png). Wenn wir es auf ein CDN setzen, um die Leistung zu maximieren, indem wir die Aufbewahrungsdauer auf ein Jahr festlegen und dann das Logo ändern, sehen Benutzer die Änderung möglicherweise ein Jahr lang nicht. Wenn wir das Logo jedoch in /static/img/meadowlark_logo-1.png umbenennen und diese Änderung im HTML-Code berücksichtigen, muss der Browser es herunterladen, da es sich anscheinend um eine neue Ressource handelt.
Wenn Sie sich für ein einseitiges Anwendungsframework wie "create-react-app" oder ähnliches entschieden haben, wird in der Erstellungsphase eine Zusammenstellung gebrauchsfertiger Ressourcen mit hinzugefügten Hashes erstellt.
Wenn Sie bei Null anfangen, möchten Sie sich wahrscheinlich die Builder ansehen (das ist es, was sich unter der Haube von Single-Page-Anwendungsframeworks befindet). JavaScript, CSS und einige andere Arten statischer Ressourcen werden in möglichst wenigen Assemblys gebündelt und das Ergebnis so weit wie möglich minimiert. Build-Anpassung ist ein großes Thema, aber zum Glück gibt es viele gute Dokumentationen. Nachfolgend finden Sie die derzeit beliebtesten Sammler.
- Webpack (https://webpack.js.org/). Einer der ersten Sammler, der echte Fortschritte erzielt hat. Er hat immer noch viele Unterstützer. Es ist sehr komplex und es gibt einen Preis für diese Komplexität: Die Lernkurve ist steil. Dieser Packer eignet sich jedoch gut zum Erlernen der Grundlagen.
- Paket (https://parceljs.org/). Erschien vor kurzem und machte viel Lärm. Es ist sehr gut dokumentiert, sehr schnell und vor allem hat es die kürzeste Lernkurve. Es ist geeignet, wenn Sie die Arbeit schnell und problemlos erledigen müssen.
- Rollup (https://rollupjs.org/). Es liegt irgendwo zwischen Webpack und Paket. Wie Webpack ist es robust und funktionsreich. Der Einstieg ist jedoch einfacher als bei Webpack, jedoch nicht so einfach wie bei Parcel.
Zusammenfassung
Bei aller scheinbaren Einfachheit sind statische Ressourcen ein großer Aufwand. Sie machen jedoch den Großteil der an Ihre Besucher übermittelten Daten aus, sodass sich die Zeit, die Sie für deren Optimierung aufgewendet haben, mit Zinsen auszahlt.
Eine praktikable Lösung für statische Ressourcen, die zuvor nicht erwähnt wurde, besteht darin, statische Ressourcen einem CDN zur Verfügung zu stellen und in Ansichten und CSS immer die vollständige URL der Ressource zu verwenden. Dieser Ansatz hat den Vorteil, dass er sehr einfach ist. Wenn Sie jedoch jemals einen einwöchigen Hackathon in einer Waldhütte ohne Internetzugang veranstalten möchten, sind Sie in Schwierigkeiten!
Eine sorgfältige Montage und Minimierung ist ein weiterer Bereich, in dem Sie Zeit sparen können, wenn die Leistungssteigerungen Ihrer Anwendung den Aufwand nicht rechtfertigen. Insbesondere wenn Sie nur eine oder zwei JavaScript-Dateien auf Ihrer Site haben und sich das gesamte CSS in derselben Datei befindet, können Sie das Erstellen insgesamt überspringen, aber reale Anwendungen wachsen mit der Zeit tendenziell.
Unabhängig davon, für welche Methode Sie statische Ressourcen bereitstellen, empfehle ich Ihnen, diese separat hochzuladen, vorzugsweise auf ein CDN. Wenn es Ihnen als problematisch erscheint, versichere ich Ihnen: Es ist überhaupt nicht so schwierig, wie es scheint. Insbesondere, wenn Sie zuvor ein wenig Zeit mit dem Bereitstellungssystem verbracht haben, damit die Bereitstellung statischer Ressourcen an einem Standort und von Anwendungen an einem anderen automatisch erfolgt.
Wenn Sie sich Sorgen über die Kosten für das Hosting auf einem CDN machen, sollten Sie sich die Beträge ansehen, die Sie derzeit für das Hosting bezahlen. Die meisten Hosting-Anbieter verlangen viel Geld für den Datenverkehr, auch wenn Sie nichts davon wissen. Wenn Ihre Website jedoch plötzlich auf Slashdot gelistet ist und Sie den Slashdot-Effekt bemerken, erhalten Sie möglicherweise eine völlig unerwartete Hosting-Rechnung. CDN-Hosting ist normalerweise so eingerichtet, dass Sie nur für das bezahlen, was Sie verwenden. Zum Beispiel verbraucht die Site, die ich für ein lokales mittelständisches Unternehmen betreibe, ungefähr 20 GB Datenverkehr pro Monat, während die statischen Hosting-Gebühren (eine sehr medienintensive Site) nur ein paar Dollar pro Monat betragen.
Das Einfügen statischer Ressourcen in ein CDN bietet erhebliche Vorteile, und die Kosten und Unannehmlichkeiten sind minimal. Ich rate Ihnen daher dringend, diesen Pfad zu wählen.
Mit bestimmten JavaScript-Tricks im Browser können Sie nicht kompiliertes WENIGER verwenden. Dieser Ansatz kann jedoch negative Auswirkungen auf die Leistung haben. Ich empfehle daher nicht, ihn zu verwenden.
Weitere Details zum Buch finden Sie auf der Website des Verlags
» Inhaltsverzeichnis
» Auszug
für Einwohner 25% Rabatt auf Gutschein - JavaScript
Nach Zahlungseingang für die Papierversion des Buches wird ein E-Book per E-Mail verschickt. Mail.