FastAPI ist ein modernes, schnelles (High-Performance) Web-Framework für Python, das speziell für die Entwicklung von APIs entwickelt wurde. Es basiert auf Python 3.6+, Starlette (für Web-Handling) und Pydantic (für Datenvalidierung und -serialisierung).

Merkmale von FastAPI:

✅ Schnell – FastAPI ist eine der schnellsten verfügbaren Python-Frameworks, vergleichbar mit NodeJS oder Go (dank uvicorn und Starlette).

✅ Automatische Dokumentation – Es generiert automatisch interaktive API-Dokumentationen über Swagger UI und ReDoc.

✅ Typsicherheit – Durch Typannotationen erkennt FastAPI automatisch Eingaben, prüft sie und erstellt automatisch Dokumentation.

✅ Asynchron / Async Support – Native Unterstützung für async/await für hohe Performance bei I/O-lastigen Anwendungen (z. B. Datenbankanfragen).

✅ Einfache Nutzung – FastAPI ist einfach zu lernen, besonders wenn man bereits Erfahrung mit Python und Typannotationen hat.

Einfaches Beispiel:

from fastapi import FastAPI

app = FastAPI()

@app.get("/")
def read_root():
    return {"message": "Hallo Welt"}

Wenn du das startest (z. B. mit uvicorn main:app --reload), läuft ein Webserver und unter http://localhost:8000/docs findest du direkt eine interaktive API-Doku.

Anwendungsbereiche:

• RESTful APIs

• Backend für Web- oder Mobile-Apps

• Microservices

• Datenverarbeitung und Machine Learning APIs

OpenID Connect (OIDC) ist ein Authentifizierungsprotokoll, das auf OAuth 2.0 basiert. Es ermöglicht es Clients (z. B. Web-Apps, Mobile-Apps), die Identität eines Benutzers sicher zu verifizieren, der sich bei einem externen Identitätsanbieter (IdP) anmeldet — zum Beispiel Google, Microsoft, Apple, etc.

🔐 Kurz gesagt:

OAuth 2.0 → regelt die Autorisierung (Zugriff auf Ressourcen)
OpenID Connect → regelt die Authentifizierung (Wer ist der Benutzer?)

🧱 Wie funktioniert OpenID Connect?

1. Benutzer klickt auf "Login mit Google"

2. Deine App leitet den Benutzer zum Google-Login weiter

3. Nach erfolgreichem Login leitet Google den Benutzer mit einem ID Token zurück

4. Deine App validiert dieses JWT-Token

5. Du weißt nun, wer der Benutzer ist – verifiziert von Google

🔑 Was enthält ein ID Token?

Das ID Token ist ein JSON Web Token (JWT) mit Informationen über den Benutzer, z. B.:

{
  "iss": "https://accounts.google.com",
  "sub": "1234567890",
  "name": "John Doe",
  "email": "john@example.com",
  "iat": 1650000000,
  "exp": 1650003600
}

• iss = Issuer (z. B. Google)

• sub = Benutzer-ID

• email, name = Benutzerinformationen

• iat, exp = Zeitstempel

🧩 Typische Anwendungsfälle

• "Login mit Google/Microsoft/Apple"

• Single Sign-On (SSO) in Unternehmen

• Zentrale Identitätsverwaltung (Keycloak, Auth0, Azure AD)

• OAuth-basierte APIs mit Identitätsprüfung

🛠️ Komponenten bei OpenID Connect

OPcache ist eine in PHP integrierte Bytecode-Caching-Erweiterung, die die Leistung von PHP-Anwendungen deutlich verbessert, indem sie den PHP-Code vorkompiliert und im Arbeitsspeicher (RAM) speichert.

⚙️ Wie funktioniert OPcache?

Normalerweise passiert bei jedem PHP-Aufruf:

1. PHP liest den Quellcode (*.php-Datei)

2. Der Code wird geparst und in Bytecode umgewandelt

3. Der Bytecode wird vom PHP-Interpreter ausgeführt

