Building a Fixed Network Topology Monitor

What This Example Builds

This example builds a full-screen network topology monitor instead of a generic relationship chart. The page presents three upstream service cards on the left, a central management hub, a scheduler node, and a vertical column of execution servers on the right. Users can pan, zoom, and use the built-in toolbar to inspect the scene, while node selection adds visible emphasis through scaling and a halo effect.

The main value of the example is that it shows how relation-graph can be staged as a dark operations dashboard with predictable positions, category-specific node skins, and lightweight monitoring overlays.

How the Data Is Organized

The active graph data lives directly inside MyGraph.tsx as RAW_NODES and RAW_LINES. The node list mixes content and layout hints: the three service nodes already include fixed coordinates, while the center node, scheduler, and execution-server nodes receive their final x and y positions during initialization. Before the graph is loaded, the code clones the raw arrays, assigns those missing coordinates, and adds lineWidth: 2 to every edge before calling setJsonData.

That structure maps cleanly to real operations data. The left-side nodes could be ingestion services, queues, or gateways; the center node could be an orchestration hub; the scheduler could represent a dispatcher; and the right-side column could be workers, pods, agents, or edge devices with status text. Although the folder also contains my-data.ts, the rendered graph in the current implementation is driven by the inline arrays in MyGraph.tsx.

How relation-graph Is Used

The demo is wrapped in RGProvider, which allows RGHooks.useGraphInstance() to access the mounted graph instance. RelationGraph is configured with a fixed layout, so the scene behaves like a manually composed topology board rather than an auto-arranged diagram. The options also keep the built-in toolbar enabled, apply a dark background, use curved links with left-right junction points, and enable wheel zoom plus drag panning.

Customization happens mainly through RGSlotOnNode. The slot renderer branches by node id so the center hub, the service cards, and the execution-server cards each get different markup and styling. The graph instance API handles the startup flow: setJsonData loads the prepared nodes and lines, moveToCenter recenters the canvas, and zoomToFit makes the whole topology visible on first render.

There are no editing features in the current example. It does not use line, canvas, or viewport slots, and the imported helper components such as DraggableWindow, SimpleUISelect, and SimpleUIBoolean do not participate in the current render path. Styling is split between graph options, Tailwind-style utility classes in JSX, and a small SCSS override that keeps .rg-map dark.

Key Interactions

The primary interaction is viewport inspection. Mouse wheel input zooms the graph, drag input pans it, and the built-in toolbar remains available for standard canvas navigation. On mount, the graph automatically loads its prepared data, centers the topology, and fits it into view so users start with the whole scene visible.

Node inspection is the secondary interaction. When a node becomes selected, the custom node slot enlarges the card and adds a pulse-like halo, which makes the inspected element stand out without changing the topology structure. The example stays in viewer mode: users can inspect and navigate, but they do not edit nodes, lines, or layout.

Key Code Fragments

This options block proves that the graph is intentionally configured as a fixed, dark dashboard viewer with built-in navigation.

const graphOptions: RGOptions = {
  debug: false,
  showToolBar: true,
  backgroundColor: '#0f172a', // Dark tech-style background
  layout: {
    layoutName: 'fixed' // Use fixed layout, manually control coordinates
  },
  // ...
  wheelEventAction: 'zoom',
  dragEventAction: 'move'
};

This preprocessing step shows how the example turns raw node records into a staged topology with explicit coordinates for the hub, scheduler, and execution column.

const nodes: JsonNode[] = RAW_NODES.map((node) => {
  const newNode = { ...node };

  if (node.id === 'centre') {
    newNode.x = 0;
    newNode.y = -49;
  }
  if (node.id === 'cron') {
    newNode.x = 250;
    newNode.y = -20;
  }

This load sequence shows that relation-graph instance APIs are responsible for startup data binding and initial viewport framing.

const lines: JsonLine[] = RAW_LINES.map(line => ({
    ...line,
    lineWidth: 2
}));

await graphInstance.setJsonData({ nodes, lines });
graphInstance.moveToCenter();
graphInstance.zoomToFit();

This slot branch is the core proof that the example uses custom node rendering to express semantic roles in the topology.

{({ node, checked }: RGNodeSlotProps) => {
  const isCentre = node.id === 'centre';
  const isService = ['data', 'proxy', 'task'].includes(node.id);
  const isExe = node.id.startsWith('exe-');

  return (
    <div
      className={`
        relative flex flex-col items-center justify-center transition-all duration-300
        ${node.selected ? 'scale-110' : ''}
      `}

This overlay markup shows that the dashboard framing is part of the example, not an external shell around the graph.

<div className="absolute top-6 w-full z-10 pointer-events-none flex justify-center">
  <h1 className="text-2xl font-bold text-sky-400 tracking-widest uppercase flex items-center gap-3">
    <div className="w-8 h-1 bg-sky-500 rounded-full animate-pulse" />
    Network Topology Monitor
    <div className="w-8 h-1 bg-sky-500 rounded-full animate-pulse" />
  </h1>
</div>

What Makes This Example Distinct

Compared with nearby examples, this one is unusually scene-specific. The comparison data shows that scene-network-2 is the closest neighbor, but that example uses a left-to-right tree layout and a canvas-level VPC annotation, while this example uses a manually staged fixed layout with a central hub, a scheduler handoff, and a right-side execution-server column. This makes scene-network the more direct reference when the goal is a monitoring dashboard with a deliberate screen composition rather than a topology map that still behaves like a tree.

The example is also distinct from other fixed-layout custom-node demos such as node-content-lines, models-relationship, and table-relationship. Those examples emphasize DOM endpoints, fake lines, or parameter-port wiring. Here, custom nodes are used mainly for monitoring semantics: service cards, status cards, color-coded alerts, and dashboard readability. The comparison output also marks the combination of fixed coordinates, mount-time setJsonData plus centering plus fit, toolbar-assisted navigation, and dark overlay framing as a relatively rare feature set in this library.

Where Else This Pattern Applies

This pattern transfers well to read-only operational scenes where position carries meaning. A team could adapt it for service health boards, batch-processing pipelines, fleet-worker dashboards, edge-device monitoring, or internal scheduler-and-queue overviews. The same structure also fits manufacturing station maps or regional infrastructure boards when the screen layout should stay stable across refreshes.

The main extension path is to keep the fixed topology and custom node slot, then replace the inline text with live metrics, alerts, or status badges from a real backend. That would preserve the scene-oriented clarity of this example while expanding it into a production monitoring surface.