Webentwicklung mit Node und Express, 2. Auflage

Kapitel 1. Einführung in Express

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Die JavaScript-Revolution

Bevor ich das Hauptthema dieses Buches vorstelle, ist es wichtig, ein wenig Hintergrund und historischen Kontext zu liefern, und das bedeutet, über JavaScript und Node zu sprechen. Das Zeitalter von JavaScript ist wirklich angebrochen. Von seinen bescheidenen Anfängen als clientseitige Skriptsprache ist es nicht nur auf der Clientseite allgegenwärtig, sondern dank Node auch auf der Serverseite ein echter Renner geworden.

Das Versprechen eines reinen JavaScript-Technologie-Stacks ist klar: kein Kontextwechsel mehr! Du musst nicht mehr gedanklich von JavaScript zu PHP, C#, Ruby oder Python (oder einer anderen serverseitigen Sprache) wechseln. Außerdem ermöglicht es Frontend-Ingenieuren den Sprung zur serverseitigen Programmierung. Das heißt nicht, dass es bei der serverseitigen Programmierung nur um die Sprache geht; es gibt immer noch eine Menge zu lernen. Aber mit JavaScript ist die Sprache zumindest kein Hindernis mehr.

Dieses Buch ist für alle, die das Versprechen des JavaScript-Technologie-Stacks sehen. Vielleicht bist du ein Frontend-Ingenieur, der seine Erfahrungen in der Backend-Entwicklung erweitern möchte. Vielleicht bist du ein erfahrener Backend-Entwickler wie ich, der JavaScript als Alternative zu den etablierten serverseitigen Sprachen sieht.

Wenn du schon so lange Softwareentwicklung betreibst wie ich, hast du viele Sprachen, Frameworks und APIs gesehen, die in Mode gekommen sind. Einige haben sich durchgesetzt, andere sind inzwischen veraltet. Wahrscheinlich bist du stolz auf deine Fähigkeit, schnell neue Sprachen und Systeme zu lernen. Jede neue Sprache, die du kennenlernst, kommt dir ein bisschen vertrauter vor: Hier erkennst du etwas von einer Sprache, die du in der Schule gelernt hast, dort etwas von dem Job, den du vor ein paar Jahren hattest. Es ist gut, diese Art von Perspektive zu haben, aber es ist auch ermüdend. Manchmal möchtest du einfach nur etwas erledigen, ohne eine neue Technologie zu erlernen oder Fähigkeiten abzustauben, die du seit Monaten oder Jahren nicht mehr benutzt hast.

JavaScript mag auf den ersten Blick ein unwahrscheinlicher Verfechter sein. Ich kann das nachempfinden, glaub mir. Wenn du mir 2007 gesagt hättest, dass ich JavaScript nicht nur als meine Lieblingssprache ansehen, sondern auch ein Buch darüber schreiben würde, hätte ich dich für verrückt erklärt. Ich hatte all die üblichen Vorurteile gegen JavaScript: Ich hielt es für eine "Spielzeugsprache", etwas für Amateure und Dilettanten, die es missbrauchen. Fairerweise muss man sagen, dass JavaScript die Messlatte für Amateure niedriger gelegt hat und dass es eine Menge fragwürdiges JavaScript gab, was dem Ruf der Sprache nicht gut getan hat. Um ein bekanntes Sprichwort auf den Kopf zu stellen: "Hasse den Spieler, nicht das Spiel".

Es ist bedauerlich, dass die Menschen dieses Vorurteil gegenüber JavaScript haben. Es hat die Menschen davon abgehalten, zu entdecken, wie leistungsfähig, flexibel und elegant die Sprache ist. Viele Menschen fangen erst jetzt an, JavaScript ernst zu nehmen, obwohl es die Sprache, wie wir sie heute kennen, schon seit 1996 gibt (obwohl viele ihrer attraktiveren Funktionen erst 2005 hinzukamen).