Mit OPcache passiert dieser Vorgang nur einmal. Danach wird der bereits kompilierte Bytecode aus dem Speicher genommen und direkt ausgeführt.

🚀 Vorteile von OPcache

php -i | grep opcache.enable

Oder im Code:

phpinfo();

📦 Typische Konfiguration (php.ini)

opcache.enable=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.validate_timestamps=1
opcache.revalidate_freq=2

💡 In Produktionsumgebungen wird oft opcache.validate_timestamps=0 gesetzt – das bedeutet: PHP prüft nicht mehr bei jedem Request, ob sich Dateien geändert haben → noch mehr Performance, aber Änderungen erfordern dann z. B. einen Cache-Reset oder Neustart.

🧪 Wann bringt OPcache etwas?

OPcache bringt besonders viel bei:

• Laravel, Symfony, WordPress, Drupal, TYPO3

• vielen Requests pro Sekunde

• größeren Codebasen

🧼 Cache löschen (z. B. nach Code-Updates)

Du kannst OPcache z. B. in einem Deployment-Tool mit folgendem Befehl leeren:

opcache_reset();

Oder über die Kommandozeile:

php -r "opcache_reset();"

🧠 Fazit

OPcache ist ein einfacher, aber extrem effektiver Performance-Booster für jede PHP-Anwendung. Er sollte in jeder produktiven Umgebung aktiviert sein – es ist kostenlos, nativ in PHP enthalten und reduziert Ladezeiten sowie Serverlast drastisch.

Deployer ist ein Open-Source-Deployment-Tool für PHP-Projekte – speziell entwickelt, um Anwendungen wie Laravel, Symfony, Magento, WordPress oder auch generische PHP-Apps automatisiert, wiederholbar und sicher auf Server zu bringen.

🚀 Was macht Deployer besonders?

• Es ist ein CLI-Tool, geschrieben in PHP.

• Du definierst dein Deployment in einer deploy.php-Datei mit klaren Aufgaben (Tasks).

• Es setzt auf das Prinzip Zero Downtime Deployment, z. B. durch Symlinks.

• Unterstützt mehrstufige Umgebungen (z. B. staging, production).

🛠️ Typischer Workflow mit Deployer

Du installierst Deployer über Composer:

composer require deployer/deployer --dev

Du generierst ein Template:

vendor/bin/dep init

Du konfigurierst deploy.php, z. B. für Laravel:

host('mein-server.com')
    ->set('deploy_path', '/var/www/meinprojekt')
    ->set('branch', 'main');

task('deploy', [
    'deploy:prepare',
    'deploy:vendors',
    'artisan:migrate',
    'deploy:publish',
]);

Du startest das Deployment:

vendor/bin/dep deploy production

🔁 Was passiert im Hintergrund?

Deployer:

• Verbindet sich via SSH mit dem Zielserver

• Klont das Git-Repository in ein neues Release-Verzeichnis

• Installiert Composer-Abhängigkeiten

• Führt Tasks aus (z. B. php artisan migrate)

• Verlinkt das neue Release mit dem Live-Verzeichnis (current)

• Löscht alte Releases nach Bedarf

📦 Vorteile von Deployer

Laravel Octane ist eine offizielle Erweiterung für das Laravel-Framework, die die Performance deiner Anwendung dramatisch verbessert, indem sie Laravel auf Hochleistungsservern wie Swoole oder RoadRunner ausführt.

⚡ Was macht Laravel Octane besonders?

Statt bei jeder HTTP-Anfrage den Laravel-Framework-Code neu zu laden (wie bei PHP-FPM üblich), hält Octane deine Anwendung permanent im Speicher. Das spart Bootstrapping-Zeit und macht deine App viel schneller.

🔧 Wie funktioniert das technisch?

Laravel Octane nutzt Worker-basierte Server (z. B. Swoole oder RoadRunner), die:

1. Die Laravel-Anwendung einmalig booten,

2. Dann Anfragen wiederholt und schnell verarbeiten, ohne das Framework neu zu starten.

🚀 Vorteile von Laravel Octane

