Skip to main content

​
Topics

Topics are named, typed data channels that connect nodes together. Think of them as pipes that carry data from one node’s output to another node’s input. Topics ensure type safety—only compatible data types can flow through a connection.

​
What is a Topic?

A topic is a communication channel that:
  • Carries data from an output port to an input port
  • Has a name that identifies it (e.g., temperature_readings, sensor_data)
  • Has a type defined by a schema (e.g., TemperatureReading, SensorData)
  • Ensures type safety by preventing incompatible connections
Think of topics as labeled pipes in a plumbing system. Each pipe (topic) has a label (name) and carries a specific type of fluid (data). You can’t connect a water pipe to a gas line—similarly, you can’t connect incompatible data types.
Topics are similar to message queues or channels in other systems, but they’re automatically created when you connect nodes and are strongly typed for safety.

​
Why Use Topics?

Type Safety

Topics enforce type compatibility at connection time, preventing runtime errors from mismatched data types.

Automatic Creation

Topics are created automatically when you connect nodes. No manual setup required.

Named Channels

Each topic has a meaningful name, making it easy to understand data flow in your graph.

Decoupling

Nodes don’t need to know about each other—they only know about the topics they publish to or subscribe from.

​
How Topics Work

When you connect two nodes:
  1. Connection is made - You drag from an output port to an input port
  2. Topic is created - A topic is automatically created with a default name
  3. Type is validated - The editor ensures output and input types are compatible
  4. Data flows - When the source node sends data, it flows through the topic to the destination node

​
Topic Naming

Topics are automatically named based on the port names:
  • Default: If you connect temperature_out to temperature_in, the topic is named temperature
  • Custom: You can rename topics in the properties panel
  • Uniqueness: Topic names must be unique within a graph
Use descriptive topic names that indicate what data they carry. “temperature_readings” is better than “topic1”.

​
Topic Types

Topics are strongly typed—they can only carry data of a specific schema type:

​
Compatible Types

  • Exact match: Output type exactly matches input type
  • Compatible schemas: Types with the same structure (same fields, same types)

​
Incompatible Types

  • Different schemas: Types with different structures
  • Different field types: Same field names but different types (e.g., float vs int)
The editor will prevent you from connecting incompatible types. If you see a connection error, check that your schemas match.

​
Topic Lifecycle

Topics are created and managed automatically:
  1. Creation - When you connect nodes, a topic is created
  2. Active - Topic is active while nodes are connected
  3. Data Flow - Data flows through the topic when source node publishes
  4. Cleanup - Topic is removed when connection is deleted
Topics are lightweight—they don’t consume resources until data is actually flowing through them. The framework manages topic lifecycle automatically.

​
Topic Transport

Topics can use different transport mechanisms depending on where nodes are running:

​
Local Transport

When both nodes run on the same machine:
  • Uses shared memory (iceoryx2) for zero-copy communication
  • Sub-microsecond latency for small messages
  • No serialization overhead

​
Network Transport

When nodes run on different machines:
  • Uses Zenoh for network communication
  • Async publishing doesn’t block local operations
  • Latest-message semantics - only the most recent message is queued
The framework automatically selects the appropriate transport based on node locations. You don’t need to configure this manually.

​
Topic Properties

Each topic has configurable properties:
  • Name - The topic identifier
  • Type - The schema type (read-only, determined by connection)
  • Transport - Local or network (auto-selected)
  • QoS Settings - Quality of service configuration (optional)

​
Quality of Service (QoS)

QoS settings control how messages are delivered:
  • Reliability - Best effort vs reliable delivery
  • Durability - Volatile vs transient vs persistent
  • History - Keep last N messages vs keep all
Most use cases work fine with default QoS settings. Only configure QoS if you have specific reliability requirements.

​
Multiple Subscribers

A single topic can have multiple subscribers: 
Publisher → Topic → Subscriber 1
                  → Subscriber 2
                  → Subscriber 3
When the publisher sends data, all subscribers receive it. This is called fan-out—one publisher, many subscribers.
Each subscriber gets its own copy of the data. Modifying data in one subscriber doesn’t affect others.

​
Multiple Publishers

A single topic can have multiple publishers (with caution): 
Publisher 1 → Topic → Subscriber
Publisher 2 → Topic → Subscriber
Publisher 3 → Topic → Subscriber
When multiple publishers send to the same topic, the subscriber receives messages from all of them. This is called fan-in—many publishers, one subscriber.
Multiple publishers to one topic can cause race conditions. Use this pattern carefully, or use a join node to merge data properly.

​
Topic Best Practices

Descriptive Names

Use clear, descriptive topic names. “temperature_readings” is better than “data” or “topic1”.

One Purpose

Each topic should carry one type of data. Don’t reuse topics for different data types.

Schema First

Define schemas before creating topics. This ensures type safety from the start.

Avoid Deep Nesting

Keep topic hierarchies shallow. Deep nesting makes graphs hard to understand.

​
Common Patterns

​
Publisher-Subscriber Pattern

One publisher, one subscriber: 
Publisher → Topic → Subscriber
Use when: Simple data flow from source to sink.

​
Fan-Out Pattern

One publisher, many subscribers: 
Publisher → Topic → Subscriber 1
                  → Subscriber 2
                  → Subscriber 3
Use when: Broadcasting data to multiple consumers.

​
Fan-In Pattern

Many publishers, one subscriber: 
Publisher 1 → Topic → Subscriber
Publisher 2 → Topic → Subscriber
Publisher 3 → Topic → Subscriber
Use when: Collecting data from multiple sources (use with caution).

​
Next Steps

Now that you understand topics, learn about related concepts:

Schemas

Learn how to define the structure of data that flows through topics.

Ports and Links

Understand how ports and links create topics automatically.

Nodes

Learn about nodes that publish to and subscribe from topics.

Examples

See examples of topic patterns in action.