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

Ein Repository (deutsch: „Ablage“, „Speicher“ oder „Depot“) ist ein zentraler Ort, an dem Daten, Dateien oder Code organisiert, gespeichert und verwaltet werden. Der Begriff wird je nach Kontext etwas unterschiedlich verwendet – hier sind die häufigsten Bedeutungen:

💻 In der Softwareentwicklung (z. B. bei GitHub oder GitLab):

Ein Repository ist ein Verzeichnis, das den Quellcode eines Projekts, Konfigurationsdateien, Dokumentationen und die Versionsgeschichte enthält. Es dient dazu, die Entwicklung von Software zu verfolgen, Änderungen zu speichern und im Team zusammenzuarbeiten.

• 🔁 Versionierung: Mit Tools wie Git kann man Änderungen rückgängig machen, alte Versionen vergleichen und neue Features in eigenen Branches entwickeln.

• 🤝 Zusammenarbeit: Entwickler können gemeinsam am Code arbeiten, Pull Requests stellen, Issues anlegen und Code-Reviews durchführen.

• 🌍 Remote-Repository: Online-Plattformen wie GitHub, GitLab oder Bitbucket hosten Repositories, damit Teams weltweit gemeinsam entwickeln können.

Beispiel:

git clone https://github.com/nutzername/mein-projekt.git

📦 In Paketverwaltungssystemen (z. B. Linux, Python):

Ein Repository ist eine Sammlung von Softwarepaketen, die von einer Paketverwaltung (z. B. apt, yum, pip) verwendet wird, um Programme zu installieren oder zu aktualisieren.

Beispiel:

sudo apt update
sudo apt install firefox

📚 Allgemeiner Begriff:

Auch außerhalb der IT kann ein „Repository“ eine Art Datenbank oder Archiv sein – z. B. für wissenschaftliche Publikationen oder digitale Sammlungen.

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

PEST ist ein moderner Testing-Framework für PHP, das vor allem durch seine lesbare Syntax, Expressivität und enge Integration mit PHPUnit besticht.

📌 PEST = "PHP Testing for Humans"
Es richtet sich an Entwickler, die saubere, lesbare und schnelle Tests schreiben wollen – ohne viel Boilerplate.

🚀 Warum PEST statt PHPUnit?

PEST basiert auf PHPUnit, aber es:

• bietet eine minimalistische, expressive Syntax

• entfernt unnötigen Overhead

• unterstützt funktionalen, verhaltensbasierten Teststil

• lässt sich optional mit einer klassischen PHPUnit-Struktur kombinieren

🔍 Beispiel – PHPUnit vs. PEST

PHPUnit:

class UserTest extends TestCase
{
    public function test_user_has_name()
    {
        $user = new User('John');
        $this->assertEquals('John', $user->name);
    }
}

PEST:

it('has a name', function () {
    $user = new User('John');
    expect($user->name)->toBe('John');
});

👉 Deutlich kürzer, besser lesbar – besonders bei vielen Tests.

🧩 Features von PEST

• ✅ Elegante Syntax (ähnlich wie Jest oder Mocha in JavaScript)

• 🧪 Unterstützt unit, feature, API, browser-based Tests

• 🧱 Datengetriebene Tests (with([...]))

• 🧬 Test-Hooks wie beforeEach() / afterEach()

• 🎨 Erweiterbar über Plugins & eigene Expectations

• 🔄 Kompatibel mit PHPUnit (du kannst PHPUnit-Tests weiter nutzen)

🛠️ Installation

In einem Laravel- oder Composer-Projekt:

composer require pestphp/pest --dev
php artisan pest:install  # (für Laravel-Projekte)

Dann kannst du direkt loslegen:

./vendor/bin/pest

🧠 Fazit

PEST ist ideal, wenn du:

• Tests schreiben willst, die Spaß machen

• sauberen, modernen Code bevorzugst

• bereits PHPUnit nutzt, aber Lust auf mehr Expressivität hast

💡 Viele moderne Laravel-Entwickler steigen auf PEST um, weil es sich perfekt in Laravel-Apps integriert und das Testen „menschlich“ macht – wie der Slogan schon sagt.

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.

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)