Subgraphs

The TEN framework uses a graph structure of interconnected nodes to define data flow between extensions. Subgraphs extend this architecture by providing a powerful reuse mechanism that allows you to break down complex graph structures into modular, reusable components.

Subgraphs improve code organization and maintainability by enabling you to create self-contained graph modules that can be shared across different applications or used multiple times within the same application. This modular approach simplifies the development of complex systems while maintaining the same runtime performance characteristics as regular graphs.

Understand the tech

Subgraphs preserve the fundamental principle of TEN graphs: defining how data flows between extensions. Rather than introducing new runtime complexity, subgraphs act as a development-time abstraction that gets flattened into the larger graph structure during deployment.

This design approach provides the organizational benefits of modularity while using the same graph execution mechanism that powers all TEN applications.

Design principles

Subgraphs are built on the following foundational principles that ensure they integrate seamlessly with the TEN framework while providing meaningful development benefits:

Independence: Every subgraph is a complete, self-contained graph that can run independently or be embedded as a component within larger graphs. This independence means you can develop, test, and validate subgraphs in isolation before integrating them into complex applications.
Tool-friendly design: Subgraphs provide structured metadata through exposed_messages and exposed_properties that development tools can use to offer intelligent suggestions, validation, and debugging capabilities. This enhanced tooling support improves the development experience without adding runtime overhead.
Flattening mechanism: At deployment time, subgraphs are flattened into standard graph structures, ensuring that runtime performance remains identical to regular graphs. This approach provides development-time modularity benefits while maintaining the proven performance characteristics of the core TEN graph engine.
Simplicity: Subgraph design prioritizes simplicity. Rather than providing patching mechanisms or complex configuration options at reference points, subgraphs use straightforward mapping and exposure patterns. If a subgraph needs modification, you modify the original definition directly, avoiding complexity cascades and maintenance overhead.

This design approach allows you to treat subgraphs as black boxes. You can use them without understanding their internal complexity, while the framework handles the technical details of integration and execution.

Key features

Subgraphs provide four essential features that enable modular graph development and seamless integration within TEN applications:

Message exposure: Subgraphs declare their external interfaces through the exposed_messages field, specifying which message types (commands, data, audio, video) can be sent to or received from the subgraph. This exposure mechanism allows development tools to provide intelligent autocomplete and validation while hiding internal implementation details from external consumers.
Property exposure: Through the exposed_properties field, subgraphs can selectively expose internal extension properties to external configuration. This controlled exposure enables customization of subgraph behavior without revealing the entire internal structure, maintaining encapsulation while providing necessary flexibility.
Namespace management: Each referenced subgraph creates its own namespace, preventing naming conflicts between elements in different subgraphs. When you reference a subgraph with name subgraph_1, all internal elements become accessible through the namespace syntax (e.g., subgraph_1:ext_name), ensuring global uniqueness across complex graph hierarchies.
Cross-graph connections: Subgraphs enable sophisticated connection patterns that span multiple graph boundaries. You can connect directly to subgraph interfaces, connect to specific elements within subgraphs, or even establish connections between elements in different subgraphs. This flexibility supports complex data flow architectures while maintaining clear organizational boundaries.

These features work together to provide a powerful abstraction layer that simplifies complex graph development without sacrificing the flexibility and performance that TEN applications require.

Creating subgraphs

Subgraph definition

A subgraph is defined in a standard JSON file that contains the same basic structure as any TEN graph, with additional metadata for external interfaces. Here's a basic example:

{
 "nodes": [
   {
     "type": "extension",
     "name": "audio_processor",
     "addon": "audio_enhancement"
   },
   {
     "type": "extension", 
     "name": "audio_filter",
     "addon": "noise_reduction"
   }
 ],
 "connections": [
   {
     "extension": "audio_processor",
     "audio_frame": [
       {
         "name": "processed_audio",
         "dest": [
           {
             "extension": "audio_filter"
           }
         ]
       }
     ]
   }
 ],
 "exposed_messages": [
   {
     "extension": "audio_processor",
     "type": "audio_frame_in",
     "name": "raw_audio"
   },
   {
     "extension": "audio_filter", 
     "type": "audio_frame_out",
     "name": "clean_audio"
   }
 ],
 "exposed_properties": [
   {
     "extension": "audio_processor",
     "name": "sample_rate",
     "alias": "input_sample_rate"
   },
   {
     "extension": "audio_filter",
     "name": "noise_threshold", 
     "alias": "filter_sensitivity"
   }
 ]
}

Following is the structure breakdown:

Nodes section: Defines the extensions that make up the subgraph, just like in a regular graph. Each extension specifies its type, name, and addon identifier.
Connections section: Establishes data flow between extensions within the subgraph. These internal connections define how the subgraph processes data internally.
Exposed messages section: Declares which message interfaces are available for external connections. This acts as the subgraph's public API, allowing other graphs to send data to or receive data from the subgraph without knowing its internal structure.
Exposed properties section: Specifies which extension properties can be configured externally. The alias field provides user-friendly names for external configuration, abstracting away internal implementation details.

This sample subgraph can function as a standalone audio processing pipeline or be embedded within larger applications that need audio enhancement capabilities.

Exposed interfaces

Subgraphs use two interface types to control what external graphs can access and configure. These interfaces act as the subgraph's public API, providing controlled access while maintaining internal encapsulation.

exposed_messages

The exposed_messages field defines which message interfaces are available for external connections. This allows other graphs to interact with your subgraph without needing to understand its internal structure.

Message exposure structure:

{
 "exposed_messages": [
   {
     "extension": "internal_extension_name",
     "type": "message_direction_and_type", 
     "name": "message_name"
   }
 ]
}

Message types:

cmd_in / cmd_out: Command messages for control and responses
data_in / data_out: General data messages
audio_frame_in / audio_frame_out: Audio stream data
video_frame_in / video_frame_out: Video stream data

Example:

{
 "exposed_messages": [
   {
     "extension": "speech_recognizer",
     "type": "audio_frame_in",
     "name": "audio_input"
   },
   {
     "extension": "text_processor", 
     "type": "data_out",
     "name": "transcribed_text"
   },
   {
     "extension": "speech_recognizer",
     "type": "cmd_in", 
     "name": "configure_language"
   }
 ]
}

This example exposes an audio input, text output, and configuration command, allowing external graphs to send audio data and receive transcribed text while configuring the recognition language.

exposed_properties

The exposed_properties field specifies which internal extension properties can be configured from outside the subgraph. This enables customization without exposing the entire internal configuration.

Property exposure structure:

{
 "exposed_properties": [
   {
     "extension": "internal_extension_name",
     "name": "internal_property_name",
     "alias": "external_property_name"
   }
 ]
}

extension: The internal extension that owns the property
name: The actual property name within the extension
alias: The external name used when referencing the subgraph (optional)

Example:

{
 "exposed_properties": [
   {
     "extension": "video_encoder",
     "name": "bitrate_kbps", 
     "alias": "output_quality"
   },
   {
     "extension": "frame_buffer",
     "name": "max_buffer_size",
     "alias": "buffer_limit"
   },
   {
     "extension": "video_encoder", 
     "name": "codec_type"
   }
 ]
}

In this example, external graphs can configure video quality through the output_quality alias, set buffer limits through buffer_limit, and specify codec type directly. The aliases provide user-friendly names while hiding implementation details. Exposed interfaces provide the following benefits:

Encapsulation: Hide internal complexity while providing clean external APIs
Selective exposure: Allow control over which interfaces and properties can be accessed externally
Interface documentation: Serve as documentation for subgraph capabilities

Using subgraphs

Referencing subgraphs

To use a subgraph in your main graph, reference it as a node with type subgraph. The subgraph becomes part of your graph's namespace and can be connected like any other component.