Wenn du dieses Buch in die Hand nimmst, bist du wahrscheinlich von diesem Vorurteil befreit: entweder, weil du es, wie ich, überwunden hast oder weil du es nie hattest. In jedem Fall hast du Glück, und ich freue mich darauf, dir Express vorzustellen, eine Technologie, die durch eine wunderbare und überraschende Sprache ermöglicht wird.

2009, Jahre nachdem die Menschen begonnen hatten, die Leistungsfähigkeit und Ausdruckskraft von JavaScript als Browser-Skriptsprache zu erkennen, erkannte Ryan Dahl das Potenzial von JavaScript als serverseitige Sprache, und Node.js war geboren. Es war eine fruchtbare Zeit für die Internettechnologie. Ruby (und Ruby on Rails) griff einige großartige Ideen aus der akademischen Informatik auf, kombinierte sie mit einigen neuen eigenen Ideen und zeigte der Welt einen schnelleren Weg, Websites und Webanwendungen zu erstellen. Microsoft hat in dem tapferen Versuch, im Internetzeitalter relevant zu werden, mit .NET Erstaunliches geleistet und dabei nicht nur von Ruby und JavaScript, sondern auch von den Fehlern Javas gelernt, während es sich in den Hallen der akademischen Welt bedient hat .

Dank Transkompilierungstechnologien wie Babel haben Webentwickler heute die Freiheit, die allerneuesten JavaScript-Funktionen zu nutzen, ohne befürchten zu müssen, dass sie Nutzer mit älteren Browsern verprellen. Webpack ist zur allgegenwärtigen Lösung für die Verwaltung von Abhängigkeiten in Webanwendungen und zur Sicherstellung der Leistung geworden, und Frameworks wie React, Angular und Vue verändern die Art und Weise, wie die Menschen an die Webentwicklung herangehen, indem sie deklarative Bibliotheken zur Manipulation des Document Object Model (DOM) (wie jQuery) in den Hintergrund drängen.

Es ist eine aufregende Zeit, sich mit Internettechnologie zu beschäftigen. Überall gibt es erstaunliche neue Ideen (oder erstaunliche alte Ideen, die wiederbelebt werden). Der Innovationsgeist und die Aufregung sind so groß wie seit vielen Jahren nicht mehr.

Wir stellen vor: Express

Auf der Express-Website wird Express als "minimalistisches und flexibles Node.js-Webanwendungs-Framework beschrieben, das eine Reihe von robusten Funktionen für Web- und mobile Anwendungen bietet". Aber was bedeutet das eigentlich? Schauen wir uns diese Beschreibung genauer an:

Minimal

Dies ist einer der attraktivsten Aspekte von Express. Oftmals vergessen Entwickler von Frameworks, dass "weniger mehr ist". Die Philosophie von Express ist es, eine minimale Schicht zwischen deinem Gehirn und dem Server zu bilden. Das bedeutet nicht, dass es nicht robust ist oder dass es nicht genügend nützliche Funktionen hat. Es bedeutet, dass es dir weniger im Weg steht und du deine Ideen voll ausleben kannst, während es gleichzeitig etwas Nützliches bietet. Express bietet dir ein minimales Gerüst und du kannst je nach Bedarf verschiedene Teile der Express-Funktionen hinzufügen und alles ersetzen, was deinen Bedürfnissen nicht entspricht. Viele Frameworks geben dir alles vor und lassen dich mit einem aufgeblähten, mysteriösen und komplexen Projekt zurück, bevor du auch nur eine einzige Codezeile geschrieben hast. Oft besteht die erste Aufgabe darin, Zeit damit zu verschwenden, nicht benötigte Funktionen abzuschneiden oder Funktionen zu ersetzen, die den Anforderungen nicht entsprechen. Express verfolgt den gegenteiligen Ansatz und ermöglicht es dir, das hinzuzufügen, was du brauchst, wenn du es brauchst.

