osFoundry / Platform
Canales de datos en tiempo real
Canales pub/sub con entrega al menos una vez, replay de historial y cursores por suscriptor.
Qué es
Los canales de datos en tiempo real son la columna vertebral de mensajería de osFoundry para mover eventos entre las piezas que componen tu espacio de trabajo. Cualquier productor (un agente, una app en ejecución, un proceso de código o un chat) publica mensajes en un canal con nombre, y todos los suscriptores de ese canal los reciben. Es el clásico modelo de publicación/suscripción: productores y consumidores están desacoplados, así que puedes añadir o quitar suscriptores sin tocar el código que publica, y un solo evento puede repartirse entre muchos lectores a la vez.
La entrega es al menos una vez. Un mensaje ya publicado llegará a cada suscriptor incluso tras reconexiones y reinicios, con la contrapartida de que un suscriptor puede ver de vez en cuando el mismo mensaje dos veces, por lo que los consumidores deben tratar sus manejadores como idempotentes (identifica el trabajo por un id de mensaje o deduplica por una clave natural). Los canales conservan el historial en lugar de descartar un mensaje en cuanto se lee, lo que habilita dos cosas: el replay, con el que un suscriptor puede releer mensajes pasados del canal en vez de ver solo lo que llega en vivo, y los cursores por suscriptor, con los que cada suscriptor lleva su propia posición de forma independiente. Un cursor significa que un suscriptor que se rezaga, se desconecta o arranca más tarde retoma justo donde lo dejó, y dos suscriptores del mismo canal pueden estar en puntos completamente distintos del flujo sin interferir entre sí.
Como osFoundry es un espacio de trabajo de escritorio local-first y con tu propia clave (BYOK), este plano de datos corre junto a tu trabajo en lugar de pasar por un broker de mensajes de terceros que tengas que aprovisionar y pagar por puesto. Los canales son la fontanería bajo las funciones que necesitan reaccionar al cambio en el momento en que ocurre: un agente que vigila nuevos elementos por procesar, una app que se actualiza en cuanto llegan datos aguas arriba, o un pipeline donde una etapa pasa el testigo a la siguiente. Y permiten que esas piezas se comuniquen sin polling ni acoplamiento estrecho, mientras tus datos pueden permanecer en tu dispositivo.
Capacidades principales
- Los canales pub/sub desacoplan a productores de consumidores, así que un evento publicado se reparte a cada suscriptor sin cambiar el código del publicador
- La entrega al menos una vez hace que los mensajes sobrevivan a reconexiones y reinicios; diseña consumidores idempotentes, porque un mensaje puede repetirse de vez en cuando
- El replay del historial deja que un suscriptor relea mensajes pasados en vez de captar solo el tráfico en vivo, útil para quienes se incorporan tarde y para reprocesar
- Los cursores por suscriptor siguen la posición de cada lector de forma independiente, así un suscriptor lento, reiniciado o tardío retoma justo donde lo dejó
- Conecta agentes, apps, código y chats sobre un plano de datos compartido y local-first, sin broker externo que aprovisionar ni tarifas por puesto
Casos de uso
- Creador de agentes: un agente se suscribe a un canal de tareas entrantes y procesa cada una, retomando desde su cursor tras un reinicio sin perder ni reprocesar trabajo
- Desarrollador de apps: una app del espacio de trabajo se suscribe a un canal y actualiza su vista en cuanto se publican datos aguas arriba, en vez de hacer polling por temporizador
- Autor de pipelines: la etapa uno publica resultados en un canal que consume la etapa dos, con replay disponible para reprocesar el historial tras un cambio de lógica
Preguntas frecuentes
¿Qué significa la entrega al menos una vez para mi código?
Garantiza que un mensaje publicado llegue a cada suscriptor incluso tras desconexiones y reinicios, pero un suscriptor puede recibir de vez en cuando el mismo mensaje más de una vez. Haz tus manejadores idempotentes (deduplica por un id de mensaje o una clave natural) para que una repetición sea inofensiva en lugar de contarse doble.
¿Puede un suscriptor nuevo o reiniciado ponerse al día con los mensajes que perdió?
Sí. Los canales retienen el historial y cada suscriptor tiene su propio cursor, así que un suscriptor que se incorpora tarde o vuelve tras un reinicio puede reproducir los mensajes pasados y retomar desde su última posición registrada, no solo ver el tráfico que llega mientras está conectado.
¿Dos suscriptores del mismo canal comparten una posición en el flujo?
No. Los cursores son por suscriptor, así que cada lector avanza de forma independiente. Un suscriptor puede estar al día con el mensaje más reciente mientras otro sigue trabajando el historial más antiguo del mismo canal, y ninguno afecta al otro.