osFoundry / Platform
Canaux de données temps réel
Canaux pub/sub avec livraison au moins une fois, replay d'historique et curseurs par abonné.
Présentation
Les canaux de données temps réel forment l'épine dorsale de messagerie d'osFoundry pour faire circuler les événements entre les rouages de votre espace de travail. N'importe quel producteur (un agent, une app en cours d'exécution, un processus de code ou un chat) publie des messages sur un canal nommé, et chaque abonné à ce canal les reçoit. C'est le classique modèle publication/abonnement : producteurs et consommateurs sont découplés, vous pouvez donc ajouter ou retirer des abonnés sans toucher au code qui publie, et un seul événement peut se diffuser à de nombreux lecteurs à la fois.
La livraison est au moins une fois. Un message déjà publié atteindra chaque abonné même à travers les reconnexions et les redémarrages, au prix qu'un abonné puisse occasionnellement voir deux fois le même message ; les consommateurs doivent donc traiter leurs gestionnaires comme idempotents (clé de travail sur un id de message ou déduplication sur une clé naturelle). Les canaux conservent l'historique au lieu de jeter un message dès qu'il est lu, ce qui débloque deux choses : le replay, où un abonné peut relire les messages passés du canal au lieu de ne voir que ce qui arrive en direct, et les curseurs par abonné, où chaque abonné suit sa propre position de façon indépendante. Un curseur signifie qu'un abonné qui prend du retard, se déconnecte ou démarre plus tard reprend exactement là où il s'était arrêté, et deux abonnés d'un même canal peuvent se trouver à des points complètement différents du flux sans se gêner.
Parce qu'osFoundry est un espace de travail de bureau local-first et à clé apportée par vous (BYOK), ce plan de données tourne à côté de votre travail plutôt que de transiter par un courtier de messages tiers que vous devez provisionner et payer au siège. Les canaux sont la plomberie sous les fonctionnalités qui doivent réagir au changement au moment où il survient : un agent qui guette de nouveaux éléments à traiter, une app qui se met à jour dès que des données amont arrivent, ou un pipeline où une étape passe le relais à la suivante. Et ils laissent ces éléments communiquer sans polling ni couplage étroit, tandis que vos données peuvent rester sur votre appareil.
Fonctionnalités clés
- Les canaux pub/sub découplent producteurs et consommateurs, si bien qu'un événement publié se diffuse à chaque abonné sans modifier le code du publieur
- La livraison au moins une fois permet aux messages de survivre aux reconnexions et redémarrages ; concevez des consommateurs idempotents, car un message peut se répéter à l'occasion
- Le replay de l'historique laisse un abonné relire les messages passés au lieu de ne capter que le trafic en direct, utile pour les arrivées tardives et le retraitement
- Les curseurs par abonné suivent la position de chaque lecteur de façon indépendante, si bien qu'un abonné lent, redémarré ou tardif reprend exactement là où il s'était arrêté
- Relie agents, apps, code et chats sur un plan de données partagé et local-first, sans courtier externe à provisionner ni frais au siège
Cas d’usage
- Créateur d'agents : un agent s'abonne à un canal de tâches entrantes et traite chacune, reprenant depuis son curseur après un redémarrage sans perdre ni retraiter de travail
- Développeur d'apps : une app de l'espace de travail s'abonne à un canal et met à jour sa vue dès que des données amont sont publiées, au lieu de faire du polling sur minuterie
- Auteur de pipeline : l'étape un publie ses résultats sur un canal que l'étape deux consomme, avec replay disponible pour retraiter l'historique après un changement de logique
Questions fréquentes
Que signifie la livraison au moins une fois pour mon code ?
Elle garantit qu'un message publié atteint chaque abonné même à travers déconnexions et redémarrages, mais un abonné peut occasionnellement recevoir le même message plus d'une fois. Rendez vos gestionnaires idempotents (dédupliquez sur un id de message ou une clé naturelle) pour qu'une répétition soit sans effet plutôt que comptée deux fois.
Un abonné nouveau ou redémarré peut-il rattraper les messages qu'il a manqués ?
Oui. Les canaux conservent l'historique et chaque abonné a son propre curseur, donc un abonné qui arrive tard ou revient après un redémarrage peut rejouer les messages passés et reprendre à sa dernière position enregistrée, au lieu de ne voir que le trafic arrivant pendant sa connexion.
Deux abonnés d'un même canal partagent-ils une position dans le flux ?
Non. Les curseurs sont par abonné, donc chaque lecteur avance indépendamment. Un abonné peut être à jour sur le message le plus récent tandis qu'un autre travaille encore un historique plus ancien du même canal, sans que l'un affecte l'autre.