M295 Theorie¶

Autor

Lars Hellstern 21. März 2026 2. Version

1. Client-Server Architektur mit JSON¶

Die Theorie: Es handelt sich um ein System der strengen Arbeitsteilung. Der Client (in unserem Fall der Browser mit dem Frontend) fragt Informationen an. Der Server (unser Node.js Backend) verarbeitet die Logik, holt Daten aus der Datenbank und schickt sie zurück.
Warum JSON? JSON (JavaScript Object Notation) ist der weltweite Standard für diesen Austausch. Es ist reiner Text, extrem leichtgewichtig und kann systemübergreifend von jeder Programmiersprache (egal ob C++, Java oder JS) verstanden werden.

Synchron: Blockiert den Ablauf. Ein Befehl muss zu 100% fertig sein, bevor der nächste startet (z. B. mathematische Berechnungen).
Asynchron: Wenn das Backend Daten von der MongoDB-Datenbank anfragt (was übers Internet geht und lange dauert), blockiert es nicht. Elementare Regel: > "Ich warte hier im Hintergrund auf die Antwort, arbeite aber in der Zwischenzeit schon mal die Anfragen anderer User ab."
Prüfungs-Hitze: "Weil Node.js nur einen 'Single Thread' hat, würde synchroner Code bei einer Datenbankabfrage den kompletten Webserver für alle anderen Benutzer einfrieren. Erst durch die Asynchronität (mit async / await) wird unser Server schnell und kann viele User gleichzeitig bedienen."

Die Theorie: Ein Router im Backend funktioniert wie eine Empfangsdame. Er schaut sich an, über welchen Pfad (z.B. /api/vehicles) und mit welcher Methode ein Datenpaket ankommt, und schickt es an die zuständige Fachabteilung (den Controller).
Die 4 wichtigsten HTTP Methoden:
- GET: Fordert Daten an (Read).
- POST: Erstellt neue Daten. Sendet oft sensible Daten versteckt im "Body" mit (Create).
- PUT / PATCH: Überschreibt oder ändert bestehende Daten (Update).
- DELETE: Löscht Daten auf dem Server (Delete).

Die Theorie: Das standardisierte Ampelsystem des Internets. Das Backend schickt bei jedem Request eine dreistellige Nummer an das Frontend, damit dieses sofort weiß, was zu tun ist, ohne lange Fehlertexte zu analysieren.
Kategorien:
- 2xx (Erfolg): z. B. 200 OK (Abfrage erfolgreich) oder 201 Created (Auto gespeichert).
- 4xx (Client-Fehler): Der User hat einen Fehler gemacht. z. B. 401 Unauthorized (Falsches Passwort), 404 Not Found (URL existiert nicht).
- 5xx (Server-Fehler): z. B. 500 Internal Server Error (Die Backend-Programmierung ist abgestürzt).

Die Theorie: Eine klassische Template Engine (wie z. B. EJS oder Pug) nimmt ein serverseitiges HTML-Gerüst und füllt es dynamisch mit Variablendaten aus der Datenbank, bevor die fertige HTML-Seite an den Client geschickt wird.
Im LuxFleet Projekt: Wir haben das moderner gelöst. Wir generieren das HTML nicht im Backend. Wir nutzen JavaScript Template Literals (Backticks `) direkt im Frontend. Das Frontend holt sich die JSON-Variablen über die API und baut das HTML (z.B. mit Platzhaltern wie ${kpis.total}) selbstständig im Browser zusammen.

Die Theorie: APIs haben keine grafischen Buttons, auf die man testweise klicken kann. Man muss sie mit Tools auf Herz und Nieren prüfen.
- Postman: Ein grafisches Programm für Entwickler. Man gibt manuell eine Route (z.B. GET /api/vehicles) ein und sieht auf Knopfdruck, welches JSON zurückkommt.
- Supertest & Jest: "Postman für Programmiercode". Man schreibt ein Skript, das die HTTP-Aufrufe total automatisch simuliert. Das System prüft in Sekundenbruchteilen dutzende Routen und schlägt Alarm, wenn z. B. nicht wie erwartet der Status 200 zurückkommt.

Die Theorie: Programmierer müssen das Rad nicht täglich neu erfinden. NPM (Node Package Manager) ist eine riesige Bibliothek mit Millionen gratis Code-Paketen von anderen Entwicklern.
Wie es funktioniert: Man lädt externe Module per Konsole (npm install name) in den Ordner node_modules herunter. Im Code bindet man sie mit require('name') ein und kann direkt ihre Funktionen nutzen. (Beispiele in LuxFleet: Express für den Server, bcrypt fürs Hashing).

Klassische Backend-Applikation: (wie z.B. WordPress) Vermischt das Backend mit dem Frontend-Design. Wenn man eine URL aufruft, generiert der Server im Hintergrund eine riesige, fertig gestaltete HTML-Datei inkl. CSS und schickt sie an den Browser.
Eine Headless API: Das ist der LuxFleet Ansatz! Die "Application Programming Interface" ist eine pure Datenschnittstelle. Sie empfängt JSON und schickt ausschließlich pure Rohdaten (JSON) zurück. Sie sendet kein einziges Gramm HTML-Design. Dadurch könnte an unser Backend in Zukunft problemlos auch eine direkte iPhone- oder Android-App angebunden werden!

Die Theorie: Ein Handler (oft 'Controller' genannt) ist die entscheidende JavaScript-Funktion, die ausgeführt wird, nachdem das Routing den Request weitergeleitet hat.
CRUD steht für die 4 elementaren Operationen jeder Datenbank:
- Create: Speichere das ankommende Auto ins Datenbanksystem (über HTTP POST).
- Read: Finde alle Autos und sende sie als JSON zurück (über HTTP GET).
- Update: Suche ein spezielles Auto anhand der ID und ändere seine Parameter (über HTTP PUT).
- Delete: Lösche den Datensatz restlos aus dem System (über HTTP DELETE).

Die Theorie: Im Gegensatz zu klassischen SQL-Datenbanken, in denen Daten in unglaublich starren Excel-artigen "Tabellen" mit festen Relationen gespeichert werden, arbeiten NoSQL-Datenbanken (Not Only SQL) wie MongoDB "schemalos" und extrem flexibel.
Verknüpfung mit Node.js: "In einer NoSQL-Datenbank werden Daten als BSON/JSON-artige Dokumente gespeichert. Das passt 1:1 perfekt zu JavaScript und Node.js, da wir nicht mehr ständig mühsam zwischen SQL-Tabellenzeilen und unseren JavaScript-Objekten hin und her konvertieren müssen. Wir schicken unser JavaScript-Objekt einfach an MongoDB – und es wird nativ genauso abgespeichert!"