Wir haben in den vorangegenangenen Folien gesehen, wie man einen einfachen Web-Server in NodeJS erstellt.
+Moderne Features wie Routing-Logik, Logging, Error-Handling und weitere Features waren nicht mit inbegriffen.
+Wir wollen das auch nicht selber schreiben. Hierfür wurde das Rad unzählige male für verschiedenste Problemstellungen neu Entwickelt.
+Eines dieser vielen Räder schauen wir uns genauer an: Fastify
+Fastify ist ein modernes Web-Framework um seinen eigenen Web-Server zu bauen. Es bietet die vorher erwähnten Features und hat darüber hinaus noch mehr zu bieten.
+Das wichtigste aus meiner Sicht: Eine solide TypeScript Unterstützung.
+Wir beginnen nun damit, einen (bzw. mehrere) Server mit JavaScript auf NodeJS zu implementieren.
+NodeJS ist im Vergleich zur Umgebung im Browser anders aufgebaut. Wir haben zum Beispiel kein document auf das wir beispielsweise zugreifen könnten.
Dafür haben wir nun Zugriff auf die gesamte NodeJS-API um mit dem Betriebssystem zu interagieren (Dateizugriffe, Netzwerk-Ports öffnen und so weiter).
+Wenn Node installiert ist, können wir eine JavaScript Datei mit node name-der-datei.js ausführen.
Legen wir nun eine erste Datei server.js an:
+ const http = require("node:http");
+
+ http.createServer(function(req, res) {
+ res.end();
+ }).listen(8080);
+
+ console.log("Server listening on port 8080!");
+ Funktionalitäten in NodeJS sind in Modulen geschrieben. Wir können auf diese jederzeit zugreifen.
+Je nachdem wie das Projekt aufgebaut ist, müssen wir auf diese Module anders zugreifen.
+In nicht näher konfigurierten Projekten müssen wir mittels require("modulname") auf diese Sachen zurgeifen.
In moderneren Projekten, benutzen wir die neuere Modul-Syntax die mittels den keywords import something from 'modul'; aufgerufen wird.
Das aktuelle Setup macht nicht viel... Senden wir mal etwas an den Sender zurück!
+Wir nutzen res.write() um Inhalte zum Client zurück zu senden
+ http.createServer(function(req, res) {
+ res.write("Hallo vom Server!");
+ res.end();
+ }).listen(8080);
+ Wenn der Server startet, wird bei jedem Request zum Server die Callback-Funktion ausgeführt.
+Diese Funktion erhält zum einen ein Request-Objekt und zum zweiten ein Response-Objekt.
+Mit dem Request-Objekt können wir alle Informationen aus der vom Client gesendeten Anfrage extrahieren. Das Objekt ist (ähnlich zum Reponse-Objekt) recht komplex gestaltet.
+Im Request finden wir die URL (den Pfad) über den wir die Anfrage erhalten haben, ggf. den Body, welche Methode, und mehr.
+Das Response-Objekt beinhaltet Funktionalität um Daten zurück zu senden. Wichtig ist dabei zu wissen das wir mit einem NodeJS-Stream Objekt interagieren.
+Streams sind Lesbar, Schreibbar oder beides. Sie dienen dazu mit verschiedenen Dingen zu interagieren (wie zum Beispiel Netzwerk-Streams, Interkation mit Dateien und mehr).
+Für uns wichtig ist erstmal der Umstand, das wir in das response-Objekt mittels .write() Daten in den Stream hinein schreiben können, und dass wir mit .end() den Stream schließen können (und damit ultimativ den Request "beenden" oder schließen).
Geben wir ein paar Infos zum testen zurück.
+
+ http.createServer(function(req, res) {
+ res.write("Hallo vom Server!<br />");
+ res.write(`Request unter dem Pfad ${req.url} aufgerufen.
+ Verwendete Methode: ${req.method}`);
+ res.end();
+ }).listen(8080);
+ Nun erhalten wir ein paar Informationen im Browser (Pfad + Methode). Aber offensichtlich denkt der Browser nicht, dass wir hier mit HTML arbeiten..
+Wir arbeiten auch nicht wirklich mit HTML, aber wir können dem Browser mitteilen, dass das was wir versenden HTML ist und vom Browser entsprechend interpretiert werden soll.
+
+ http.createServer(function(req, res) {
+ res.writeHead(200, { 'Content-Type': 'text/html' });
+ res.write("Hallo vom Server!<br />");
+ res.write(`Request unter dem Pfad ${req.url} aufgerufen.
+ Verwendete Methode: ${req.method}`);
+ res.end();
+ }).listen(8080);
+ Damit sollte der Browser die Empfangenen Daten als HTML erkennen und sein möglichstes Versuchen um dieses korrekt zu rendern (also ohne, dass wir extra den Kompletten Rahmen mitsenden müssten.)
+Wenn wir nun mehr daraus machen wollen, müssten wir ein paar Dinge implementieren:
+Aber bevor wir uns damit auseinander setzen, verwenden wir lieber bereits existierende Frameworks die uns all diesen Aufwand ersparen.
+Bevor wir aber dazu kommen, sehen wir uns die darunter liegenden Protokolle an, die wir hier verwenden.
+Wir betrachten nun in den Nachfolgenden Slides was passiert wenn wir eine URL im Browser angeben bis zu dem Zeitpunkt an dem wir alle Daten empfangen haben.
+Wenn wir eine URL wie "google.de" haben, weiß unser PC nicht, wohin der Request gesendet werden muss. Dazu benötigt der PC die IP-Adresse des Ziels.
+IP-Adressen sind heutzutage entweder in der Version 4 oder Version 6 vorhanden. Version 6 wurde primär dazu erfunden, weil es keine Verfügbaren IPv4 Adressen mehr gab.
+Um einen Namen wie "google.de" in eine für den Computer / das Netzwerk interpretierbare Adresse umzuwandeln, frägt der Computer bei einem DNS-Server nach.
+Der Namens-Server gibt uns eine IP-Adresse zu der dann der Request gesendet werden kann.
+Die Info, unter welcher IP der Namensserver zu finden ist, erhalten wir durch unseren Internet-Service-Provider (Über den Router des Providers).
+Es gibt ein paar Schritte die bei einem DNS-Lookup geschehen:
+Die IP vom DNS-Server die wir "haben", ist die eines "DNS Recursive Resolvers". Dieser ist der "Einstiegspunkt" in der Suche eines Namenseintrages.
+DNS-Server bestehen nicht nur aus einzelnen Servern sondern sind einer Verkettung von mehreren Namens-Servern die jeweils einen kleineren Teil des Namens-Raums kennen.
+Der DNS-Root-Server ist die erste Übersetzungs-Ebene im DNS-System.
+Der Root-Server kennt dabei den "nächsten" Ansprechpartner (Server), der die Adresse kennt.
+Im Normalfall ist dies ein Top-Level-DNS-Server
+Der Recursive Resolver frägt nun beim TLD-DNS-Server nach der IP des gesuchten Ziels.
+Überlicherweise erhält der Resolver die IP des Authorative Nameserver.
+Der Authorative Nameserver hat die Einträge der gesuchten Domains (Name zu IP-Mapping)
+Der Recursive Resolver kann uns nun mit der gesuchten IP Antworten.
+Jeder Gängige Web-Request wird über das HTTP-Protokol versendet.
+Über die Jahre hat sich das HTTP-1 Protokol entwickelt (HTTP2 und HTTP3). Der Inhalt eines jeden Requests ist aber zunächst gleich/ähnlich.
+Ein HTTP-Request besteht aus mehreren Informationen:
+Die HTTP-Methode definiert die Aktion die wir auf einer URL (auch genannt Resource) ausführen wollen.
+Der Browser sendet im ohne Information "by default" ein GET bei allen Requests
+Es gibt noch weitere Methoden wie OPTIONS, aber diese werden seltener direkt in der Webentwicklung genutzt.
+Header im HTTP-Request enthalten zusätzliche Informationen als Key-Value-Paare.
+Header können entweder durch Code gesetzt werden (also durch den Entwickler) als auch durch den User-Agent (Web-Browser)
+Beispielhafte Inhalte
+Im Body eines Requests stehen die zu übertragenden Informationen der jeweiligen Seite.
+Der Body kann bei GET-Requests von der Sendenden Partei nicht gesetzt werden.
+Im Body befindet sich bei einer Anfrage mittels Post zum Beispiel die Information für die zu anlegende Resource.
+Sobald / Während der Bearbeitung kann der Server in einer Response einen StatusCode festlegen, die dem Client mitteilen soll, wie der Status zur Bearbeitung der Anfrage ist.
+Diese Responses sind eine Zahl im Bereich zwischen 100 und 599. Wobei jede "100-er" Kategorie einen anderen Allgemeinen Zustand definiert:
+Eine Ausführliche Erklärung (mit Katzen) ist hier zu finden
+