3.6 KiB
Idées à explorer
APIs et extensibilité
Nomenclature *-api
Status : Retenue
Les crates de contrats publics extensibles utilisent ksp-<domain>-api, sans suffixe -lib.
Premiers couples retenus :
ksp-program-api / ksp-program-lib
ksp-materializer-api / ksp-materializer-lib
ksp-store-api / ksp-store-lib
Éviter un unique ksp-api-lib monolithique.
APIs workers et jobs
Status : Retenue
Les workers et jobs ont des modèles de lifecycle différents et ne doivent pas partager une API universelle commune.
Prévoir séparément :
ksp-worker-api
ksp-job-api
ksp-worker-control-lib reste un candidat d'implémentation de contrôle des workers uniquement.
Le besoin éventuel d'une implémentation commune de contrôle des jobs sera évalué séparément.
Type d'erreur KSP unique
Status : En exploration
La direction retenue est un seul type public ksp_core_lib::Error consommable par le workspace, sans obliger ksp-core-lib à connaître chaque domaine supérieur.
Nommage des items publics
Status : À explorer
Définir avec les premières APIs réelles les conventions de nommage des traits, structs, enums, aliases, constantes et autres items exportés publiquement.
Arborescence et réexports
Status : À explorer
Définir avec les premières crates fonctionnelles les conventions d'arborescence des modules/fichiers, façades lib.rs, modules API et réexports publics.
Données et notifications
Notifications normalisées de données
Status : Retenue
Une notification de donnée doit avoir la même représentation canonique pour le même type de donnée quelle que soit son origine.
ksp-store-api est le propriétaire candidat de ces contrats lorsque la notification signifie qu'une donnée persistée est disponible.
Le transport concret de notification reste indépendant du contrat.
Backend PostgreSQL
Status : Retenue
ksp-store-lib contient PostgreSQL comme implémentation de référence de ksp-store-api.
Workers et jobs
W1
Status : Retenue
W1 reste strictement un worker raw live/quasi-live avec reconfiguration à chaud, persistance raw et notification. Aucun replay/backfill.
Backfill historique
Status : Retenue
Le backfill historique est un job distinct, candidat ksp-job-backfill.
Autres jobs
Status : Retenue
Des jobs séparés pourront apparaître pour metadata, quotes ou autres traitements ponctuels lorsqu'un besoin réel existe.
Orchestrateur
Status : Retenue
Commencer par des managers séparés. Introduire un orchestrateur global lorsque plusieurs workers/managers le justifient. Les jobs restent gouvernés par leurs contrats propres.
Pipelines
Pas de pipeline monolithique
Status : Retenue
Ne pas créer de ksp-pipeline-lib. Les pipelines sont introduits séparément à la demande avec un périmètre borné.
Scénarios
Crates spécialisées
Status : Retenue
Ne pas créer de ksp-scenarios-lib monolithique. Utiliser des crates spécialisées ksp-scenario-<domain>-lib.
Memo, Token classique, ATA et Token-2022 restent séparés. Metaplex Token Metadata et Token-2022 Metadata peuvent partager une famille metadata ; Solana Program Metadata reste séparé.
Trading
Trading Intelligence avant application de trading
Status : Retenue
Construire d'abord statistiques, features, signaux, risque, backtests, détection de patterns/anomalies et intégrations ML telles que XGBoost. La couche/application de trading opérationnelle est construite ensuite.