stream-bridge-implementation

Implement runtime bridge patterns for data sources with xreg contract compliance.

36|7|Updated Jul 27, 2023
One-click install
npx skills add https://github.com/clemensv/real-time-sources --skill stream-bridge-implementation
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: stream-bridge-implementation
Source: https://github.com/clemensv/real-time-sources/tree/main/.github/skills/stream-bridge-implementation
Command: npx skills add https://github.com/clemensv/real-time-sources --skill stream-bridge-implementation

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Streamline and standardize the implementation of runtime bridges for data sources in this repository, ensuring contract compliance with xreg, correct emission of reference data, and robust handling of state, deduplication, and testing patterns.

Core Features & Use Cases

  • Provides a consistent bridge pattern for pollers, websockets or MQTT clients, and raw TCP decoders.
  • Ensures reference data is emitted at startup and refreshed periodically, with proper per-family producer wiring and isolated failure handling.
  • Includes guidance for testing, docker-based end-to-end checks, and alignment with the repo's runtime checklist.

Quick Start

Initialize a new bridge following the documented runtime patterns, implement per-family producers, and run the repo's Docker E2E tests to validate reference and telemetry flows.

Frequently Asked Questions about stream-bridge-implementation

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

FAQPage Schema
How do I implement a runtime bridge for polling data sources while ensuring xreg contract compliance?

A runtime bridge connects data sources to your system by applying a standardized pattern for pollers, websocket/MQTT clients, and raw TCP decoders, ensuring consistent producer wiring and proper state handling across different data source families.

How does a runtime bridge handle state and deduplication for websocket and MQTT clients?

The runtime bridge pattern handles state and deduplication by implementing isolated failure handling and per-family producer wiring. This ensures websocket and MQTT clients maintain data integrity without duplicating messages during transmission.

Do I need Docker to test runtime bridges and reference data emission?

Yes, Docker is required to validate runtime bridges. The implementation must pass repo-wide Docker end-to-end tests to confirm correct reference data emission and telemetry flow compatibility.

What is the best way to emit reference data at startup for a raw TCP decoder bridge?

The best way to emit reference data at startup is to follow the documented runtime bridge pattern, which broadcasts initial reference data upon connection and refreshes it periodically while maintaining proper state and dedupe handling for raw TCP decoders.

Can I use this bridge pattern for multiple data source families with isolated failure handling?

Yes, the bridge pattern supports multiple data source families including pollers, websockets, MQTT clients, and raw TCP decoders. It provides per-family producer wiring and isolated failure handling to prevent one source failure from affecting others.

Why is my runtime bridge not passing end-to-end tests for reference and telemetry flows?

Runtime bridges fail end-to-end tests when xreg contract compliance is missing, startup reference data emission is skipped, or state and dedupe handling is incorrect. Validate your per-family producer wiring against the repo's runtime checklist.