RoadRunner ist ein High-Performance Application Server für PHP, der von Spiral Scout entwickelt wurde. Er ersetzt den klassischen PHP-FPM (FastCGI Process Manager) und bietet durch eine dauerhafte Ausführung deiner PHP-Anwendung einen massiven Performance-Schub – besonders bei Frameworks wie Laravel oder Symfony.

🚀 Was macht RoadRunner besonders?

✅ Performance durch Worker

• PHP-Skripte werden nicht bei jeder Anfrage neu geladen, sondern laufen dauerhaft in sogenannten Worker-Prozessen (ähnlich wie bei Node.js oder Swoole).

• Dadurch sparst du dir das erneute Bootstrapping deiner App bei jedem Request – das ist wesentlich schneller als bei PHP-FPM.

✅ In Go geschrieben

• RoadRunner selbst ist in der Programmiersprache Go geschrieben – das bedeutet hohe Stabilität, einfache Cross-Plattform-Deployments und parallele Verarbeitung von Anfragen.

✅ Features

• HTTP-Server (inkl. HTTPS, Gzip, CORS, etc.)

• PSR-7 & PSR-15 Middleware-Kompatibilität

• Unterstützung für:

  • Queues (z. B. mit RabbitMQ, Redis, etc.)

  • gRPC

  • WebSockets

  • Static file serving

  • Metrics (Prometheus)

  • RPC zwischen PHP und Go

• Hot Reload für Änderungen im Code (mit Watch-Modul)

⚙️ Wie funktioniert RoadRunner technisch?

1. RoadRunner startet PHP-Worker-Prozesse.

2. Die Worker laden einmal den gesamten Framework-Bootstrap.

3. RoadRunner verteilt HTTP- oder gRPC-Anfragen an die Worker.

4. Die Antwort wird über Go zurückgegeben – schnell und parallel.

📦 Typischer Einsatz:

• Laravel + RoadRunner (statt Laravel + PHP-FPM)

• Anwendungen mit hoher Request-Frequenz

• APIs, Microservices, Echtzeit-Anwendungen (z. B. mit WebSockets)

• Serverless-ähnliche Dienste, wo Latenz kritisch ist

📉 Vergleich zu PHP-FPM

Die .htaccess-Datei ist eine Konfigurationsdatei für Apache-Webserver, mit der du das Verhalten deiner Website direkt beeinflussen kannst – ohne Zugriff auf die zentrale Serverkonfiguration. Sie befindet sich typischerweise im Root-Verzeichnis deiner Website (z. B. /public_html oder /www).

Wichtige Hinweise:

• Die .htaccess wirkt nur auf Apache-Servern (nicht bei nginx).

• Änderungen gelten sofort, du brauchst den Server nicht neu zu starten.

• Viele Shared-Hosting-Anbieter erlauben .htaccess, aber nicht alle Befehle sind immer erlaubt.

• Fehlerhafte Einträge können deine Seite unbrauchbar machen – also Vorsicht beim Bearbeiten.

GitHub Actions ist ein Feature von GitHub, mit dem du automatisierte Workflows für deine Softwareprojekte erstellen kannst – direkt im GitHub-Repository.

🛠️ Was kann man mit GitHub Actions machen?

Du kannst CI/CD-Pipelines (Continuous Integration / Continuous Deployment) aufbauen, z. B.:

• ✅ Code automatisch testen (z. B. mit PHPUnit, Jest, Pytest)

• 🛠️ Code bei jedem Push oder Pull Request builden

• 🚀 Software automatisch deployen (z. B. auf einen Webserver, in die Cloud, zu DockerHub)

• 📦 Releases erstellen (z. B. ZIP-Dateien, Versionstags)

• 🔄 Cronjobs oder geplante Tasks laufen lassen

🧱 Wie funktioniert es?

GitHub Actions basiert auf sogenannten Workflows, die du in einer Datei definierst:

• Die Datei heißt z. B. .github/workflows/ci.yml

• Sie ist im YAML-Format

• Du definierst Events (z. B. push, pull_request) und Jobs (z. B. build, test)