Basic subgraph reference:

{
 "nodes": [
   {
     "type": "extension",
     "name": "input_source",
     "addon": "audio_input"
   },
   {
     "type": "extension", 
     "name": "output_sink",
     "addon": "audio_output"
   },
   {
     "type": "subgraph",
     "name": "audio_pipeline",
     "source_uri": "./ten_packages/extension/audio_processing/subgraph.json"
   }
 ],
 "connections": [
   {
     "extension": "input_source",
     "audio_frame": [
       {
         "name": "raw_audio",
         "dest": [
           {
             "subgraph": "audio_pipeline"
           }
         ]
       }
     ]
   },
   {
     "subgraph": "audio_pipeline", 
     "audio_frame": [
       {
         "name": "processed_audio",
         "dest": [
           {
             "extension": "output_sink"
           }
         ]
       }
     ]
   }
 ]
}

Subgraph with properties: You can configure exposed properties when referencing a subgraph:

{
 "type": "subgraph",
 "name": "video_processor",
 "source_uri": "./subgraphs/video_enhancement.json",
 "property": {
   "output_quality": "high",
   "buffer_limit": 1024,
   "codec_type": "h264"
 }
}

The properties you specify must exist in the subgraph's exposed_properties field, otherwise the configuration is rejected.

Connection patterns

Subgraphs support multiple connection patterns that provide flexibility in how you route data between components.

Direct connections to subgraphs

Connect directly to a subgraph using its name when the subgraph exposes the appropriate message interface:

{
 "connections": [
   {
     "extension": "data_source",
     "cmd": [
       {
         "name": "process_data",
         "dest": [
           {
             "subgraph": "data_processor"
           }
         ]
       }
     ]
   }
 ]
}

This pattern works when data_processor exposes a cmd_in interface for process_data. The connection is clean and hides the subgraph's internal structure.

Connections to elements within subgraphs

For more granular control, connect directly to specific extensions within a subgraph using namespace syntax:

{
 "connections": [
   {
     "extension": "external_source",
     "data": [
       {
         "name": "raw_input", 
         "dest": [
           {
             "extension": "video_pipeline:frame_buffer"
           }
         ]
       }
     ]
   },
   {
     "extension": "video_pipeline:encoder",
     "video_frame": [
       {
         "name": "encoded_output",
         "dest": [
           {
             "extension": "external_sink"
           }
         ]
       }
     ]
   }
 ]
}

The subgraph_name:extension_name syntax allows you to bypass the subgraph's exposed interfaces and connect directly to internal elements. Use this pattern when you need fine-grained control over data flow.

Advanced connection syntax

You can mix different connection patterns within the same graph to create sophisticated data flow architectures:

{
 "connections": [
   {
     "extension": "input_hub",
     "data": [
       {
         "name": "sensor_data",
         "dest": [
           {
             "subgraph": "processing_pipeline"
           },
           {
             "extension": "backup_pipeline:data_logger"
           },
           {
             "extension": "monitoring_extension"
           }
         ]
       }
     ]
   },
   {
     "subgraph": "processing_pipeline",
     "cmd": [
       {
         "name": "status_update", 
         "dest": [
           {
             "extension": "monitoring_extension"
           },
           {
             "subgraph": "alert_system"
           }
         ]
       }
     ]
   }
 ]
}

Connection pattern guidelines:

Use direct subgraph connections when working with well-defined interfaces
Use namespace syntax when you need to access specific internal functionality
Mix patterns when building complex data flow architectures
Prefer exposed interfaces for maintainability and clarity

These patterns give you the flexibility to build everything from simple linear pipelines to complex multi-path processing architectures while maintaining clear organizational boundaries.

Flattening process

How flattening works

Before your application runs, the TEN framework automatically flattens all subgraph references into a single, standard graph structure. This flattening process converts the modular development structure into the standard graph format that the TEN runtime executes.

