128 lines
3.6 KiB
Markdown
128 lines
3.6 KiB
Markdown
<!-- file: docs/IDEAS.md -->
|
|
<!-- version: 5 -->
|
|
|
|
# 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 :
|
|
|
|
```text
|
|
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 :
|
|
|
|
```text
|
|
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.
|