• Jobs bestehen aus Steps, die Befehle oder Aktionen ausführen

Beispiel: Einfacher CI-Workflow für Node.js

name: CI

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '20'
      - run: npm install
      - run: npm test

🧩 Was sind "Actions"?

Eine Action ist ein einzelner Schritt, den man in einem Workflow ausführt. Es gibt:

• Vorgefertigte Actions (z. B. actions/checkout, setup-node, upload-artifact)

• Eigene Actions (z. B. Shell-Skripte oder Docker-Container)

Du kannst Actions im GitHub Marketplace finden und nutzen.

💡 Warum ist das nützlich?

• Spart manuelle Arbeit

• Verbessert Codequalität (durch automatisierte Tests)

• Macht Deployments reproduzierbar

• Alles direkt in GitHub – kein externer CI-Dienst nötig (wie Jenkins oder Travis CI)

Docker Compose ist ein Werkzeug, mit dem du mehrere Docker-Container als einen einzigen Service definieren und starten kannst. Statt jeden Container einzeln über die Docker-CLI zu starten, kannst du mit Docker Compose eine docker-compose.yml-Datei schreiben, in der du alle benötigten Dienste (z. B. Datenbank, Webserver, App-Container) deklarierst.

Kurz gesagt:

Docker Compose = Projektbeschreibung + Mehrere Container + Ein Befehl zum Starten

Beispiel: docker-compose.yml

version: '3.9'
services:
  web:
    build: .
    ports:
      - "5000:5000"
    volumes:
      - .:/code
  redis:
    image: "redis:alpine"

In diesem Beispiel:

• Ein Container baut die lokale Webanwendung.

• Ein zweiter Container nutzt das offizielle Redis-Image.

• Beide Container sind miteinander vernetzt.

Häufige Kommandos:

docker-compose up       # Startet alle Container im Vordergrund
docker-compose up -d    # Startet im Hintergrund (detached)
docker-compose down     # Stoppt und entfernt Container, Netzwerke etc.

Vorteile von Docker Compose:

✅ Einfaches Setup für Multi-Container-Anwendungen
✅ Alles wird in einer Datei versioniert (z. B. für Git)
✅ Reproduzierbare Entwicklungsumgebungen
✅ Leichtes Hoch- und Runterfahren ganzer Stacks

Typische Anwendungsfälle:

• Lokale Entwicklung mit mehreren Services (z. B. App + DB)

• Integrationstests mit vollständigem Stack

• Simpler Deployment-Workflow (z. B. über CI/CD)

Ein Headless CMS (Content Management System) ist ein Content-Management-System, bei dem das Backend (die Inhalte und ihre Verwaltung) vom Frontend (der Darstellung für die Nutzer) vollständig getrennt ist.

Im Detail:

Klassisches CMS (z. B. WordPress):

• Backend und Frontend sind gekoppelt.

• Die Inhalte werden im System erstellt und direkt als HTML über ein fest integriertes Theme angezeigt.

• Vorteil: Alles aus einer Hand.

• Nachteil: Eingeschränkte Flexibilität, schwer für Multi-Plattform-Ausgabe (z. B. App + Webseite + Smartwatch).

Headless CMS:

• Nur Backend.

• Inhalte werden über eine API (z. B. REST oder GraphQL) bereitgestellt.

• Das Frontend (z. B. eine React-Webseite, native App, Digital Signage) holt sich die Inhalte dynamisch.

• Vorteil: Sehr flexibel, geeignet für Multi-Channel-Ausspielung.

• Nachteil: Frontend muss separat entwickelt werden (mehr Aufwand).

Typische Einsatzszenarien:

• Webseiten mit modernen JavaScript-Frameworks (z. B. React, Next.js, Vue)

• Mobile Apps, die denselben Content wie die Website zeigen sollen

• Omnichannel-Strategien: Website, App, IoT-Geräte, etc.

Beispiele für Headless CMS:

• Contentful

• Strapi

• Sanity

• Directus

• Prismic

• Storyblok (Hybrid-Ansatz mit Visual Editor)