Flexibel

Letzten Endes ist das, was Express tut, sehr einfach: Es nimmt HTTP-Anfragen von einem Client entgegen (das kann ein Browser, ein mobiles Gerät, ein anderer Server, eine Desktop-Anwendung ... alles sein, was HTTP spricht) und gibt eine HTTP-Antwort zurück. Dieses grundlegende Muster beschreibt fast alles, was mit dem Internet verbunden ist, und macht Express extrem flexibel in seinen Anwendungen.

Webanwendungs-Framework

Eine genauere Beschreibung wäre vielleicht "serverseitiger Teil eines Webanwendungs-Frameworks". Wenn du heute an ein "Web Application Framework" denkst, denkst du in der Regel an ein Single-Page Application Framework wie React, Angular oder Vue. Doch abgesehen von einer Handvoll eigenständiger Anwendungen müssen die meisten Webanwendungen Daten austauschen und mit anderen Diensten integriert werden. Dies geschieht in der Regel über eine Web-API, die als serverseitige Komponente eines Webanwendungs-Frameworks betrachtet werden kann. Beachte, dass es möglich (und manchmal auch wünschenswert) ist, eine ganze Anwendung nur mit serverseitigem Rendering zu erstellen. In diesem Fall kann Express sehr wohl das gesamte Webanwendungs-Framework darstellen!

Zusätzlich zu den Merkmalen von Express, die in der Beschreibung explizit erwähnt werden, möchte ich zwei weitere hinzufügen:

Schnell

Als Express zum bevorzugten Web-Framework für die Node.js-Entwicklung wurde, erregte es die Aufmerksamkeit großer Unternehmen, die hochleistungsfähige Websites mit hohem Datenverkehr betreiben. Dadurch entstand Druck auf das Express-Team, sich auf die Leistung zu konzentrieren, und heute bietet Express eine führende Leistung für Websites mit hohem Datenverkehr.

Unvoreingenommen

Eines der Markenzeichen des JavaScript-Ökosystems ist seine Größe und Vielfalt. Während Express oft im Zentrum der Node.js-Webentwicklung steht, gibt es Hunderte (wenn nicht Tausende) von Community-Paketen, die in eine Express-Anwendung einfließen. Das Express-Team hat diese Vielfalt des Ökosystems erkannt und darauf mit einem extrem flexiblen Middleware-System reagiert, das es dir leicht macht, die Komponenten deiner Wahl bei der Erstellung deiner Anwendung zu verwenden. Im Laufe der Entwicklung von Express wurden die "eingebauten" Komponenten zugunsten einer konfigurierbaren Middleware aufgegeben.

Ich habe bereits erwähnt, dass Express der "serverseitige Teil" eines Webanwendungs-Frameworks ist... also sollten wir uns vielleicht mit der Beziehung zwischen serverseitigen und clientseitigen Anwendungen beschäftigen.

Serverseitige und clientseitige Anwendungen

Bei einer serverseitigen Anwendung werden die Seiten der Anwendung auf dem Server gerendert (als HTML, CSS, Bilder und andere Multimedia-Assets sowie JavaScript) und an den Client gesendet. Bei einer clientseitigen Anwendung hingegen wird der Großteil der Benutzeroberfläche aus einem Anwendungspaket gerendert, das nur einmal gesendet wird. Das heißt, sobald der Browser das anfängliche (in der Regel sehr minimale) HTML erhält, verwendet er JavaScript, um das DOM dynamisch zu verändern, und muss sich nicht auf den Server verlassen, um neue Seiten anzuzeigen (obwohl die Rohdaten normalerweise immer noch vom Server kommen).

Vor 1999 waren serverseitige Anwendungen der Standard. In diesem Jahr wurde sogar der Begriff Webanwendung offiziell eingeführt. Die Zeit zwischen 1999 und 2012 bezeichne ich als die Web 2.0-Ära, in der die Technologien und Techniken entwickelt wurden, die später zu clientseitigen Anwendungen wurden. Im Jahr 2012, als die Smartphones fest etabliert waren, war es üblich, so wenig Informationen wie möglich über das Netzwerk zu senden, was Client-seitige Anwendungen begünstigte.

