Vue d’ensemble de l’architecture

Fichiers source

Cette page est générée à partir des fichiers source suivants :

• apps/sim/blocks/registry.ts
• apps/sim/blocks/types.ts
• apps/sim/executor/index.ts
• apps/sim/connectors/registry.ts
• apps/sim/triggers/registry.ts
• apps/sim/socket/index.ts
• .claude/rules/sim-architecture.md
• apps/sim/blocks/utils.ts
• apps/sim/triggers/index.ts
• apps/sim/blocks/index.ts
• packages/db/index.ts
• packages/python-sdk/setup.py
• apps/sim/tools/index.ts
• apps/sim/stores/index.ts
• packages/cli/src/index.ts
• apps/sim/providers/index.ts
• apps/sim/connectors/index.ts
• apps/sim/serializer/index.ts
• packages/logger/src/index.ts
• packages/ts-sdk/src/index.ts

Sim Studio AI est une plateforme d'automatisation de workflows basée sur une architecture modulaire et extensible. Le système permet de créer, orchestrer et exécuter des workflows complexes en connectant plus de 150 intégrations externes via un système de blocs configurables, de déclencheurs événementiels et de connecteurs normalisés.

Architecture système globale

La plateforme repose sur plusieurs couches architecturales distinctes : une couche de présentation pour l'interface utilisateur, une couche d'orchestration pour l'exécution des workflows, une couche d'intégration pour les connexions externes, et une couche de communication temps réel pour la synchronisation des états.

正在加载图表渲染器...

Points clés de l'architecture :

1. Séparation des responsabilités : Chaque couche a un rôle bien défini, permettant une maintenance et une évolution indépendantes des composants
2. Registres centralisés : Les blocs, triggers et connecteurs sont gérés via des registres unifiés (apps/sim/blocks/registry.ts:207-280, apps/sim/triggers/registry.ts:176-250, apps/sim/connectors/registry.ts:33-64)
3. Communication temps réel optionnelle : Le système peut fonctionner avec ou sans Redis pour la scalabilité horizontale
4. Extensibilité : L'ajout de nouvelles intégrations se fait par simple ajout au registre correspondant

Registre des blocs et extensibilité

Le système de blocs constitue le cœur fonctionnel de la plateforme. Chaque bloc représente une unité de traitement configurable, capable d'interagir avec des services externes ou d'effectuer des transformations de données.

Structure du registre des blocs

Le registre central définit plus de 150 types de blocs, couvrant une large gamme de services : API HTTP, bases de données (PostgreSQL, MongoDB, DynamoDB), services cloud (AWS S3, Google Drive, Dropbox), outils de collaboration (Slack, Discord, Microsoft Teams), et plateformes métier (Salesforce, HubSpot, Jira).

typescript
1// Extrait conceptuel de la structure du registre
2export const registry: Record<string, BlockConfig> = {
3  agent: AgentBlock,
4  api: ApiBlock,
5  github: GitHubBlock,
6  slack: SlackBlock,
7  // ... 150+ autres blocs
8}

Responsabilités du registre :

• Centraliser la configuration de tous les blocs disponibles
• Fournir une fonction de recherche normalisée via getBlock() (apps/sim/blocks/registry.ts:432-437)
• Supporter la normalisation des identifiants (conversion tirets/underscores)

Système de types configurable

Chaque bloc est configuré via une structure BlockConfig qui définit ses paramètres d'entrée, ses sous-blocs et ses métadonnées. Le système de types permet une validation statique et dynamique des configurations.

正在加载图表渲染器...

Éléments clés du système de types (apps/sim/blocks/types.ts:256-288) :

1. ParamConfig : Définit le type, la description et le schéma JSON de validation pour chaque paramètre
2. SubBlockConfig : Configure les sous-composants avec leur visibilité (user-or-llm, user-only, llm-only, hidden)
3. Conditions de requis : Support de conditions complexes pour l'affichage conditionnel des paramètres

