osFoundry / Platform
Canais de dados em tempo real
Canais pub/sub com entrega pelo menos uma vez, replay de histórico e cursores por assinante.
O que é
Os canais de dados em tempo real são a espinha dorsal de mensageria do osFoundry para levar eventos entre as partes móveis do seu espaço de trabalho. Qualquer produtor (um agente, um app em execução, um processo de código ou um chat) publica mensagens em um canal nomeado, e todo assinante desse canal as recebe. É o clássico modelo de publicação/assinatura: produtores e consumidores ficam desacoplados, então você pode adicionar ou remover assinantes sem tocar no código que publica, e um único evento pode se espalhar para muitos leitores de uma vez.
A entrega é ao menos uma vez. Uma mensagem já publicada chegará a cada assinante mesmo através de reconexões e reinícios, com a contrapartida de que um assinante pode ocasionalmente ver a mesma mensagem duas vezes, então os consumidores devem tratar seus handlers como idempotentes (identifique o trabalho por um id de mensagem ou deduplique por uma chave natural). Os canais mantêm o histórico em vez de descartar uma mensagem assim que ela é lida, o que habilita duas coisas: o replay, em que um assinante pode reler mensagens passadas do canal em vez de ver apenas o que chega ao vivo, e os cursores por assinante, em que cada assinante acompanha a própria posição de forma independente. Um cursor significa que um assinante que fica para trás, se desconecta ou inicia mais tarde retoma exatamente de onde parou, e dois assinantes no mesmo canal podem estar em pontos totalmente diferentes do fluxo sem interferir um no outro.
Como o osFoundry é um espaço de trabalho de desktop local-first e com sua própria chave (BYOK), esse plano de dados roda ao lado do seu trabalho em vez de passar por um broker de mensagens de terceiros que você precise provisionar e pagar por assento. Os canais são o encanamento sob os recursos que precisam reagir à mudança no momento em que ela acontece: um agente que fica de olho em novos itens para processar, um app que se atualiza no instante em que dados a montante chegam, ou um pipeline em que um estágio passa o bastão ao seguinte. E eles deixam essas peças se comunicarem sem polling nem acoplamento forte, enquanto seus dados podem permanecer no seu dispositivo.
Principais recursos
- Canais pub/sub desacoplam produtores de consumidores, então um evento publicado se espalha para cada assinante sem alterar o código do publicador
- A entrega ao menos uma vez faz as mensagens sobreviverem a reconexões e reinícios; projete consumidores idempotentes, pois uma mensagem pode se repetir de vez em quando
- O replay de histórico deixa um assinante reler mensagens passadas em vez de captar só o tráfego ao vivo, útil para quem entra tarde e para reprocessamento
- Cursores por assinante acompanham a posição de cada leitor de forma independente, então um assinante lento, reiniciado ou atrasado retoma exatamente de onde parou
- Conecta agentes, apps, código e chats sobre um plano de dados compartilhado e local-first, sem broker externo para provisionar nem taxas por assento
Casos de uso
- Criador de agentes: um agente assina um canal de tarefas recebidas e processa cada uma, retomando do seu cursor após um reinício sem perder nem reprocessar trabalho
- Desenvolvedor de apps: um app do espaço de trabalho assina um canal e atualiza sua visão no instante em que dados a montante são publicados, em vez de fazer polling por temporizador
- Autor de pipelines: o estágio um publica resultados em um canal que o estágio dois consome, com replay disponível para reprocessar o histórico após uma mudança de lógica
Perguntas frequentes
O que a entrega ao menos uma vez significa para o meu código?
Ela garante que uma mensagem publicada chegue a cada assinante mesmo através de desconexões e reinícios, mas um assinante pode ocasionalmente receber a mesma mensagem mais de uma vez. Torne seus handlers idempotentes (deduplique por um id de mensagem ou uma chave natural) para que uma repetição seja inofensiva em vez de contada em dobro.
Um assinante novo ou reiniciado consegue recuperar as mensagens que perdeu?
Sim. Os canais retêm o histórico e cada assinante tem o próprio cursor, então um assinante que entra tarde ou volta após um reinício pode reproduzir mensagens passadas e retomar da última posição registrada, não apenas ver o tráfego que chega enquanto está conectado.
Dois assinantes no mesmo canal compartilham uma posição no fluxo?
Não. Os cursores são por assinante, então cada leitor avança de forma independente. Um assinante pode estar em dia com a mensagem mais recente enquanto outro ainda trabalha o histórico mais antigo do mesmo canal, e nenhum afeta o outro.