We've lifted the restriction on defining flows between nodes without a shared network, greatly enhancing both the simplicity of descriptions and visual clarity.

---

Until recently, defining flows between nodes without a shared network wasn't feasible. For instance, in the diagram below, establishing a flow between the Load Balancer and API nodes was impossible due to the absence of a common network. Initially, this limitation led to splitting flows into two parts: from the source to the routing element and from the routing element to the destination. However, this approach not only added visual complexity but also misrepresented the role of the routing element. It may mislead users into perceiving this element as both the origin and destination of flows, whereas it serves solely as a layer-3 element.

Recognizing this, we've removed this restriction, allowing flows to seamlessly connect nodes without a shared network. Voilà!

In this example, nodes exist across three distinct networks without any shared network infrastructure. Through concise descriptions, the flows between these nodes can be visualized in just a few lines.

networks:
  Frontend:
    nodes: [LB]
  Backend:
    nodes: [API 1, API 2]
  Data:
    nodes: [DB]

flows:
  API:
    from: LB
    to: [API 1, API 2]
  SQL:
    from: [API 1, API 2]
    to: DB

Previously, achieving this diagram's clarity required a description similar to the one below. However, lifting this restriction significantly enhances the diagram's readability and comprehension.

networks:
  Frontend:
    nodes: [LB, Router]
  Backend:
    nodes: [API 1, API 2, Router]
  Data:
    nodes: [DB, Router]

flows:
  HTTP1:
    from: LB
    to: Router
    label: API
  HTTP2:
    from: Router
    to: [API 1, API 2]
    label: API
  SQL1:
    from: [API 1, API 2]
    to: Router
    label: SQL
  SQL2:
    from: Router
    to: DB
    label: SQL