Integrationen – Übersicht

Verstehen Sie, wie CodeCourier mit E2B, Trigger.dev, Clerk, Convex und weiteren Diensten zusammenspielt, um eine vollständige KI-Workflow-Plattform bereitzustellen.

6 min Lesezeit
integrationsoverviewe2b

CodeCourier basiert auf einer sorgfältig ausgewählten Reihe von Drittanbieterdiensten, die jeweils eine entscheidende Fähigkeit bereitstellen, deren Eigenentwicklung unpraktikabel wäre. Anstelle einer monolithischen Infrastruktur folgt CodeCourier einer komponierbaren Architektur, in der jede Integration einen Bereich besonders gut abdeckt. Diese Seite gibt Ihnen einen Überblick über jede Integration, ihre Aufgaben und das Zusammenspiel der einzelnen Bausteine.

Integrationsarchitektur

Der Datenfluss der Plattform lässt sich in vier Schichten verstehen:

  1. Authentifizierungsschicht (Clerk) -- Verwaltet Registrierung, Anmeldung, Sitzungsverwaltung und Identität. Clerk stellt JWTs aus, die Convex bei jedem Funktionsaufruf validiert.
  2. Datenschicht (Convex) -- Die reaktive Datenbank, die den gesamten Anwendungszustand speichert: Benutzer, Projekte, Sandboxes, Workflows, Runs, Nachrichten, Learnings und Nutzungsdaten. Convex bietet Echtzeit-Abonnements, sodass das Dashboard sofort aktualisiert wird, wenn sich Daten ändern.
  3. Ausführungsschicht (E2B) -- Stellt isolierte Linux-Cloud-VMs bereit, in denen KI-Coding-Agents laufen. E2B übernimmt VM-Provisionierung, Dateisystemzugriff, Prozess- ausführung und Netzwerkverwaltung.
  4. Orchestrierungsschicht (Trigger.dev) -- Verwaltet langlaufende Hintergrundaufgaben, die den gesamten Workflow koordinieren: Bereitstellung von Sandboxes, Senden von Prompts, Designer-Checker-Iterationen, Extraktion von Learnings und Erstellung von Pull Requests.

Verfügbare Integrationen

E2B Sandboxes

E2B stellt die isolierten Cloud-Ausführungsumgebungen bereit, die das Herzstück von CodeCourier bilden. Jede Sandbox ist eine E2B-Micro-VM mit eigenem Linux-Kernel, Dateisystem und Netzwerk- Stack. Das E2B SDK (Version 2.14+) wird zum Erstellen, Verbinden und Verwalten von Sandbox-Lebenszyklen verwendet.

Lesen Sie den E2B-Integrationsleitfaden

Trigger.dev

Trigger.dev übernimmt die gesamte Hintergrundverarbeitung. Workflow- Orchestrierung, Work-Chain-Ausführung, Issue Sessions, Issue Discovery, Learning-Extraktion und Merge-Agent-Operationen laufen alle als Trigger.dev-Tasks. So bleibt das Convex-Backend reaktions- fähig, während langlaufende KI-Operationen asynchron ausgeführt werden.

Lesen Sie den Trigger.dev-Integrationsleitfaden

Clerk-Authentifizierung

Clerk bietet eine Drop-in-Authentifizierung mit Unterstützung für E-Mail und Passwort, OAuth-Anbieter (Google, GitHub) und Magic Links. Das @clerk/nextjs SDK (Version 6+) integriert sich direkt in den Next.js App Router, und Clerk-JWTs werden zur serverseitigen Identitätsprüfung an Convex weitergegeben.

Lesen Sie den Clerk-Integrationsleitfaden

Convex-Datenbank

Convex ist die reaktive Datenbankplattform, die die gesamte Datenspeicherung und Echtzeit-Funktionen antreibt. Queries werden automatisch erneut ausgeführt, wenn sich zugrunde liegende Daten ändern, Mutations sind transaktional und Actions ermöglichen den Aufruf externer Dienste. Das Convex-Schema definiert alle Tabellen, Indizes und Validierungsregeln.

Lesen Sie den Convex-Integrationsleitfaden

Wie Integrationen konfiguriert werden

Jede Integration erfordert spezifische Konfiguration, in der Regel über Umgebungsvariablen. Hier eine Zusammenfassung dessen, was jede Integration benötigt:

Erforderliche Umgebungsvariablen

  • Convex -- CONVEX_DEPLOYMENT und NEXT_PUBLIC_CONVEX_URL werden während des Projekt-Setups automatisch gesetzt.
  • Clerk -- NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY und CLERK_SECRET_KEY aus dem Clerk-Dashboard. CLERK_WEBHOOK_SECRET für die Webhook-Verifizierung.
  • Trigger.dev -- TRIGGER_SECRET_KEY für das Trigger.dev SDK, TRIGGER_CALLBACK_SECRET für sichere Callbacks an Convex.
  • E2B -- Benutzer stellen ihren eigenen E2B-API- Key über das Dashboard bereit, der verschlüsselt in der Datenbank gespeichert wird. Eine serverseitige E2B-Konfiguration ist nicht erforderlich.

Vom Benutzer bereitgestellte API-Keys

Zusätzlich zur serverseitigen Konfiguration können einzelne Benutzer oder Projekte eigene API-Keys für Dienste bereitstellen, die Sandboxes zur Laufzeit nutzen:

  • E2B API Key -- Erforderlich für die Sandbox- Provisionierung.
  • Anthropic API Key oder Token -- Erforderlich für Claude-Code-Sandboxes.
  • OpenRouter API Key -- Für den Modellzugriff über OpenRouter.
  • OpenAI API Key -- Für Codex und OpenAI-basierte Tools.
  • GitHub Token -- Für Repository-Operationen innerhalb von Sandboxes.

Diese Keys können auf Benutzerebene (gültig für alle Projekte) oder auf Projektebene (überschreiben Benutzer-Keys für ein bestimmtes Projekt) festgelegt werden. Alle Keys werden vor der Speicherung verschlüsselt.

Abhängigkeiten zwischen Integrationen

Die Integrationen haben spezifische Abhängigkeitsbeziehungen:

  • Clerk hängt von Convex ab -- Clerk-JWTs werden von Convex validiert. Die User-Tabelle in Convex speichert die Zuordnung zwischen Clerk-IDs und internen Benutzer-IDs.
  • Trigger.dev hängt von Convex ab -- Alle Trigger.dev-Tasks melden Fortschritte über den HTTP-Callback- Endpoint an Convex zurück.
  • E2B hängt von Trigger.dev ab -- Sandbox- Provisionierung und -Verwaltung erfolgen innerhalb von Trigger.dev-Tasks. E2B-Operationen werden niemals direkt aus dem Browser aufgerufen.
  • Convex ist der Knotenpunkt -- Alle anderen Dienste kommunizieren über Convex, das damit zum zentralen Datenspeicher und Koordinationspunkt wird.

Paketversionen

CodeCourier verwendet die folgenden Versionen der Integrations- Pakete (prüfen Sie package.json für die aktuellen Versionen):

  • convex -- ^1.32.0
  • @clerk/nextjs -- ^6.39.0
  • e2b -- ^2.14.0
  • @trigger.dev/sdk -- 4.4.3
  • @trigger.dev/react-hooks -- 4.4.3
  • @anthropic-ai/sdk -- ^0.78.0