Serverseitige Anwendungen werden oft als server-side rendered (SSR) bezeichnet, und clientseitige Anwendungen werden in der Regel single-page applications(SPAs) genannt. Client-seitige Anwendungen werden in Frameworks wie React, Angular und Vue vollständig umgesetzt. Ich war schon immer der Meinung, dass "Single-Page" eine falsche Bezeichnung ist, denn aus Sicht des Nutzers kann es tatsächlich viele Seiten geben. Der einzige Unterschied besteht darin, ob die Seite vom Server ausgeliefert oder dynamisch auf dem Client gerendert wird.

In der Realität sind die Grenzen zwischen serverseitigen und clientseitigen Anwendungen oft fließend. Viele clientseitige Anwendungen haben zwei bis drei HTML-Bündel, die an den Client gesendet werden können (z. B. die öffentliche Schnittstelle und die eingeloggte Schnittstelle oder eine normale Schnittstelle und eine Verwaltungsschnittstelle). Außerdem werden SPAs oft mit SSR kombiniert, um die Leistung beim Laden der ersten Seite zu erhöhen und die Suchmaschinenoptimierung (SEO) zu unterstützen.

Wenn der Server nur wenige HTML-Dateien (in der Regel ein bis drei) sendet und der Nutzer ein reichhaltiges, auf dynamischer DOM-Manipulation basierendes Multiview-Erlebnis hat, sprechen wir von clientseitigem Rendering. Die Daten (in der Regel in Form von JSON) und Multimedia-Assets für die verschiedenen Ansichten kommen in der Regel weiterhin aus dem Netzwerk.

Natürlich ist es Express egal, ob du eine serverseitige oder eine clientseitige Anwendung erstellst. Es macht für Express keinen Unterschied, ob du ein HTML-Paket oder hundert Pakete auslieferst.

Auch wenn SPAs als vorherrschende Webanwendungsarchitektur definitiv "gewonnen" haben, beginnt dieses Buch mit Beispielen, die mit serverseitigen Anwendungen übereinstimmen. Sie sind nach wie vor relevant, und der konzeptionelle Unterschied zwischen dem Servieren eines HTML-Bündels oder mehrerer ist gering. In Kapitel 16 gibt es ein SPA-Beispiel.

Eine kurze Geschichte von Express

Der Erfinder von Express, TJ Holowaychuk, beschreibt Express als ein Web-Framework, das von Sinatra inspiriert ist, einem Web-Framework, das auf Ruby basiert. Es ist nicht verwunderlich, dass Express Anleihen bei einem Framework nimmt, das auf Ruby basiert: Ruby hat eine Vielzahl großartiger Ansätze für die Webentwicklung hervorgebracht, die darauf abzielen, die Webentwicklung schneller, effizienter und wartbarer zu machen.

So sehr Express von Sinatra inspiriert war, so sehr war es auch mit Connect, einer "Plug-in"-Bibliothek für Node, verwoben. Connect hat den Begriff "Middleware" geprägt, um steckbare Node-Module zu beschreiben, die in unterschiedlichem Maße Webanfragen bearbeiten können. 2014, in Version 4.0, löste Express seine Abhängigkeit von Connect auf, verdankt sein Konzept der Middleware aber immer noch Connect.

Hinweis

Express wurde zwischen 2.x und 3.0 und dann noch einmal zwischen 3.x und 4.0 grundlegend überarbeitet. Dieses Buch konzentriert sich auf die Version 4.0.

Node: Eine neue Art von Webserver

In gewisser Weise hat Node viele Gemeinsamkeiten mit anderen beliebten Webservern wie Microsofts Internet Information Services (IIS) oder Apache. Interessanter ist jedoch, wie er sich unterscheidet, also fangen wir dort an.

