Connections
What this page covers
This page explains how to connect nodes in DiagramFlow. It covers direction, undirected links, edge attributes, chained expressions, and multi-line flow patterns.
Mental model
Connections describe relationships between nodes. In a cloud architecture diagram, that usually means traffic flow, data flow, event flow, or a logical dependency between services.
Start with the simplest possible edge, then add labels or styling only when they improve understanding.
Basic syntax
The simplest connection is a directed edge:
a = EKS("a")
b = SQS("b")
a -> bAttributes and options
Directed right: a -> b
Use -> when the flow goes from left to right in the expression:
a = EKS("a")
b = SQS("b")
a -> bDirected left: a <- b
Use <- when you want to express the relationship in the opposite direction:
a = EKS("a")
b = SQS("b")
a <- bUndirected: a - b
Use - when you want to show a link without directional emphasis:
a = EKS("a")
b = SQS("b")
a - bEdge attributes
Edge attributes are written inline after the operator.
Label only:
a = EKS("a")
b = SQS("b")
a ->[label="publish"] bColor only:
a = EKS("a")
b = SQS("b")
a ->[color="firebrick"] bLabel, color, and style together:
a = EKS("a")
b = SQS("b")
a ->[label="dispatch", color="darkgreen", style="dashed"] bCommon style examples shown in the source examples include dashed, solid, dotted, and bold.
Common patterns
Chain simple flows
Chaining is concise for short sequences:
a = EKS("a")
b = SQS("b")
c = Lambda("c")
a -> b -> cSplit larger flows across lines
For diagrams that are more than a tiny example, multi-line flows are usually easier to read:
source = EKS("source")
queue = SQS("queue")
handler = Lambda("handler")
store = S3("store")
source -> queue
queue ->[label="consume", style="solid"] handler
handler -> storeThis is often a better default than one very long chain.
Mixed operators
DiagramFlow also supports mixed connection operators in one expression:
a = EKS("a")
b = SQS("b")
c = Lambda("c")
d = S3("d")
a -> b - c <- dUse this form carefully. It is compact, but harder to scan than separate lines.
Recommended usage
- Start with plain
->edges and add attributes only when they communicate something useful. - Use labels for actions such as
publish,consume,read, orwrite. - Use color and edge style sparingly so the important relationships stand out.
- Prefer multi-line connections once a flow has more than two or three steps.
- Treat mixed operators as advanced shorthand, not the default style for production diagrams.
Common mistakes
- Encoding too much meaning into edge colors and styles before the basic flow is clear.
- Using one long chained expression for a large diagram when separate lines would be easier to review.
- Mixing
->,<-, and-in one expression without a strong readability reason.