subscription-sync

Synchronize real-time backend and frontend data via WebSocket subscriptions.

15|3|Updated Apr 29, 2025
One-click install
npx skills add https://github.com/chaingraphlabs/chaingraph --skill subscription-sync
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: subscription-sync
Source: https://github.com/chaingraphlabs/chaingraph/tree/main/.claude/skills/subscription-sync
Command: npx skills add https://github.com/chaingraphlabs/chaingraph --skill subscription-sync

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill addresses the challenge of keeping frontend views synchronized with backend state in real-time, while avoiding race conditions and stale data during flow and execution event processing.

Core Features & Use Cases

  • Two-channel real-time syncing: Separate WebSocket-connected channels for flow editing and execution events to prevent backpressure and performance issues.
  • Event buffering & atomic flush: Buffer incoming flow events and flush atomically on FlowInitEnd to ensure nodes render before edges.
  • Dedicated subscriptions: Independent tRPC clients for editing and execution to isolate concerns and improve reliability.
  • Use Case: Implement live flow editing dashboards that reflect backend changes instantly and safely while execution traces stream concurrently.

Quick Start

Configure the frontend to connect to ws://localhost:3001 (main server) and ws://localhost:4021 (executor server), then subscribe to flow events and execution events as needed, ensuring FlowInitEnd flush is performed before rendering completed structures and starting execution.

Frequently Asked Questions about subscription-sync

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I synchronize real-time frontend-backend state via WebSocket without race conditions?

Real-time frontend-backend synchronization via WebSocket requires dual tRPC clients and event buffering to ensure atomic flush on FlowInitEnd, preventing race conditions and stale data during flow and execution event processing.

Why do I need separate WebSocket subscriptions for flow editing and execution events?

Separate WebSocket subscriptions for flow editing and execution events prevent backpressure and performance issues by isolating concerns, ensuring live flow editing dashboards reflect backend changes instantly while execution traces stream concurrently.

What is event buffering and atomic flush in real-time flow initialization?

Event buffering in real-time flow initialization stores incoming WebSocket flow events and flushes atomically on FlowInitEnd, ensuring nodes render completely before edges to maintain deterministic event delivery and visual consistency.

How to set up dual tRPC clients for frontend-backend subscriptions?

To set up dual tRPC clients for frontend-backend subscriptions, configure the frontend to connect to the main server and executor server via separate WebSocket connections, isolating flow editing and execution event streams for improved reliability.

Can I use a single tRPC client for both flow editing and execution event streaming?

Using a single tRPC client for both flow editing and execution event streaming is not recommended; dedicated subscriptions on independent clients isolate concerns, prevent backpressure, and ensure deterministic event delivery without performance degradation.

When should I flush buffered flow events before rendering a live dashboard?

You should flush buffered flow events when FlowInitEnd is received, ensuring nodes render before edges and execution starts, which guarantees atomic flow initialization and prevents incomplete visual structures in live dashboards.