Ähnlich wie Express ist der Ansatz von Node für Webserver sehr minimalistisch. Im Gegensatz zu IIS oder Apache, mit deren Beherrschung man viele Jahre verbringen kann, ist Node einfach einzurichten und zu konfigurieren. Das soll nicht heißen, dass es trivial ist, Node-Server für eine maximale Leistung in einer Produktionsumgebung einzustellen; es ist nur so, dass die Konfigurationsoptionen einfacher und unkomplizierter sind.

Ein weiterer großer Unterschied zwischen Node und herkömmlichen Webservern ist, dass Node nur einen Thread hat. Auf den ersten Blick mag das wie ein Rückschritt erscheinen. Es stellt sich jedoch heraus, dass es ein Geniestreich ist. Wenn du die Leistung einer Multithreading-Applikation benötigst, kannst du einfach mehrere Instanzen von Node aufsetzen und die Leistungsvorteile von Multithreading nutzen. Der aufmerksame Leser denkt jetzt wahrscheinlich, dass das nur Schall und Rauch ist. Ist Multithreading durch Server-Parallelität (im Gegensatz zu App-Parallelität) nicht einfach nur eine Verschiebung der Komplexität, anstatt sie zu beseitigen? Vielleicht, aber meiner Erfahrung nach hat es die Komplexität genau dorthin verlagert, wo sie sein sollte. Außerdem macht dieser Ansatz angesichts der zunehmenden Beliebtheit von Cloud Computing und der Behandlung von Servern als generische Ware viel mehr Sinn. IIS und Apache sind in der Tat sehr leistungsfähig und darauf ausgelegt, das letzte Quäntchen Leistung aus der heutigen leistungsstarken Hardware herauszukitzeln. Das hat allerdings seinen Preis: Um diese Leistung zu erreichen, müssen sie mit viel Know-how eingerichtet und eingestellt werden.

In Bezug auf die Art und Weise, wie Apps geschrieben werden, haben Node-Apps mehr mit PHP- oder Ruby-Apps gemeinsam als mit .NET- oder Java-Apps. Die JavaScript-Engine, die Node verwendet (Googles V8), kompiliert JavaScript zwar in nativen Maschinencode (ähnlich wie C oder C++), aber sie tut dies transparent,¹ Aus der Sicht des Nutzers verhält sie sich also wie eine rein interpretierte Sprache. Der Verzicht auf einen separaten Kompilierungsschritt reduziert den Wartungs- und Bereitstellungsaufwand: Du musst nur eine JavaScript-Datei aktualisieren, und deine Änderungen sind automatisch verfügbar.

Ein weiterer überzeugender Vorteil von Node-Apps ist, dass Node unglaublich plattformunabhängig ist. Es ist nicht die erste oder einzige plattformunabhängige Servertechnologie, aber die Plattformunabhängigkeit ist eher ein Spektrum als eine binäre Aussage. Dank Mono kannst du zum Beispiel .NET-Anwendungen auf einem Linux-Server laufen lassen, aber das ist ein mühsames Unterfangen, weil die Dokumentation lückenhaft ist und das System nicht kompatibel ist. Genauso kannst du PHP-Anwendungen auf einem Windows-Server ausführen, aber die Einrichtung ist in der Regel nicht so einfach wie auf einem Linux-Rechner. Node hingegen lässt sich auf allen gängigen Betriebssystemen (Windows, macOS und Linux) problemlos einrichten und ermöglicht eine einfache Zusammenarbeit. In Teams, die Websites entwickeln, ist eine Mischung aus PCs und Macs üblich. Bestimmte Plattformen wie .NET stellen Frontend-Entwickler/innen und Designer/innen, die oft Macs benutzen, vor Herausforderungen, was sich stark auf die Zusammenarbeit und Effizienz auswirkt. Die Vorstellung, in wenigen Minuten (oder sogar Sekunden!) einen funktionierenden Server auf einem beliebigen Betriebssystem aufsetzen zu können, ist ein wahr gewordener Traum.