Flattening transformations:

Namespace resolution: Subgraph references are resolved and internal elements are prefixed with the subgraph name to ensure global uniqueness.
Node expansion: Subgraph nodes are replaced with their constituent extension nodes, maintaining all original properties and configurations.
Connection mapping: References using namespace syntax (subgraph:extension) are converted to direct extension names, and subgraph-level connections are mapped to specific internal extensions.
Property inheritance: Properties specified when referencing a subgraph are applied to the appropriate internal extensions based on the exposed_properties mapping.
Interface removal: The exposed_messages and exposed_properties metadata is removed since it's only needed during graph composition.

Naming convention:
The colon (:) is replaced with an underscore (_) to create valid extension names in the flattened structure.

Original: subgraph_name:extension_name
Flattened: subgraph_name_extension_name

Flattened graph example

Following is a complete example that shows how a graph with subgraphs transforms during the flattening process:

Before flattening:

{
 "nodes": [
   {
     "type": "extension",
     "name": "input_source",
     "addon": "microphone_input"
   },
   {
     "type": "extension", 
     "name": "output_sink",
     "addon": "speaker_output"
   },
   {
     "type": "subgraph",
     "name": "audio_pipeline",
     "source_uri": "./subgraphs/audio_processing.json",
     "property": {
       "sample_rate": 48000,
       "noise_threshold": 0.3
     }
   },
   {
     "type": "subgraph",
     "name": "effects_chain", 
     "source_uri": "./subgraphs/audio_effects.json"
   }
 ],
 "connections": [
   {
     "extension": "input_source",
     "audio_frame": [
       {
         "name": "raw_audio",
         "dest": [
           {
             "subgraph": "audio_pipeline"
           }
         ]
       }
     ]
   },
   {
     "extension": "audio_pipeline:processor",
     "audio_frame": [
       {
         "name": "clean_audio", 
         "dest": [
           {
             "extension": "effects_chain:reverb"
           }
         ]
       }
     ]
   },
   {
     "subgraph": "effects_chain",
     "audio_frame": [
       {
         "name": "final_audio",
         "dest": [
           {
             "extension": "output_sink"
           }
         ]
       }
     ]
   }
 ]
}

After flattening:

{
 "nodes": [
   {
     "type": "extension",
     "name": "input_source", 
     "addon": "microphone_input"
   },
   {
     "type": "extension",
     "name": "output_sink",
     "addon": "speaker_output"
   },
   {
     "type": "extension",
     "name": "audio_pipeline_enhancer",
     "addon": "audio_enhancement", 
     "property": {
       "sample_rate": 48000
     }
   },
   {
     "type": "extension",
     "name": "audio_pipeline_processor",
     "addon": "noise_reduction",
     "property": {
       "noise_threshold": 0.3
     }
   },
   {
     "type": "extension", 
     "name": "effects_chain_reverb",
     "addon": "reverb_effect"
   },
   {
     "type": "extension",
     "name": "effects_chain_compressor", 
     "addon": "dynamic_compressor"
   }
 ],
 "connections": [
   {
     "extension": "input_source",
     "audio_frame": [
       {
         "name": "raw_audio",
         "dest": [
           {
             "extension": "audio_pipeline_enhancer"
           }
         ]
       }
     ]
   },
   {
     "extension": "audio_pipeline_enhancer",
     "audio_frame": [
       {
         "name": "enhanced_audio",
         "dest": [
           {
             "extension": "audio_pipeline_processor"
           }
         ]
       }
     ]
   },
   {
     "extension": "audio_pipeline_processor", 
     "audio_frame": [
       {
         "name": "clean_audio",
         "dest": [
           {
             "extension": "effects_chain_reverb"
           }
         ]
       }
     ]
   },
   {
     "extension": "effects_chain_reverb",
     "audio_frame": [
       {
         "name": "reverb_audio",
         "dest": [
           {
             "extension": "effects_chain_compressor"
           }
         ]
       }
     ]
   },
   {
     "extension": "effects_chain_compressor",
     "audio_frame": [
       {
         "name": "final_audio", 
         "dest": [
           {
             "extension": "output_sink"
           }
         ]
       }
     ]
   }
 ]
}