Importations et étendue des intégrations

Les importations du registre révèlent l'étendue des capacités d'intégration (apps/sim/blocks/registry.ts:1-100) :

Moteur dexécution DAG

Le moteur d'exécution repose sur une architecture de graphe acyclique dirigé (DAG), permettant l'orchestration parallèle et séquentielle des tâches au sein d'un workflow.

Architecture de l'exécuteur

L'exécuteur principal est exporté comme point d'entrée unique depuis le module executor (apps/sim/executor/index.ts:1-6) :

typescript
1/**
2 * Executor - Main entry point
3 * Exports the DAG executor as the default executor
4 */
5export { DAGExecutor as Executor } from '@/executor/execution/executor'

Responsabilités du DAGExecutor :

• Orchestration de l'exécution des blocs selon leurs dépendances
• Gestion du parallélisme pour les tâches indépendantes
• Propagation des données entre les blocs connectés
• Gestion des erreurs et des retries

Flux d'exécution d'un workflow

正在加载图表渲染器...

Points clés du flux d'exécution :

1. Construction du DAG : Analyse des dépendances entre blocs pour déterminer l'ordre d'exécution optimal
2. Résolution des blocs : Utilisation de getBlock() pour récupérer la configuration (apps/sim/blocks/registry.ts:432-437)
3. Exécution parallèle : Les blocs sans dépendance mutuelle sont exécutés simultanément
4. Propagation des données : Les sorties d'un bloc alimentent les entrées des blocs descendants

Gestion des erreurs et résilience

Le système d'exécution implémente plusieurs stratégies de résilience :

• Isolation des erreurs : Un bloc en échec n'affecte pas les branches parallèles indépendantes
• Retry configurable : Possibilité de définir des politiques de retry par bloc
• Timeouts : Protection contre les blocages via des timeouts configurables
• Logging centralisé : Traçabilité complète des exécutions via le package logger

Système de déclencheurs (Triggers)

Le système de triggers permet l'automatisation événementielle en réagissant à des événements externes provenant de multiples sources.

Registre des déclencheurs

Le registre TRIGGER_REGISTRY centralise tous les types de déclencheurs disponibles (apps/sim/triggers/registry.ts:176-250) :

正在加载图表渲染器...

Catégories de triggers disponibles (apps/sim/triggers/registry.ts:1-90) :

Architecture des triggers

Chaque trigger est configuré avec :

1. Type d'événement : Identifiant unique dans le registre
2. Source de données : Service externe émetteur
3. Filtres : Conditions optionnelles pour filtrer les événements
4. Mapping : Transformation des données d'entrée en format standardisé

Intégration avec le moteur d'exécution

Lorsqu'un trigger est activé :

1. Le système reçoit l'événement (webhook ou polling)
2. Le trigger valide et transforme les données
3. Le workflow associé est instancié avec les données du trigger
4. Le DAGExecutor prend le relais pour l'exécution du workflow

Connecteurs et intégrations externes

Les connecteurs fournissent une couche d'abstraction pour l'authentification et la communication avec les services tiers.

Registre des connecteurs

Le CONNECTOR_REGISTRY centralise les configurations de connexion pour tous les services supportés (apps/sim/connectors/registry.ts:33-64) :

typescript
1export const CONNECTOR_REGISTRY: ConnectorRegistry = {
2  airtable: airtableConnector,
3  asana: asanaConnector,
4  confluence: confluenceConnector,
5  discord: discordConnector,
6  github: githubConnector,
7  gmail: gmailConnector,
8  google_drive: googleDriveConnector,
9  hubspot: hubspotConnector,
10  slack: slackConnector,
11  // ... autres connecteurs
12}

Connecteurs disponibles (apps/sim/connectors/registry.ts:13-32) :

Responsabilités des connecteurs

