Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- modul:m290_guko:learningunits:lu15:theorie:a_backend_server [2025/12/07 21:27] – gkoch
+++ modul:m290_guko:learningunits:lu15:theorie:a_backend_server [2025/12/07 21:37] (aktuell) – gkoch
@@ Zeile 39: / Zeile 39: @@
 ===== Warum überhaupt ein Backend-Server? =====
-Bis jetzt haben Sie im Modul M290:
+Bis jetzt haben Sie im Modul M290 vor allem mit der Datenbank gearbeitet:
-  * direkt in **WebStorm** mit dem Datenbank-Plugin gearbeitet,
+  * Sie haben in **WebStorm** mit dem Datenbank-Plugin gearbeitet.
-  * SQL-Statements (inkl. CRUD) **direkt auf MySQL** ausgeführt.
+  * Sie haben **SQL-Befehle** (inkl. CRUD) direkt an die Datenbank ''MySQL'' geschickt.
+  * Das war ideal, um SQL zu üben und zu verstehen, wie Tabellen, JOINs und Aggregatfunktionen funktionieren.
-Das ist ideal zum Lernen von SQL – aber für eine echte Webapplikation **nicht geeignet**:
+Für eine **richtige Webapplikation**, die viele Benutzerinnen und Benutzer über das Internet nutzen, ist dieser direkte Zugriff jedoch **nicht sinnvoll** und auch **nicht sicher**.
-  * Ein Browser-Frontend sollte **nie direkt** mit der Datenbank kommunizieren.
+==== Was wäre, wenn der Browser direkt auf die Datenbank zugreifen würde? ====
-  * Die Datenbank soll **geschützt** im Hintergrund laufen.
-  * Zwischen Browser und Datenbank braucht es eine **Logik-Schicht** → Ihren **Backend-Server**.
+Stellen Sie sich vor:
+  * Ihr Browser würde direkt eine Verbindung zur Datenbank ''MySQL'' aufbauen.
+  * Jede Benutzerin / jeder Benutzer hätte direkten Zugriff auf Tabellen und könnte eigene SQL-Befehle schicken.
+Das führt zu mehreren Problemen:
+  * **Sicherheitsrisiko**: Alle, die die Verbindung kennen, könnten eigene SQL-Befehle ausführen – auch schädliche (z.B. Daten löschen).
+  * **Keine Kontrolle über die Logik**: Es gäbe keine zentrale Stelle, die prüft, ob eine Aktion erlaubt ist (z.B. darf ein:e Lernende:r wirklich Noten ändern?).
+  * **Schwierige Wartung**: Wenn sich die Struktur der Datenbank ändert, müssten alle Frontends (Webseiten, Apps, …) angepasst werden.
+  * **Technische Abhängigkeit**: Jedes Frontend müsste wissen, wie genau die Datenbank aufgebaut ist (Tabellennamen, Spaltennamen, Datentypen, …).
+==== Die Lösung: eine zusätzliche Logik-Schicht ====
+Statt den Browser direkt mit der Datenbank sprechen zu lassen, schalten wir eine **Zwischenschicht** dazwischen:
+den **Backend-Server**.
 <WRAP center round box 80%>
@@ Zeile 58: / Zeile 75: @@
 </WRAP>
