Talkz

Lokales Backend mit Docker Compose

Voraussetzung ist Docker Desktop oder eine andere aktuelle Docker-Installation mit Compose v2.

Der vollständige lokale Backend-Stack wird aus dem Repository-Stamm gestartet:

docker compose up --build

Für einen Start im Hintergrund:

docker compose up --build --detach
docker compose ps

Die wichtigsten lokalen Endpunkte sind:

Komponente	URL/Port
API Gateway	http://localhost:5100
Realtime Gateway	http://localhost:5120
Auth Service	http://localhost:5055
Party Service	http://localhost:5151
Message Service	http://localhost:5263 (Health), http://localhost:5264 (gRPC)
PostgreSQL	localhost:5432
Kafka	localhost:9092
Redis	localhost:6379

Das API Gateway kann nach dem Start so geprüft werden:

Invoke-RestMethod http://localhost:5100/health/live
Invoke-RestMethod http://localhost:5100/health/ready

Die Authentifizierung verwendet einen externen Auth0-Tenant. Lege dort eine Regular Web Application und eine API an. Aktiviere eine Database Connection sowie die benötigten Social- und Enterprise-Connections. Für die lokale Anwendung werden mindestens diese Auth0-Einstellungen benötigt:

• Allowed Callback URL: http://localhost:5100/auth/callback
• Allowed Web Origin: http://localhost:5173
• Allowed Logout URL: http://localhost:5173
• Database-Signups und E-Mail-Verifikation für die produktive Connection

Damit Talkz den bei Auth0 hinterlegten Benutzernamen statt des aus der E-Mail abgeleiteten Handles anzeigt, muss unter Actions → Library → Build Custom eine Post-Login-Action mit folgendem Inhalt angelegt, deployed und dem Login-Flow hinzugefügt werden:

exports.onExecutePostLogin = async (event, api) => {
  if (event.user.username) {
    api.idToken.setCustomClaim(
      'https://api.talkz.local/username',
      event.user.username
    );
  }
};

Das Gateway übernimmt den namespaced Username-Claim bevorzugt in die interne Benutzerprojektion. Für Social- oder Enterprise-Identitäten ohne eigenen Username bleibt der Name-Claim der Fallback.

Domain, API-Identifier, Client-ID, Client-Secret, Connection-Namen und ein zufälliger interner Service-Key werden über eine nicht versionierte .env-Datei gesetzt. Eine Vorlage liegt in .env.compose.example. Client-Secret und Service-Key dürfen nicht committed werden. Einen lokalen Service-Key kannst du beispielsweise mit openssl rand -base64 48 erzeugen.

Das API Gateway verwendet Authorization Code + PKCE und speichert keine Auth0-Tokens im Browser. Nach erfolgreicher Anmeldung enthält der Browser ausschließlich das verschlüsselte, sichere Talkz-Session-Cookie. Der AuthService legt die interne Benutzerprojektion per EF-Core-Migration in auth_db an.

Der Stack wird mit folgendem Befehl beendet:

docker compose down

docker compose down --volumes entfernt zusätzlich alle lokalen PostgreSQL-, Kafka- und Redis-Daten. Dieser Befehl ist nur für einen vollständigen lokalen Neustart vorgesehen.