Key changes during flattening:

Subgraph nodes removed: audio_pipeline and effects_chain subgraph nodes are replaced with their constituent extensions
Names prefixed: Internal extensions get prefixed names (audio_pipeline_processor, effects_chain_reverb)
Properties distributed: Subgraph properties are applied to the correct internal extensions
Connections resolved: All namespace references and subgraph connections are converted to direct extension connections
Internal connections preserved: Connections that existed within the original subgraphs are included in the flattened result

The flattened graph contains only standard extensions and direct connections, maintaining the organizational benefits you gained during development while using the standard TEN graph execution model.

Advanced features

Message conversion with subgraphs

Subgraphs support the TEN framework's message conversion mechanism, allowing you to transform message formats when routing data between components.

Message conversion syntax: You can apply message conversion rules when connecting to subgraphs, internal subgraph elements, or when subgraphs connect to external components:

{
 "connections": [
   {
     "extension": "data_source",
     "cmd": [
       {
         "name": "user_request",
         "dest": [
           {
             "subgraph": "ai_processor",
             "msg_conversion": {
               "type": "per_property",
               "rules": [
                 {
                   "path": "request_type",
                   "conversion_mode": "fixed_value",
                   "value": "chat_completion"
                 },
                 {
                   "path": "model_config.temperature",
                   "conversion_mode": "from_original",
                   "original_path": "settings.creativity"
                 }
               ],
               "keep_original": true
             }
           },
           {
             "extension": "nlp_pipeline:tokenizer",
             "msg_conversion": {
               "type": "per_property", 
               "rules": [
                 {
                   "path": "input_text",
                   "conversion_mode": "from_original",
                   "original_path": "user_message"
                 }
               ],
               "keep_original": false
             }
           }
         ]
       }
     ]
   }
 ]
}

Conversion during flattening: Message conversion rules are preserved during the flattening process, ensuring that your data transformations work correctly at runtime:

{
 "connections": [
   {
     "extension": "data_source",
     "cmd": [
       {
         "name": "user_request",
         "dest": [
           {
             "extension": "ai_processor_chat_handler",
             "msg_conversion": {
               "type": "per_property",
               "rules": [
                 {
                   "path": "request_type", 
                   "conversion_mode": "fixed_value",
                   "value": "chat_completion"
                 }
               ],
               "keep_original": true
             }
           },
           {
             "extension": "nlp_pipeline_tokenizer",
             "msg_conversion": {
               "type": "per_property",
               "rules": [
                 {
                   "path": "input_text",
                   "conversion_mode": "from_original", 
                   "original_path": "user_message"
                 }
               ],
               "keep_original": false
             }
           }
         ]
       }
     ]
   }
 ]
}

Multi-graph connections

Beyond subgraphs, TEN supports connections between separate graphs running in the same application or across different applications. This enables sophisticated distributed architectures.

Connecting to predefined graphs

You can reference and connect to other predefined graphs within the same TEN application:

{
 "nodes": [
   {
     "type": "extension",
     "name": "local_processor",
     "addon": "data_processor"
   },
   {
     "type": "graph",
     "graph_name": "analytics_pipeline",
     "singleton": true
   },
   {
     "type": "graph", 
     "graph_name": "monitoring_system",
     "singleton": false
   }
 ],
 "connections": [
   {
     "extension": "local_processor",
     "data": [
       {
         "name": "processed_data",
         "dest": [
           {
             "extension": "analytics_pipeline:data_ingester"
           },
           {
             "graph": "monitoring_system"
           }
         ]
       }
     ]
   },
   {
     "graph": "analytics_pipeline", 
     "cmd": [
       {
         "name": "analysis_complete",
         "dest": [
           {
             "extension": "local_processor"
           }
         ]
       }
     ]
   }
 ]
}

