osFoundry / Platform
Canali dati in tempo reale
Canali pub/sub con consegna at-least-once, replay storico e cursori per subscriber.
Che cos’è
I canali dati in tempo reale sono la spina dorsale di messaggistica di osFoundry per spostare eventi tra le parti in movimento del tuo spazio di lavoro. Qualsiasi produttore (un agente, un'app in esecuzione, un processo di codice o una chat) pubblica messaggi su un canale con nome, e ogni subscriber di quel canale li riceve. È il classico modello publish/subscribe: produttori e consumatori sono disaccoppiati, quindi puoi aggiungere o togliere subscriber senza toccare il codice che pubblica, e un singolo evento può diramarsi verso molti lettori contemporaneamente.
La consegna è at-least-once. Un messaggio già pubblicato raggiungerà ogni subscriber anche attraverso riconnessioni e riavvii, con il compromesso che un subscriber può occasionalmente vedere lo stesso messaggio due volte, perciò i consumatori dovrebbero trattare i propri handler come idempotenti (identifica il lavoro con un id di messaggio o deduplica su una chiave naturale). I canali conservano lo storico invece di scartare un messaggio nell'istante in cui viene letto, il che sblocca due cose: il replay, con cui un subscriber può rileggere i messaggi passati del canale anziché vedere solo ciò che arriva dal vivo, e i cursori per singolo subscriber, con cui ogni subscriber tiene traccia della propria posizione in modo indipendente. Un cursore significa che un subscriber che resta indietro, si disconnette o parte più tardi riprende esattamente da dove aveva lasciato, e due subscriber sullo stesso canale possono trovarsi in punti completamente diversi dello stream senza interferire tra loro.
Poiché osFoundry è uno spazio di lavoro desktop local-first e con la tua chiave (BYOK), questo piano dati gira accanto al tuo lavoro invece di passare per un message broker di terze parti che dovresti provisionare e pagare a postazione. I canali sono l'idraulica sotto le funzionalità che devono reagire al cambiamento nel momento in cui avviene: un agente che sorveglia nuovi elementi da elaborare, un'app che si aggiorna nell'istante in cui arrivano dati a monte, o una pipeline in cui uno stadio passa il testimone al successivo. E lasciano che quei pezzi comunichino senza polling né accoppiamento stretto, mentre i tuoi dati possono restare sul tuo dispositivo.
Funzionalità principali
- I canali pub/sub disaccoppiano produttori e consumatori, così un evento pubblicato si dirama verso ogni subscriber senza modificare il codice del publisher
- La consegna at-least-once fa sopravvivere i messaggi a riconnessioni e riavvii; progetta consumatori idempotenti, perché un messaggio può ripetersi ogni tanto
- Il replay dello storico consente a un subscriber di rileggere i messaggi passati anziché captare solo il traffico dal vivo, utile per chi si unisce tardi e per la rielaborazione
- I cursori per singolo subscriber tracciano la posizione di ogni lettore in modo indipendente, così un subscriber lento, riavviato o tardivo riprende esattamente da dove aveva lasciato
- Collega agenti, app, codice e chat su un piano dati condiviso e local-first, senza broker esterno da provisionare né costi a postazione
Casi d’uso
- Creatore di agenti: un agente si iscrive a un canale di task in arrivo ed elabora ciascuno, riprendendo dal proprio cursore dopo un riavvio senza perdere né rielaborare lavoro
- Sviluppatore di app: un'app dello spazio di lavoro si iscrive a un canale e aggiorna la sua vista nell'istante in cui vengono pubblicati dati a monte, invece di fare polling a timer
- Autore di pipeline: lo stadio uno pubblica i risultati su un canale che lo stadio due consuma, con il replay disponibile per rielaborare lo storico dopo un cambio di logica
Domande frequenti
Cosa significa la consegna at-least-once per il mio codice?
Garantisce che un messaggio pubblicato raggiunga ogni subscriber anche attraverso disconnessioni e riavvii, ma un subscriber può occasionalmente ricevere lo stesso messaggio più di una volta. Rendi i tuoi handler idempotenti (deduplica su un id di messaggio o una chiave naturale) così che una ripetizione sia innocua invece di essere contata due volte.
Un subscriber nuovo o riavviato può recuperare i messaggi persi?
Sì. I canali conservano lo storico e ogni subscriber ha il proprio cursore, quindi un subscriber che si unisce tardi o torna dopo un riavvio può rieseguire i messaggi passati e riprendere dalla sua ultima posizione registrata, non solo vedere il traffico che arriva mentre è connesso.
Due subscriber sullo stesso canale condividono una posizione nello stream?
No. I cursori sono per singolo subscriber, quindi ogni lettore avanza in modo indipendente. Un subscriber può essere aggiornato al messaggio più recente mentre un altro sta ancora lavorando lo storico più vecchio dello stesso canale, e nessuno dei due influenza l'altro.