Docs: WSS/Streaming-Architektur festgehalten (Core-Verbindungsklasse, Modul-Instanzen)
- Neue Sektion 2.7: Core stellt wiederverwendbare WSS-Verbindungsklasse bereit (Factory, keine geteilten Singleton-Streams); jedes Modul erzeugt eigene Instanz mit eigenem API-Key + eigenem Filter (Streams sind modulspezifisch gefiltert). AlchemyWebsocketService wird entsprechend aufgeteilt. - API-Keys wandern von globaler ServerSettings in die Modul-Settings. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Opus 4.8
parent
f5e7eaf2d5
commit
7e189fec54
@@ -134,6 +134,32 @@ Eintrag in den Core-Log und einen Detaileintrag in seinen eigenen Log.
|
||||
Betriebsschalter).
|
||||
- **Modul-Settings-Sektion:** jedes Modul trägt seine eigene Sektion zum Settings-Tab bei
|
||||
(analog zu den UI-Tabs), registriert über den `IPolyTraderModule`-Contract.
|
||||
- **API-Keys sind Modul-Settings:** Alchemy-/Polymarket-WSS-Keys wandern von der globalen
|
||||
`ServerSettings` in die jeweilige Modul-Settings-Sektion (siehe 2.7).
|
||||
|
||||
### 2.7 Streaming / WebSocket-Architektur *(Entscheidung 2026-07-01)*
|
||||
|
||||
**Prinzip:** Der **Core stellt die WSS-Verbindungs-Klasse als wiederverwendbare Fähigkeit**
|
||||
bereit — **keinen** geteilten Singleton-Stream. Jedes **Modul erzeugt seine eigene Instanz**
|
||||
mit **eigenem API-Key und eigenem Filter**.
|
||||
|
||||
**Begründung:** Blockchain-/WSS-Streams werden modulspezifisch **gefiltert** (sonst viel zu
|
||||
umfangreich). Ein einzelner, Core-gesteuerter Stream, auf den mehrere Module gleichzeitig
|
||||
zugreifen, wäre für jedes einzelne Modul mit nutzlosen Informationen geflutet.
|
||||
|
||||
**Aufteilung des heutigen `AlchemyWebsocketService`:**
|
||||
- **Core** (`PolyTrader.Core.Streaming`): Verbindungs-Mechanik — `ClientWebSocket`, `eth_subscribe`,
|
||||
Empfangs-Loop, Decode, Reconnect/429-Backoff, Health. Parametrisiert über eine
|
||||
`BlockchainWssSubscription` (Contract, Topics, Adress-Filter) + RPC-URL/Key. Als **Factory**
|
||||
(`IBlockchainWssClientFactory.Create()`), damit jedes Modul eine eigene Instanz bekommt.
|
||||
- **Modul** (`CopyTrading`): `CopyTradingBlockchainListener : BackgroundService`, der eine
|
||||
Core-WSS-Instanz mit dem Copytrading-Filter (Wallets der getrackten Master-Trader) + dem
|
||||
Modul-eigenen Alchemy-Key betreibt, den gefilterten Substream konsumiert und selbst reagiert
|
||||
(TraderMonitor-Poll, Re-Subscribe bei Trader-Listen-Änderung).
|
||||
|
||||
Analog für den Polymarket-User/Market-WSS (`PolymarketWssClient` → Core-Verbindungsklasse +
|
||||
Modul-Listener). `IsAlchemyHealthy` (heute im Core-State) wird zum Health-Signal der jeweiligen
|
||||
Modul-Instanz.
|
||||
|
||||
---
|
||||
|
||||
@@ -234,10 +260,15 @@ Dreh- und Angelpunkt für Phase 5.
|
||||
Accounts, MarketCache, GlobalPnl) vs. `CopyTradingState` im Modul (Traders,
|
||||
MasterTraderPositions, TraderAnalyticsCache, TotalCopyTrades, PendingOrderTimestamps,
|
||||
SixSharesMinimum); 10 Konsumenten umgestellt. Modulgrenze auf State-Ebene gezogen.
|
||||
- [x] **5.3a** (`f5e7eaf`): MarketSyncService → Core (nur Core-State).
|
||||
- [ ] **5.3:** Modul-Services physisch ins Modul-Projekt verschieben: TraderMonitorService,
|
||||
CopyTradingEngine, beide Analytics-Jobs. Ebenso die jetzt entkoppelbaren Infra-Services
|
||||
neu verorten: MarketSyncService (nur Core-State → Core), Alchemy/WSS/Snapshot
|
||||
(CopyTradingState-gekoppelt → Modul bzw. bleiben vorerst App).
|
||||
CopyTradingEngine, beide Analytics-Jobs (blockiert durch ClosedTrade-Migration, s.u.).
|
||||
- [ ] **5.3-WSS (siehe 2.7):** `AlchemyWebsocketService` **aufteilen** — Verbindungs-Klasse
|
||||
(`IBlockchainWssClient` + Factory) → Core; `CopyTradingBlockchainListener` → Modul
|
||||
(eigener Key + Filter). Analog `PolymarketWssClient`. API-Keys → Modul-Settings.
|
||||
- [ ] **ClosedTrade-Migration (Voraussetzung für 5.3):** `ClosedTrade` → Modul,
|
||||
`ICopyTradeLogRepository`, `closed_trades`-Zugriffe in TraderMonitor/CopyTradingEngine/WSS
|
||||
umstellen (~20-25 Stellen; frm_main/Persistence-Nutzungen laufen via Modul-Referenz weiter).
|
||||
- [ ] Copytrading-UI-Tabs aus `frm_main` in das Modul auslagern (Master/Slave-Verwaltung,
|
||||
Modul-Analyse, Closed Trades). `frm_main` wird zur reinen Shell (Terminal, Jobs,
|
||||
Core-Gesamt-Dashboard, Settings-Rahmen).
|
||||
|
||||
Reference in New Issue
Block a user