Remote graph connections

Connect to graphs running in different TEN applications across the network:

{
 "nodes": [
   {
     "type": "extension",
     "name": "local_service",
     "addon": "api_handler"
   },
   {
     "type": "graph",
     "graph_name": "ml_inference",
     "singleton": true,
     "app": "msgpack://ml-server.example.com:8002/"
   },
   {
     "type": "graph",
     "graph_name": "data_warehouse", 
     "singleton": false,
     "app": "msgpack://data-cluster.example.com:8003/"
   }
 ],
 "connections": [
   {
     "extension": "local_service",
     "cmd": [
       {
         "name": "inference_request",
         "dest": [
           {
             "graph": "ml_inference"
           }
         ]
       }
     ]
   },
   {
     "graph": "ml_inference",
     "data": [
       {
         "name": "inference_result",
         "dest": [
           {
             "extension": "local_service"
           },
           {
             "graph": "data_warehouse"
           }
         ]
       }
     ]
   }
 ]
}

Graph node types

TEN supports three types of graph nodes for different connection scenarios:

Subgraph nodes:

{
 "type": "subgraph",
 "name": "processing_module",
 "source_uri": "./subgraphs/data_processing.json",
 "property": {
   "batch_size": 100
 }
}

Local graph nodes:

{
 "type": "graph", 
 "graph_name": "background_service",
 "singleton": true
}

{
 "type": "graph",
 "graph_name": "worker_pool", 
 "singleton": false
}

Remote graph nodes:

{
 "type": "graph",
 "graph_name": "external_api",
 "singleton": true,
 "app": "msgpack://api.service.com:8001/"
}

{
 "type": "graph",
 "graph_name": "distributed_cache",
 "singleton": false, 
 "app": "msgpack://cache-cluster.internal:8004/"
}

Graph node properties:

graph_name: Identifies the target graph within its application
singleton: Controls whether multiple instances can exist (true = single instance, false = multiple instances allowed)
app: Specifies the target application URL for remote connections (omit for local graphs)

These advanced features enable you to build sophisticated distributed systems where subgraphs, local graphs, and remote services work together seamlessly while maintaining clear architectural boundaries.

{
 "type": "subgraph",
 "name": "unique_subgraph_name",
 "source_uri": "path/to/subgraph.json"
}

Subgraph node with properties:

{
 "type": "subgraph", 
 "name": "configurable_module",
 "source_uri": "./ten_packages/extension/module/subgraph.json",
 "property": {
   "param1": "value1",
   "param2": 42,
   "nested_config": {
     "enabled": true,
     "threshold": 0.85
   }
 }
}

Remote subgraph node:

{
 "type": "subgraph",
 "name": "shared_component", 
 "source_uri": "https://cdn.example.com/subgraphs/v1.2/nlp_pipeline.json"
}

Required fields:

type: Must be "subgraph"
name: Unique identifier within the current graph (serves as namespace)
source_uri: Path or URL to the subgraph definition file

Optional fields:

property: Configuration values for exposed properties

Local graph nodes

Reference other predefined graphs within the same TEN application:

Singleton local graph:

{
 "type": "graph",
 "graph_name": "predefined_graph_id",
 "singleton": true
}

Multi-instance local graph:

{
 "type": "graph",
 "graph_name": "worker_template",
 "singleton": false
}

Required fields:

type: Must be "graph"
graph_name: Identifier of the predefined graph in the same application
singleton: Boolean controlling instance multiplicity

Singleton behavior:

true: Only one instance of the graph exists, shared across references
false: Each reference creates a separate graph instance

Remote graph nodes

Reference graphs running in different TEN applications across the network:

Singleton remote graph:

{
 "type": "graph",
 "graph_name": "ml_service",
 "singleton": true,
 "app": "msgpack://ml-cluster.internal:8002/"
}

Multi-instance remote graph:

{
 "type": "graph",
 "graph_name": "data_processor",
 "singleton": false, 
 "app": "msgpack://processing-farm.example.com:8003/"
}

Required fields:

type: Must be "graph"
graph_name: Identifier of the target graph in the remote application
singleton: Boolean controlling instance behavior
app: Network address of the target TEN application

Supported protocols:

msgpack://host:port/: MessagePack-based communication
Additional protocols may be supported in future versions

Connection syntax reference

TEN provides flexible syntax for establishing connections between different types of graph nodes and their internal elements.

subgraph_name:element_name

Access specific elements within subgraphs using namespace syntax:

Extension within subgraph:

{
 "extension": "audio_pipeline:noise_filter",
 "audio_frame": [
   {
     "name": "filtered_audio",
     "dest": [
       {
         "extension": "output_device"
       }
     ]
   }
 ]
}

Connecting to subgraph element:

{
 "extension": "microphone",
 "audio_frame": [
   {
     "name": "raw_audio",
     "dest": [
       {
         "extension": "processing_chain:input_buffer"
       }
     ]
   }
 ]
}

Syntax rules:

Format: subgraph_name:extension_name
The colon (:) separates namespace from element name
Element name must exist within the referenced subgraph
Bypasses subgraph's exposed interface constraints

Graph references

Connect to graphs using their identifiers:

Direct graph connection:

{
 "subgraph": "local_processor",
 "cmd": [
   {
     "name": "process_complete",
     "dest": [
       {
         "graph": "analytics_engine"
       }
     ]
   }
 ]
}

Graph element connection:

{
 "graph": "background_service",
 "data": [
   {
     "name": "status_update", 
     "dest": [
       {
         "extension": "monitor:logger"
       }
     ]
   }
 ]
}

Local graph with namespace:

{
 "extension": "coordinator",
 "cmd": [
   {
     "name": "task_assignment",
     "dest": [
       {
         "extension": "worker_pool:task_manager"
       }
     ]
   }
 ]
}

Advanced patterns

Combine multiple connection types for sophisticated data flow architectures:

Multi-destination routing:

{
 "extension": "data_ingester", 
 "data": [
   {
     "name": "incoming_data",
     "dest": [
       {
         "subgraph": "validation_pipeline"
       },
       {
         "extension": "processing_farm:load_balancer"
       },
       {
         "graph": "audit_logger"
       },
       {
         "extension": "backup_storage"
       }
     ]
   }
 ]
}

Cross-application message flow:

{
 "graph": "local_analytics",
 "cmd": [
   {
     "name": "analysis_request", 
     "dest": [
       {
         "extension": "ml_cluster:inference_engine"
       }
     ]
   }
 ]
}

Conditional routing with message conversion:

{
 "extension": "request_router",
 "cmd": [
   {
     "name": "user_request",
     "dest": [
       {
         "subgraph": "fast_processing",
         "msg_conversion": {
           "type": "per_property",
           "rules": [
             {
               "path": "priority",
               "conversion_mode": "fixed_value", 
               "value": "high"
             }
           ]
         }
       },
       {
         "extension": "slow_processing:queue_manager",
         "msg_conversion": {
           "type": "per_property",
           "rules": [
             {
               "path": "priority",
               "conversion_mode": "fixed_value",
               "value": "normal"
             }
           ]
         }
       }
     ]
   }
 ]
}

Connection target types:

extension: Direct extension name
subgraph: Subgraph name (uses exposed interfaces)
graph: Graph name (uses exposed interfaces)
extension with namespace: namespace:extension_name

Best practices:

Use exposed interfaces when possible for better encapsulation
Use namespace syntax only when you need direct access to internal elements
Prefer subgraphs over direct graph references for reusable components
Document complex connection patterns for maintainability

Was this helpful?