-Vorteile des Backend-Servers:
+  * Der **Client** (z.B. Browser oder Postman) sendet **HTTP-Anfragen** (z.B. ''GET /api/books'').
+  * Der **Backend-Server**:
+    - nimmt die Anfrage entgegen,
+    - prüft die Daten,
+    - entscheidet, was erlaubt ist,
+    - führt die passenden **SQL-Befehle** auf der Datenbank aus,
+    - formatiert das Ergebnis (z.B. als JSON) und sendet es zurück.
+  * Die **Datenbank** kennt nur den Server und führt dessen SQL-Kommandos aus – aber kein Client greift direkt darauf zu.
+==== Vorteile des Backend-Servers im Detail ====
+**1. Sicherheit**
+  * Die Datenbank ist nicht direkt aus dem Internet erreichbar.
+  * Nur der Backend-Server hat Zugang zur Datenbank (z.B. über einen eigenen ''AppUser'' mit klar definierten Rechten).
+  * Der Server entscheidet:
+    - welche SQL-Befehle erlaubt sind,
+    - welche Daten angezeigt oder verändert werden dürfen.
-  * **Sicherheit**
+**2. Businesslogik & Validierung**
-    Die Datenbank ist nicht direkt aus dem Internet erreichbar. Der Server entscheidet, welche SQL-Befehle ausgeführt werden.
-  * **Businesslogik & Validierung**
-    Regeln (z.B. ''Note zwischen 1.0 und 6.0'', ''Geburtsdatum nicht in der Zukunft'') werden im Backend implementiert, nicht im Browser.
-  * **Mehrere Frontends möglich**
-    Dieselbe API kann von einer Website, einer Mobile-App oder einem anderen Service genutzt werden.
-  * **Wartbarkeit**
-    Datenbank, Backend-Logik und Frontend können unabhängig voneinander angepasst werden.
+  * Fachliche Regeln werden im Backend umgesetzt, z.B.:
+    - ''Note muss zwischen 1.0 und 6.0 liegen'',
+    - ''Geburtsdatum darf nicht in der Zukunft liegen'',
+    - ''Eine Bewertung darf nur 1–5 Sterne haben''.
+  * Der Browser darf nicht über eigene SQL-Befehle mit der Datenbank kommunizieren, sondern ruft nur definierte **API-Endpunkte** auf
+    (z.B. ''POST /api/trips'' oder ''GET /api/books'').
+  * So ist klar geregelt, was das System darf und was nicht.
-===== Kein Website-Frontend, sondern ein Backend-Server =====
+**3. Einheitliche Schnittstelle (API)**
-Wichtig für diese Learning Unit:
+  * Der Backend-Server stellt eine **API** bereit (z.B. ''/api/trips'', ''/api/songs'').
+  * Diese API kann von verschiedenen Clients genutzt werden:
+    - einer Webseite,
+    - einer Mobile-App,
+    - Tools wie Postman.
+  * Die Datenbank-Struktur kann sich im Hintergrund ändern – die API kann stabil bleiben.
-  * Sie programmieren **keine klassische Website** mit HTML/CSS/JavaScript im Browser.
+**4. Bessere Wartbarkeit & Erweiterbarkeit**
-  * Sie programmieren einen **Server**, der über HTTP angesprochen wird.
-  * Der Browser dient hier nur als **Client**, der eine Anfrage schickt und die Antwort (Text oder JSON) anzeigt.
-In den nächsten Seiten erstellen Sie:
+  * Änderungen an der Datenbank (z.B. neue Tabelle, anderes Feld) werden zuerst im Backend angepasst.
+  * Frontends müssen nur die API kennen, nicht die Details der Datenbank.
+  * Neue Funktionen (z.B. zusätzlicher Filter, neue Berechnung) können im Backend ergänzt werden,
+    ohne dass direkt SQL im Frontend geändert werden muss.
-  * ein neues Node.js/Express-Projekt,
+In dieser Phase des Moduls gehen wir den nächsten Schritt:
-  * Ihren ersten kleinen Backend-Server,
-  * und verstehen den Unterschied zwischen **Website** und **API**.
+  * Wir schreiben **keine SQL-Befehle, wie ''SELECT''/''UPDATE''/''DELETE''/''CREATE'' mehr direkt in WebStorm an die Datenbank**,
+  * sondern wir bauen einen **Backend-Server mit Node.js/Express**, der für uns mit der Datenbank spricht. (Andere SQL-Befehle, wie das Erstellen von Tabellen und Datenbanken werden wir weiterhin direkt mit Webstorm/Datenbank-Plugin machen).
+  * Im Unterricht verwenden wir dazu zunächst den Browser und **Postman** als Client, später könnten auch echte Frontends (Web oder Mobile) diese API nutzen.