Das Knotenpunkt-Ökosystem

Node ist natürlich das Herzstück des Stacks. Es ist die Software, die es ermöglicht, JavaScript unabhängig vom Browser auf dem Server laufen zu lassen, wodurch wiederum in JavaScript geschriebene Frameworks (wie Express) verwendet werden können. Eine weitere wichtige Komponente ist die Datenbank, auf die wir in Kapitel 13 näher eingehen werden. Nur die einfachsten Web-Apps benötigen eine Datenbank, und es gibt Datenbanken, die sich besser in das Node-Ökosystem einfügen als andere.

Es ist nicht überraschend, dass Datenbankschnittstellen für alle großen relationalen Datenbanken (MySQL, MariaDB, PostgreSQL, Oracle, SQL Server) verfügbar sind. Das Aufkommen der Node-Entwicklung hat jedoch einen neuen Ansatz für die Speicherung von Datenbanken wiederbelebt: die sogenannten NoSQL-Datenbanken. Da es nicht immer hilfreich ist, etwas als das zu definieren, was es nicht ist, fügen wir hinzu, dass diese NoSQL-Datenbanken besser als "Dokumentendatenbanken" oder "Schlüssel/Wertpaardatenbanken" bezeichnet werden sollten. Sie bieten einen konzeptionell einfacheren Ansatz für die Speicherung von Daten. Es gibt viele davon, aber MongoDB ist einer der Spitzenreiter und die NoSQL-Datenbank, die wir in diesem Buch verwenden werden.

Da die Erstellung einer funktionalen Website von mehreren Technologien abhängt, wurden Akronyme entwickelt, um den "Stack" zu beschreiben, auf dem eine Website aufgebaut ist. So wird zum Beispiel die Kombination aus Linux, Apache, MySQL und PHP als LAMP-Stack bezeichnet. Valeri Karpov, ein Ingenieur bei MongoDB, prägte das Akronym MEAN: Mongo, Express, Angular und Node. Die Abkürzung ist zwar einprägsam, aber auch einschränkend: Es gibt so viele Möglichkeiten für Datenbanken und Anwendungsframeworks, dass "MEAN" die Vielfalt des Ökosystems nicht erfasst (außerdem lässt es eine meiner Meinung nach wichtige Komponente außer Acht: Rendering-Engines).

Es ist eine interessante Aufgabe, ein passendes Akronym zu finden. Die unverzichtbare Komponente ist natürlich Node. Es gibt zwar auch andere serverseitige JavaScript-Container, aber Node hat sich als die dominierende Komponente herauskristallisiert. Auch Express ist nicht das einzige verfügbare Web-App-Framework, obwohl es in seiner Dominanz Node sehr nahe kommt. Die beiden anderen Komponenten, die für die Entwicklung von Webanwendungen in der Regel unverzichtbar sind, sind ein Datenbankserver und eine Rendering Engine (entweder eine Templating Engine wie Handlebars oder ein SPA-Framework wie React). Für die letzten beiden Komponenten gibt es nicht so viele eindeutige Spitzenreiter, und ich glaube, dass es nicht gut ist, sich hier einzuschränken.

Das Bindeglied zwischen all diesen Technologien ist JavaScript. Um alle zu berücksichtigen, beziehe ich mich im Folgenden auf denJavaScript-Stack. In diesem Buch sind das Node, Express und MongoDB (es gibt auch ein Beispiel für eine relationale Datenbank inKapitel 13).

Lizenzierung

