Vue d’ensemble des intégrations

CodeCourier repose sur un ensemble soigneusement choisi de services tiers, chacun fournissant une capacité critique qu’il serait peu pratique de développer en interne. Plutôt qu’une infrastructure monolithique, CodeCourier suit une architecture composable où chaque intégration gère un seul domaine, et le gère exceptionnellement bien. Cette page présente une vue d’ensemble de chaque intégration, ce qu’elle apporte, et comment les différentes pièces s’assemblent.

Architecture des intégrations

Le flux de données de la plateforme peut être compris en quatre couches :

1. Couche d’authentification (Clerk) -- Gère l’inscription, la connexion, la gestion de session et l’identité des utilisateurs. Clerk émet des JWT que Convex valide à chaque appel de fonction.
2. Couche de données (Convex) -- La base de données réactive qui stocke tout l’état de l’application : utilisateurs, projets, sandboxes, workflows, runs, messages, learnings et enregistrements d’utilisation. Convex fournit des abonnements en temps réel afin que le tableau de bord se mette à jour instantanément dès que les données changent.
3. Couche d’exécution (E2B) -- Fournit des machines virtuelles Linux cloud isolées où s’exécutent les agents de codage IA. E2B gère le provisionnement des VM, l’accès au système de fichiers, l’exécution des processus et la gestion réseau.
4. Couche d’orchestration (Trigger.dev) -- Gère les tâches de fond de longue durée qui coordonnent l’ensemble du workflow : provisionnement des sandboxes, envoi des prompts, itérations designer-checker, extraction des learnings et création des pull requests.

Intégrations disponibles

Sandboxes E2B

E2B fournit les environnements d’exécution cloud isolés qui constituent le cœur de CodeCourier. Chaque sandbox est une micro-VM E2B avec son propre noyau Linux, système de fichiers et pile réseau. Le SDK E2B (version 2.14+) est utilisé pour créer, connecter et gérer le cycle de vie des sandboxes.

Lire le guide d’intégration E2B

Trigger.dev

Trigger.dev gère l’ensemble du traitement des tâches de fond. L’orchestration des workflows, l’exécution des work chains, les issue sessions, la découverte d’issues, l’extraction des learnings et les opérations de l’agent de merge s’exécutent tous comme des tâches Trigger.dev. Cela permet au backend Convex de rester réactif pendant que les opérations IA de longue durée s’exécutent de manière asynchrone.

Lire le guide d’intégration Trigger.dev

Authentification Clerk

Clerk fournit une authentification prête à l’emploi avec prise en charge de l’e-mail et du mot de passe, des fournisseurs OAuth (Google, GitHub) et des liens magiques. Le SDK @clerk/nextjs (version 6+) s’intègre directement au routeur d’application Next.js, et les JWT Clerk sont transmis à Convex pour la vérification d’identité côté serveur.

Lire le guide d’intégration Clerk

Base de données Convex

Convex est la plateforme de base de données réactive qui alimente tout le stockage de données et les fonctionnalités en temps réel. Les queries se ré-exécutent automatiquement lorsque les données sous-jacentes changent, les mutations sont transactionnelles, et les actions permettent d’appeler des services externes. Le schéma Convex définit toutes les tables, index et règles de validation.

Lire le guide d’intégration Convex

Comment les intégrations sont configurées

Chaque intégration nécessite une configuration spécifique, généralement via des variables d’environnement. Voici un résumé de ce dont chaque intégration a besoin :

Variables d’environnement requises

• Convex -- CONVEX_DEPLOYMENT et NEXT_PUBLIC_CONVEX_URL sont définies automatiquement lors de la configuration du projet.
• Clerk -- NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY et CLERK_SECRET_KEY depuis le tableau de bord Clerk. CLERK_WEBHOOK_SECRET pour la vérification des webhooks.
• Trigger.dev -- TRIGGER_SECRET_KEY pour le SDK Trigger.dev, TRIGGER_CALLBACK_SECRET pour les callbacks sécurisés vers Convex.
• E2B -- Les utilisateurs fournissent leur propre clé API E2B via le tableau de bord, qui est chiffrée et stockée dans la base de données. Aucune configuration E2B au niveau serveur n’est nécessaire.

Clés API fournies par l’utilisateur

En plus de la configuration au niveau serveur, les utilisateurs ou projets individuels peuvent fournir leurs propres clés API pour les services que les sandboxes utilisent à l’exécution :

• Clé API E2B -- Requise pour le provisionnement des sandboxes.
• Clé API ou token Anthropic -- Requis pour les sandboxes Claude Code.
• Clé API OpenRouter -- Pour l’accès aux modèles via OpenRouter.
• Clé API OpenAI -- Pour Codex et les outils basés sur OpenAI.
• Token GitHub -- Pour les opérations sur les dépôts au sein des sandboxes.

Ces clés peuvent être définies au niveau utilisateur (s’appliquant à tous les projets) ou au niveau projet (remplaçant les clés au niveau utilisateur pour ce projet spécifique). Toutes les clés sont chiffrées avant stockage.

Dépendances entre intégrations

Les intégrations ont des relations de dépendance spécifiques :

• Clerk dépend de Convex -- Les JWT Clerk sont validés par Convex. La table utilisateur dans Convex stocke la correspondance entre les identifiants Clerk et les identifiants utilisateur internes.
• Trigger.dev dépend de Convex -- Toutes les tâches Trigger.dev rapportent leur progression à Convex via le point de terminaison de callback HTTP.
• E2B dépend de Trigger.dev -- Le provisionnement et la gestion des sandboxes se produisent au sein des tâches Trigger.dev. Les opérations E2B ne sont jamais appelées directement depuis le navigateur.
• Convex est le pivot central -- Tous les autres services communiquent via Convex, ce qui en fait le magasin de données central et le point de coordination.

Versions des paquets

CodeCourier utilise les versions de paquets d’intégration suivantes (consultez package.json pour les dernières versions) :

• 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