2 Tage vor
Pods und Services klingen ähnlich, gehören aber zu verschiedenen Welten. Der eine ist ein Arbeiter, der kommt und geht – der andere ist das Schild am Gebäude.
Verwechselt werden beide, weil sie im Alltag zusammen auftreten. Immer wenn eine Anwendung Pods startet, steht ein Service davor.
Ein Pod ist die kleinste Einheit in Kubernetes und enthält einen oder mehrere Container, die sich Netzwerk und Speicher teilen. Ein Deployment hält eine gewünschte Anzahl gleicher Pods am Laufen. Pods sind bewusst kurzlebig: Bei jedem Update, bei Knotenausfall oder Neustart ersetzt Kubernetes alte Pods durch neue – und jeder neue Pod erhält eine neue Cluster-IP. Ein Webshop-Deployment verwaltet etwa drei Pods, von denen jeder Neustart mit einer frischen IP startet.
Ein Service ist dagegen eine feste Adresse für diese wechselnde Gruppe. Er besitzt eine eigene IP-Adresse und einen DNS-Namen (DNS übersetzt Namen in IP-Adressen) innerhalb des Clusters, die sich nicht ändern, solange der Service existiert. Der Service wählt seine Pods über ein Label-Selektor-Kriterium aus: Alle Pods mit einem bestimmten Label gehören zur Gruppe. Der Service „frontend“ verteilt alle Aufrufe von „frontend“ immer auf einen der gerade laufenden Pods – egal, wer gerade neu gestartet wurde.
Der Pod liefert die Arbeit, der Service liefert die Erreichbarkeit. Pod-IPs bleiben hinter dem Service verborgen; fällt ein Pod aus, wandern seine Anfragen automatisch zu den verbleibenden.
Faustregel: Pods nie direkt adressieren, sondern immer über den Service – eine Pod-IP in einer Konfiguration ist nach dem nächsten Neustart unbrauchbar.
Der Service heißt nicht Lastverteiler für Container, sondern feste Anlaufstelle vor kurzlebigen Pods.
📌 Pod · Service · Label-Selektor
📚 Cloud von Grund auf · Tag 4 von 30
#kubernetes #CloudHosting #devops
Verwechselt werden beide, weil sie im Alltag zusammen auftreten. Immer wenn eine Anwendung Pods startet, steht ein Service davor.
Ein Pod ist die kleinste Einheit in Kubernetes und enthält einen oder mehrere Container, die sich Netzwerk und Speicher teilen. Ein Deployment hält eine gewünschte Anzahl gleicher Pods am Laufen. Pods sind bewusst kurzlebig: Bei jedem Update, bei Knotenausfall oder Neustart ersetzt Kubernetes alte Pods durch neue – und jeder neue Pod erhält eine neue Cluster-IP. Ein Webshop-Deployment verwaltet etwa drei Pods, von denen jeder Neustart mit einer frischen IP startet.
Ein Service ist dagegen eine feste Adresse für diese wechselnde Gruppe. Er besitzt eine eigene IP-Adresse und einen DNS-Namen (DNS übersetzt Namen in IP-Adressen) innerhalb des Clusters, die sich nicht ändern, solange der Service existiert. Der Service wählt seine Pods über ein Label-Selektor-Kriterium aus: Alle Pods mit einem bestimmten Label gehören zur Gruppe. Der Service „frontend“ verteilt alle Aufrufe von „frontend“ immer auf einen der gerade laufenden Pods – egal, wer gerade neu gestartet wurde.
Der Pod liefert die Arbeit, der Service liefert die Erreichbarkeit. Pod-IPs bleiben hinter dem Service verborgen; fällt ein Pod aus, wandern seine Anfragen automatisch zu den verbleibenden.
Faustregel: Pods nie direkt adressieren, sondern immer über den Service – eine Pod-IP in einer Konfiguration ist nach dem nächsten Neustart unbrauchbar.
Der Service heißt nicht Lastverteiler für Container, sondern feste Anlaufstelle vor kurzlebigen Pods.
📌 Pod · Service · Label-Selektor
📚 Cloud von Grund auf · Tag 4 von 30
#kubernetes #CloudHosting #devops
2 Tage vor
Viele Einsteiger halten JavaScript für eine Browsersprache. Dabei läuft dieselbe Sprache auch auf Servern und Build-Werkzeugen.
Die Annahme klingt plausibel: JavaScript entstand für Webseiten, und dort sieht man es auch. Wer Buttons, Formulare und Animationen kennt, verbindet die Sprache fest mit Browser und Frontend.
Tatsächlich ist der Browser nur eine Laufzeitumgebung – also das Programm, das die Sprache überhaupt ausführen kann. Es enthält die Sprach-Engine und Bibliotheken, über die der Code sein Betriebssystem erreicht. Die Sprache selbst definiert die ECMAScript-Norm, und jede Umgebung legt fest, was sie darf. Node.js ist eine solche Umgebung und führt JavaScript außerhalb des Browsers aus, etwa auf einem Server. Sie ergänzt die Sprache um Module für Dateizugriffe und um eines, das einen HTTP-Server startet, der Anfragen entgegennimmt und antwortet.
Der Irrtum entsteht, weil Einsteiger JavaScript fast ausschließlich im Frontend erleben. Dort laufen die Sprache und der Browser scheinbar immer gemeinsam auf.
Ein kleines Skript zeigt den Unterschied: Unter Node.js liest es eine Datei ein und zählt Wörter. Genau dieses JavaScript hat vorher vielleicht einen Button im Browser verarbeitet. Wird daraus ein Server, beantwortet er etwa die Anfrage GET /artikel/42 mit einem Datensatz im JSON-Format.
Woran man es erkennt: Läuft Code ohne geöffnetes Browserfenster, ist er nicht im Frontend, sondern im Backend unterwegs. Frontend und Backend sind keine Ordner, sondern Lauforte derselben Sprache.
JavaScript heißt nicht „die Browsersprache“, sondern eine Sprache mit wechselnden Lauforten. Wer Werkzeuge wie npm nutzt, fährt bereits Node.js, ohne es zu bemerken.
📌 Laufzeitumgebung · Node.js · Frontend und Backend als Lauforte
📚 Webentwicklung von Grund auf · Tag 4 von 30
#javascript #NodeJS #webdev
Die Annahme klingt plausibel: JavaScript entstand für Webseiten, und dort sieht man es auch. Wer Buttons, Formulare und Animationen kennt, verbindet die Sprache fest mit Browser und Frontend.
Tatsächlich ist der Browser nur eine Laufzeitumgebung – also das Programm, das die Sprache überhaupt ausführen kann. Es enthält die Sprach-Engine und Bibliotheken, über die der Code sein Betriebssystem erreicht. Die Sprache selbst definiert die ECMAScript-Norm, und jede Umgebung legt fest, was sie darf. Node.js ist eine solche Umgebung und führt JavaScript außerhalb des Browsers aus, etwa auf einem Server. Sie ergänzt die Sprache um Module für Dateizugriffe und um eines, das einen HTTP-Server startet, der Anfragen entgegennimmt und antwortet.
Der Irrtum entsteht, weil Einsteiger JavaScript fast ausschließlich im Frontend erleben. Dort laufen die Sprache und der Browser scheinbar immer gemeinsam auf.
Ein kleines Skript zeigt den Unterschied: Unter Node.js liest es eine Datei ein und zählt Wörter. Genau dieses JavaScript hat vorher vielleicht einen Button im Browser verarbeitet. Wird daraus ein Server, beantwortet er etwa die Anfrage GET /artikel/42 mit einem Datensatz im JSON-Format.
Woran man es erkennt: Läuft Code ohne geöffnetes Browserfenster, ist er nicht im Frontend, sondern im Backend unterwegs. Frontend und Backend sind keine Ordner, sondern Lauforte derselben Sprache.
JavaScript heißt nicht „die Browsersprache“, sondern eine Sprache mit wechselnden Lauforten. Wer Werkzeuge wie npm nutzt, fährt bereits Node.js, ohne es zu bemerken.
📌 Laufzeitumgebung · Node.js · Frontend und Backend als Lauforte
📚 Webentwicklung von Grund auf · Tag 4 von 30
#javascript #NodeJS #webdev
2 Tage vor
Die Antwort der API kommt zurück, aber das Frontend zeigt nichts an. Der Grund ist oft ein einziges falsches Komma im JSON.
Das Symptom: Der Browser meldet einen Fehler beim Auslesen der Daten. Die Anfrage selbst war erfolgreich; nur der Text der Antwort lässt sich nicht in ein Objekt umwandeln.
Dahinter steckt JSON, das JavaScript Object Notation, ein reines Textformat und der verbreitete Standard für Daten von Web-APIs. JSON kennt Objekte mit Schlüssel-Wert-Paaren, Listen, Zeichenketten, Zahlen sowie true, false und null. Der Browser fragt etwa per GET /artikel/42 einen Datensatz an, und der Server antwortet im Body, dem Teil der Antwort mit den eigentlichen Nutzdaten. Ein Header wie Content-Type: application/json kündigt dabei das Format an.
Ein typischer Fehler: einfache statt doppelter Anführungszeichen oder ein Komma nach dem letzten Paar. Beides macht das JSON ungültig, und der Empfänger verweigert das Lesen. Korrekt verschachtelt kombiniert eine Antwort beides: ein Objekt mit Metadaten wie der Gesamtzahl 2 sowie eine Liste in eckigen Klammern mit zwei Artikeln, den Nummern 42 und 43 und den Titeln „Neu“ und „Alt“ – Objekte und Listen lassen sich beliebig ineinander verschachteln.
So prüft man es: Die Antwort in einen JSON-Validator kopieren, der ungültige Stellen markiert. In JavaScript prüft JSON.parse den Text und meldet die Stelle, an der etwas fehlt; JSON.stringify wandelt ein Objekt wieder in Text um.
Wer null sieht, sollte zudem wissen: Das heißt, ein Wert fehlt bewusst – anders als die Zahl 0 oder eine leere Zeichenkette, bei denen ein Wert vorhanden ist.
JSON heißt nicht „irgendein Textformat“, sondern Objekte, Listen und Werte in exakter Schreibweise – doppelte Anführungszeichen, kein Schlusskomma.
📌 JSON-Objekt · Listen · null statt 0
📚 Webentwicklung von Grund auf · Tag 3 von 30
#webdev #api #javascript #frontend
Das Symptom: Der Browser meldet einen Fehler beim Auslesen der Daten. Die Anfrage selbst war erfolgreich; nur der Text der Antwort lässt sich nicht in ein Objekt umwandeln.
Dahinter steckt JSON, das JavaScript Object Notation, ein reines Textformat und der verbreitete Standard für Daten von Web-APIs. JSON kennt Objekte mit Schlüssel-Wert-Paaren, Listen, Zeichenketten, Zahlen sowie true, false und null. Der Browser fragt etwa per GET /artikel/42 einen Datensatz an, und der Server antwortet im Body, dem Teil der Antwort mit den eigentlichen Nutzdaten. Ein Header wie Content-Type: application/json kündigt dabei das Format an.
Ein typischer Fehler: einfache statt doppelter Anführungszeichen oder ein Komma nach dem letzten Paar. Beides macht das JSON ungültig, und der Empfänger verweigert das Lesen. Korrekt verschachtelt kombiniert eine Antwort beides: ein Objekt mit Metadaten wie der Gesamtzahl 2 sowie eine Liste in eckigen Klammern mit zwei Artikeln, den Nummern 42 und 43 und den Titeln „Neu“ und „Alt“ – Objekte und Listen lassen sich beliebig ineinander verschachteln.
So prüft man es: Die Antwort in einen JSON-Validator kopieren, der ungültige Stellen markiert. In JavaScript prüft JSON.parse den Text und meldet die Stelle, an der etwas fehlt; JSON.stringify wandelt ein Objekt wieder in Text um.
Wer null sieht, sollte zudem wissen: Das heißt, ein Wert fehlt bewusst – anders als die Zahl 0 oder eine leere Zeichenkette, bei denen ein Wert vorhanden ist.
JSON heißt nicht „irgendein Textformat“, sondern Objekte, Listen und Werte in exakter Schreibweise – doppelte Anführungszeichen, kein Schlusskomma.
📌 JSON-Objekt · Listen · null statt 0
📚 Webentwicklung von Grund auf · Tag 3 von 30
#webdev #api #javascript #frontend
3 Tage vor
JavaScript kann Bilder von fremden Servern laden, aber nicht deren pixelgenaue Daten auslesen. Dieser Unterschied ist die Same-Origin-Policy – und sie erklärt, warum fetch-Aufrufe scheitern können, obwohl die Anfrage beim Server ankam.
Der Browser vergleicht bei jeder Antwort, ob sie von derselben Origin (der Kombination aus Schema, Host und Port) stammt wie die Seite, deren JavaScript sie lesen will. Das begegnet Einsteigern sofort, sobald Frontend und Backend getrennt laufen.
Zuerst lädt der Browser die Seite, etwa eine gewöhnliche Dokumentseite unter https. JavaScript auf dieser Seite ruft dann Daten ab, zum Beispiel von einer API unter einem anderen Host. Die Anfrage geht ganz normal raus; der Server antwortet, ohne zu prüfen, wer sie liest.
Dann zählt der Browser Schema, Host und Port, nicht den Pfad: Zwei Adressen wie /seite1 und /api/daten auf demselben Host mit demselben Port teilen sich eine Origin. Aber ein API-Host und ein www-Host derselben Domain sind verschiedene Hosts, und derselbe Host mit abweichendem Port wie 8443 ist eine andere Origin. Ein fehlender Port bedeutet den Standardport, also 443 bei https.
Danach hält der Browser die Antwort zurück, wenn die Origins verschieden sind. Der Browser schickt die Anfrage, gibt die Antwort aber nicht an JavaScript weiter, solange der Server sie nicht per CORS (einem Header-Mechanismus zur Freigabe) erlaubt. Bilder und Stylesheets fremder Origins erscheinen trotzdem, weil kein Skript ihren Inhalt liest.
Zuletzt gilt die Grenze nur im Browser. curl (ein Kommandozeilenwerkzeug für HTTP-Anfragen) sendet und liest ohne Sandbox alles; die Same-Origin-Policy schützt den Server nicht, nur die Seite im Browser.
Gleiche Origin heißt also nicht gleicher Host, und fremde Origin heißt nicht blockierte Anfrage – sondern unlesbare Antwort.
📌 Origin · Same-Origin-Policy · CORS
📚 Webentwicklung von Grund auf · Tag 3 von 30
#WebSecurity #webdev #javascript
Der Browser vergleicht bei jeder Antwort, ob sie von derselben Origin (der Kombination aus Schema, Host und Port) stammt wie die Seite, deren JavaScript sie lesen will. Das begegnet Einsteigern sofort, sobald Frontend und Backend getrennt laufen.
Zuerst lädt der Browser die Seite, etwa eine gewöhnliche Dokumentseite unter https. JavaScript auf dieser Seite ruft dann Daten ab, zum Beispiel von einer API unter einem anderen Host. Die Anfrage geht ganz normal raus; der Server antwortet, ohne zu prüfen, wer sie liest.
Dann zählt der Browser Schema, Host und Port, nicht den Pfad: Zwei Adressen wie /seite1 und /api/daten auf demselben Host mit demselben Port teilen sich eine Origin. Aber ein API-Host und ein www-Host derselben Domain sind verschiedene Hosts, und derselbe Host mit abweichendem Port wie 8443 ist eine andere Origin. Ein fehlender Port bedeutet den Standardport, also 443 bei https.
Danach hält der Browser die Antwort zurück, wenn die Origins verschieden sind. Der Browser schickt die Anfrage, gibt die Antwort aber nicht an JavaScript weiter, solange der Server sie nicht per CORS (einem Header-Mechanismus zur Freigabe) erlaubt. Bilder und Stylesheets fremder Origins erscheinen trotzdem, weil kein Skript ihren Inhalt liest.
Zuletzt gilt die Grenze nur im Browser. curl (ein Kommandozeilenwerkzeug für HTTP-Anfragen) sendet und liest ohne Sandbox alles; die Same-Origin-Policy schützt den Server nicht, nur die Seite im Browser.
Gleiche Origin heißt also nicht gleicher Host, und fremde Origin heißt nicht blockierte Anfrage – sondern unlesbare Antwort.
📌 Origin · Same-Origin-Policy · CORS
📚 Webentwicklung von Grund auf · Tag 3 von 30
#WebSecurity #webdev #javascript
4 Tage vor
Die meisten Einsteiger denken, eine Webseite sei ein einziger Ort. Dabei läuft sie an zwei Orten: im Browser und auf dem Server.
Wer nicht weiß, welcher Baustein wo läuft, baut Prüfregeln an den falschen Ort. Und der falsche Ort ist der, den jeder Besucher verändern kann.
🌐 Frontend und Backend sind keine Ordner, sondern Lauforte. Das Frontend ist der Teil, der im Browser läuft: HTML beschreibt die Struktur, CSS das Aussehen, JavaScript das Verhalten auf der Seite. Das Backend läuft auf dem Server, speichert Daten und stellt Schnittstellen bereit. Dieselbe Sprache JavaScript kann an beiden Orten laufen: im Browser oder mit Node.js auf dem Server.
🧩 Der Browser spricht mit dem Backend über HTTP, das Anfrage-Antwort-Protokoll des Webs. Eine Schnittstelle (API) liefert etwa mit GET /artikel/42 einen Datensatz, oft als JSON, einem einfachen Textformat für Daten. Der Server kann dieselbe Adresse unterschiedlich beantworten: dem Browser eine HTML-Seite, einem Programm JSON-Daten. Er weiß dabei nie, was gerade angezeigt wird; jede Anfrage muss alles enthalten, was er zum Prüfen braucht.
🔒 Sensible Daten und alle Prüfregeln gehören immer ins Backend. Der JavaScript-Code im Browser ist sichtbar und veränderbar. Ein Kontaktformular prüft dort per JavaScript, ob das E-Mail-Feld ausgefüllt ist, und markiert den Fehler sofort. Das Backend prüft dieselbe Eingabe trotzdem erneut, weil die Frontend-Prüfung mit den Entwicklerwerkzeugen abgeschaltet sein kann.
Frontend heißt nicht „der sichere Teil der Anwendung“, sondern der Teil auf dem Gerät des Besuchers. Deshalb gilt: Ob eine Eingabe gilt, prüft der Server, nicht der Browser.
📌 Frontend · Backend · Serverprüfung
📚 Webentwicklung von Grund auf · Tag 2 von 30
#frontend #backend #webdev
Wer nicht weiß, welcher Baustein wo läuft, baut Prüfregeln an den falschen Ort. Und der falsche Ort ist der, den jeder Besucher verändern kann.
🌐 Frontend und Backend sind keine Ordner, sondern Lauforte. Das Frontend ist der Teil, der im Browser läuft: HTML beschreibt die Struktur, CSS das Aussehen, JavaScript das Verhalten auf der Seite. Das Backend läuft auf dem Server, speichert Daten und stellt Schnittstellen bereit. Dieselbe Sprache JavaScript kann an beiden Orten laufen: im Browser oder mit Node.js auf dem Server.
🧩 Der Browser spricht mit dem Backend über HTTP, das Anfrage-Antwort-Protokoll des Webs. Eine Schnittstelle (API) liefert etwa mit GET /artikel/42 einen Datensatz, oft als JSON, einem einfachen Textformat für Daten. Der Server kann dieselbe Adresse unterschiedlich beantworten: dem Browser eine HTML-Seite, einem Programm JSON-Daten. Er weiß dabei nie, was gerade angezeigt wird; jede Anfrage muss alles enthalten, was er zum Prüfen braucht.
🔒 Sensible Daten und alle Prüfregeln gehören immer ins Backend. Der JavaScript-Code im Browser ist sichtbar und veränderbar. Ein Kontaktformular prüft dort per JavaScript, ob das E-Mail-Feld ausgefüllt ist, und markiert den Fehler sofort. Das Backend prüft dieselbe Eingabe trotzdem erneut, weil die Frontend-Prüfung mit den Entwicklerwerkzeugen abgeschaltet sein kann.
Frontend heißt nicht „der sichere Teil der Anwendung“, sondern der Teil auf dem Gerät des Besuchers. Deshalb gilt: Ob eine Eingabe gilt, prüft der Server, nicht der Browser.
📌 Frontend · Backend · Serverprüfung
📚 Webentwicklung von Grund auf · Tag 2 von 30
#frontend #backend #webdev
4 Tage vor
Viele Einsteiger schreiben ihr Webseiten-Aussehen direkt in den HTML-Code. Dabei haben die drei Websprachen längst klare Aufgaben verteilt: Struktur, Aussehen, Verhalten.
Man begegnet ihnen bei jeder Seite im Browser. Wer die Trennung nicht kennt, ändert später jede Datei einzeln und sammelt Fehler, statt sie zu vermeiden.
Das Frontend, also der Teil einer Anwendung, der im Browser läuft, nutzt drei Sprachen mit getrennten Aufgaben. HTML beschreibt Struktur und Inhalt, CSS das Aussehen, JavaScript das Verhalten. HTML ist eine Auszeichnungssprache: Elemente wie Überschriften und Links teilen dem Browser mit, welche Bedeutung ein Textteil hat. CSS besteht aus Regeln mit Selektor, der bestimmt, welche Elemente gemeint sind, und Deklarationen wie color: red, die das Aussehen festlegen. JavaScript ist eine Programmiersprache und reagiert etwa auf Klicks, ohne die Seite neu zu laden.
Ein Beispiel: ein Button, in HTML mit dem button-Element ausgezeichnet, sagt dem Browser „hier steht etwas Klickbares“. Eine CSS-Regel färbt seine Schrift rot, etwa mit color: red. Ein Klick darauf löst JavaScript aus, das per Programmierung ein Dankeschön einblendet. Drei Dateien, drei Aufgaben, ein zusammenwirkendes Ergebnis.
Verwechselt wird die Trennung oft mit der zwischen Frontend und Backend. Das Backend läuft auf dem Server, speichert Daten und stellt Schnittstellen bereit. Hier geht es aber um die Rollen innerhalb einer einzigen HTML-Seite im Browser. Der typische Irrtum: Aussehen direkt in HTML-Attribute schreiben. Dann muss man bei einer Designänderung jede Seite einzeln anfassen; mit getrennter CSS-Datei genügt eine Änderung für alle.
HTML ist also nicht der Ort für Farben oder Logik, sondern nur für Bedeutung und Struktur. Wer die Aufgaben trennt, wartet eine Änderung an genau einer Stelle.
📌 HTML · CSS · JavaScript
📚 Webentwicklung von Grund auf · Tag 1 von 30
#webdev #frontend #javascript
Man begegnet ihnen bei jeder Seite im Browser. Wer die Trennung nicht kennt, ändert später jede Datei einzeln und sammelt Fehler, statt sie zu vermeiden.
Das Frontend, also der Teil einer Anwendung, der im Browser läuft, nutzt drei Sprachen mit getrennten Aufgaben. HTML beschreibt Struktur und Inhalt, CSS das Aussehen, JavaScript das Verhalten. HTML ist eine Auszeichnungssprache: Elemente wie Überschriften und Links teilen dem Browser mit, welche Bedeutung ein Textteil hat. CSS besteht aus Regeln mit Selektor, der bestimmt, welche Elemente gemeint sind, und Deklarationen wie color: red, die das Aussehen festlegen. JavaScript ist eine Programmiersprache und reagiert etwa auf Klicks, ohne die Seite neu zu laden.
Ein Beispiel: ein Button, in HTML mit dem button-Element ausgezeichnet, sagt dem Browser „hier steht etwas Klickbares“. Eine CSS-Regel färbt seine Schrift rot, etwa mit color: red. Ein Klick darauf löst JavaScript aus, das per Programmierung ein Dankeschön einblendet. Drei Dateien, drei Aufgaben, ein zusammenwirkendes Ergebnis.
Verwechselt wird die Trennung oft mit der zwischen Frontend und Backend. Das Backend läuft auf dem Server, speichert Daten und stellt Schnittstellen bereit. Hier geht es aber um die Rollen innerhalb einer einzigen HTML-Seite im Browser. Der typische Irrtum: Aussehen direkt in HTML-Attribute schreiben. Dann muss man bei einer Designänderung jede Seite einzeln anfassen; mit getrennter CSS-Datei genügt eine Änderung für alle.
HTML ist also nicht der Ort für Farben oder Logik, sondern nur für Bedeutung und Struktur. Wer die Aufgaben trennt, wartet eine Änderung an genau einer Stelle.
📌 HTML · CSS · JavaScript
📚 Webentwicklung von Grund auf · Tag 1 von 30
#webdev #frontend #javascript