Wenn du Node-Anwendungen entwickelst, musst du vielleicht mehr auf die Lizenzierung achten als je zuvor (ich jedenfalls habe das getan). Eine der Schönheiten des Node-Ökosystems ist die große Auswahl an Paketen, die dir zur Verfügung stehen. Allerdings hat jedes dieser Pakete seine eigene Lizenzierung, und schlimmer noch, jedes Paket kann von anderen Paketen abhängen, was bedeutet, dass es schwierig sein kann, die Lizenzierung der verschiedenen Teile der von dir geschriebenen Anwendung zu verstehen.

Aber es gibt auch gute Nachrichten. Eine der beliebtesten Lizenzen für Node-Pakete ist die MIT-Lizenz. Sie ist sehr freizügig und erlaubt es dir, fast alles zu tun, was du willst, einschließlich der Verwendung des Pakets in Closed-Source-Software. Du solltest aber nicht einfach davon ausgehen, dass jedes Paket, das du verwendest, MIT-lizenziert ist.

Tipp

Es gibt mehrere Pakete in npm, die versuchen, die Lizenzen der einzelnen Abhängigkeiten in deinem Projekt herauszufinden. Suche bei npm nachnlf oder license-report.

MIT ist die häufigste Lizenz, die du finden wirst, aber du kannst auch die folgenden Lizenzen sehen:

GNU General Public License (GPL)

Die GPL ist eine weit verbreitete Open-Source-Lizenz, die auf clevere Weise dafür sorgt, dass Software frei bleibt. Das heißt, wenn du in deinem Projekt GPL-lizenzierten Code verwendest, muss dein Projekt auch unter der GPL-Lizenz stehen. Das bedeutet natürlich, dass dein Projekt nicht Closed Source sein kann.

Apache 2.0

Diese Lizenz erlaubt dir, wie MIT, eine andere Lizenz für dein Projekt zu verwenden, einschließlich einer Closed-Source-Lizenz. Du musst jedoch auf die Komponenten hinweisen, die die Apache 2.0-Lizenz verwenden.

Berkeley Software Distribution (BSD)

Ähnlich wie die Apache-Lizenz erlaubt dir diese Lizenz, jede beliebige Lizenz für dein Projekt zu verwenden, solange du die BSD-lizenzierten Komponenten erwähnst.

Hinweis

Software ist manchmal doppelt lizenziert (unter zwei verschiedenen Lizenzen). Ein häufiger Grund dafür ist, dass die Software sowohl in GPL-Projekten als auch in Projekten mit freizügigeren Lizenzen verwendet werden kann. (Damit eine Komponente in einer GPL-Software verwendet werden kann, muss die Komponente unter der GPL-Lizenz stehen.) Dieses Lizenzierungsschema wende ich bei meinen eigenen Projekten häufig an: Doppellizenzierung mit GPL und MIT.

Wenn du deine eigenen Pakete schreibst, solltest du ein guter Bürger sein und eine Lizenz für dein Paket wählen und sie korrekt dokumentieren. Es gibt nichts Frustrierenderes für einen Entwickler, als ein Paket von jemandem zu benutzen und im Quellcode nach der Lizenzierung suchen zu müssen oder, schlimmer noch, herauszufinden, dass es gar nicht lizenziert ist.

Fazit

Ich hoffe, dieses Kapitel hat dir einen Einblick gegeben, was Express ist und wie es sich in das größere Node- und JavaScript-Ökosystem einfügt, sowie etwas Klarheit über die Beziehung zwischen serverseitigen und clientseitigen Webanwendungen.

Wenn du immer noch nicht weißt, was Express eigentlich ist, mach dir keine Sorgen: Manchmal ist es viel einfacher, etwas zu benutzen, um zu verstehen, was es ist, und dieses Buch wird dir helfen, Webanwendungen mit Express zu erstellen. Bevor wir jedoch mit Express beginnen, werden wir im nächsten Kapitel einen Rundgang durch Node machen, der wichtige Hintergrundinformationen liefert, um zu verstehen, wie Express funktioniert.

¹ Oft auch Just-in-Time-Kompilierung (JIT) genannt.