Nodes

What this page covers

This page explains how to define nodes in DiagramFlow. It covers the main node patterns you will use when building system design and cloud architecture diagrams.

Mental model

Nodes are the things in the diagram. They represent services, databases, queues, workers, storage systems, and other architecture elements.

Most non-trivial diagrams start by creating named nodes, then connecting or grouping them. That is why assigned node variables are the most important pattern to learn first.

Basic syntax

The most common node pattern is assignment:


source = EKS("source")
queue = SQS("queue")

source -> queue

In this example:

EKS and SQS are node constructors.
"source" and "queue" are the labels shown in the diagram.
source and queue are variables you can reuse later in connections.

Attributes and options

Assigned nodes

Use variable assignment when the node needs to be connected, reused, or referenced later:


api = EKS("api")
eventsQueue = SQS("events queue")

This is the default pattern for most production diagrams.

Bare nodes

DiagramFlow also supports bare nodes inside a container such as a cluster:


cluster("Bare Nodes") {
    ECS("worker-a")
    ECS("worker-b")
}

Bare nodes are useful when you want to show a group visually but do not need to reference each node later.

Labels with spaces

Node labels can contain spaces:


source = EKS("k8s source cluster")
queue = SQS("primary event queue")

The label is the human-readable text in the diagram. The variable name stays short and code-friendly.

Common patterns

Top-level node and in-cluster node

Nodes can appear at the top level or inside a cluster:


source = EKS("source")

cluster("Processing") {
    handler = Lambda("handler")
}

source -> handler

This is a common pattern when one service communicates with a grouped subsystem.

Multi-provider diagrams

DiagramFlow is built for cloud architecture work, so a single diagram can mix providers:


awsNode = EKS("aws compute")
azureNode = AIStudio("azure ai")
gcpNode = Bigquery("gcp warehouse")
onpremNode = Fluentd("onprem collector")

awsNode -> azureNode -> gcpNode -> onpremNode

This is useful for multi-cloud systems, migration diagrams, and hybrid infrastructure docs.

Reuse node variables across connections

As diagrams grow, reuse variables instead of repeating concepts in new nodes:


source = EKS("source")
queue = SQS("queue")
handler = Lambda("handler")
store = S3("store")

source -> queue
queue -> handler
handler -> store

This makes the flow explicit and keeps the source readable.

Recommended usage

Use assigned nodes by default for anything that participates in one or more connections.
Use short variable names and clear labels. For example, prefer queue = SQS("orders queue") over long variable names.
Use bare nodes only when you do not need to reference the node later.
Reuse the same variable whenever the same architecture element appears in multiple connections.
Mix providers when the architecture really is multi-cloud or hybrid, not just to show variety.

Common mistakes

Creating bare nodes when the same element needs to be referenced later in a connection.
Using long variable names and vague labels at the same time, which makes the source hard to scan.
Recreating the same node multiple times instead of reusing one assigned variable.