1. Authentification : Gestion des flux OAuth et des tokens d'API
2. Normalisation : Conversion des formats de données propriétaires
3. Rate limiting : Respect des limites d'API des services
4. Retry logic : Gestion des erreurs temporaires

Communication temps réel et sockets

Le serveur Socket.IO assure la communication bidirectionnelle entre le client et le serveur pour les mises à jour en temps réel.

Architecture du serveur de sockets

Le serveur de sockets supporte deux modes de fonctionnement (apps/sim/socket/index.ts:15-28) :

typescript
1async function createRoomManager(io: SocketIOServer): Promise<IRoomManager> {
2  if (env.REDIS_URL) {
3    logger.info('Initializing Redis-backed RoomManager for multi-pod support')
4    const manager = new RedisRoomManager(io, env.REDIS_URL)
5    await manager.initialize()
6    return manager
7  }
8
9  logger.warn('No REDIS_URL configured - using in-memory RoomManager (single-pod only)')
10  const manager = new MemoryRoomManager(io)
11  await manager.initialize()
12  return manager
13}

Modes de déploiement :

Initialisation et configuration

Le processus d'initialisation du serveur (apps/sim/socket/index.ts:30-55) :

1. Création du serveur HTTP : Base pour Socket.IO
2. Configuration du port : PORT, SOCKET_PORT, ou 3002 par défaut
3. Création du serveur Socket.IO : Avec adaptateur Redis si configuré
4. Initialisation du RoomManager : Redis ou in-memory
5. Middleware d'authentification : Validation des connexions
6. Handler HTTP : Health checks et APIs internes

正在加载图表渲染器...

Gestion des rooms et authentification

Le système de rooms permet d'isoler les communications par contexte (workflow, utilisateur, session). L'authentification des sockets est assurée par un middleware dédié qui valide les credentials avant d'autoriser la connexion.

Décisions architecturales et compromis

Choix de conception majeurs

Limitations connues

1. Single-pod sans Redis : Le mode in-memory limite la scalabilité horizontale
2. Latence des webhooks : Dépendante de la réactivité des services externes
3. Complexité des workflows imbriqués : Les workflows appelant d'autres workflows peuvent créer des chaînes d'exécution difficiles à tracer

Patterns architecturaux utilisés

• Registry Pattern : Pour les blocs, triggers et connecteurs
• Strategy Pattern : Pour les différents types d'exécution de blocs
• Observer Pattern : Pour les triggers et la communication temps réel
• Factory Pattern : Pour la création des RoomManagers

Tableau récapitulatif des technologies

Flux de données de bout en bout

正在加载图表渲染器...

Points clés du flux de données :

1. Persistance : Les workflows sont stockés en base de données pour reprise et historique
2. Résolution dynamique : Les blocs sont résolus à l'exécution via le registre
3. Communication asynchrone : Socket.IO permet les mises à jour sans polling
4. Isolation des appels externes : Les connecteurs encapsulent la logique d'intégration

Configuration et démarrage

Variables d'environnement critiques

Processus de démarrage

1. Validation de l'environnement : Vérification des variables requises
2. Connexion à la base de données : Initialisation du pool de connexions
3. Chargement des registres : Import des blocs, triggers et connecteurs
4. Démarrage du serveur HTTP : Écoute sur le port configuré
5. Initialisation Socket.IO : Avec ou sans Redis selon la configuration
6. Enregistrement des handlers : Routes API et middleware d'authentification

Health checks et monitoring

Le serveur de sockets expose des endpoints de health check via le handler HTTP (apps/sim/socket/index.ts:51-53), permettant aux orchestrateurs de conteneurs (Kubernetes, Docker Swarm) de vérifier l'état du service.

---

Cette architecture modulaire et extensible permet à Sim Studio AI de supporter un large écosystème d'intégrations tout en maintenant une base de code cohérente et maintenable. Les registres centralisés facilitent l'ajout de nouvelles fonctionnalités, tandis que le moteur d'exécution DAG assure des performances optimales pour les workflows complexes.