Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

Building HELM: An Interactive Operations Dashboard for Multi-Platform Booking & Crew Management

What Was Done

We built HELM (Historical Event Lifecycle Map), a self-contained, single-file interactive operations visualization dashboard deployed to helm.queenofsandiego.com. HELM provides a force-directed graph view of Queen of San Diego's entire business flow—from marketing channels (email campaigns, web search, referral partners) through booking platforms (Viator, Boatsetter, GetMyBoat) to operational execution (crew dispatch, sail management, financial settlement). The dashboard includes live health diagnostics that probe backend systems and color-code nodes based on system status.

This addresses a critical need: engineering leadership needed a single visual reference that could drill down from high-level flow (how do customers reach us?) to operational detail (which crew members are assigned to this sail?), all connected to the underlying infrastructure and GAS automation pipelines.

Technical Architecture

Node & Edge Model

HELM uses a force-directed physics simulation (vis-network library) with three node categories:

  • Source nodes: Email campaigns, organic search, partner referrals, paid ads
  • Platform nodes: Live integrations (Viator, Boatsetter, GetMyBoat) plus greyed-out future platforms
  • Operational nodes: Crew dispatch system, expense tracking, health monitoring dashboards, financial settlement

Each node stores metadata (function signatures from Google Apps Script files, system health thresholds, drill-down detail panels). Edges represent data or control flow—for example, a Viator booking event triggers the processViatorbooking() GAS function, which connects to crew dispatch.

Health Diagnostics

Rather than static topology, HELM probes backend systems in real time. Each operational node (crew dispatch, expense tracker, financial settlement) has an associated health check:

  • Nodes glow green when their backend systems respond within SLA (typically <500ms)
  • Nodes glow yellow for degraded response (500ms–2s)
  • Nodes glow red for failures or timeouts (>2s or HTTP 5xx)
  • A system health bar at the top aggregates all probe results

The health check polling loop runs every 30 seconds, allowing engineers to spot operational issues at a glance without jumping between monitoring dashboards.

Infrastructure & Deployment

S3 & CloudFront Setup

HELM is served as a static HTML file with embedded CSS and JavaScript—no backend required, which minimizes operational overhead.

  • S3 bucket: helm.queenofsandiego.com (created in us-west-2, matching existing JADA infrastructure)
  • Bucket policy: Restricted to CloudFront Origin Access Control (OAC) only; no public read access
  • Object: index.html (approximately 85KB, including vis-network CDN link in script tags)

CloudFront distribution created with:

  • Origin: S3 bucket with OAC (not legacy Origin Access Identity)
  • Viewer protocol: Redirect HTTP → HTTPS
  • Cache behavior: 60-second TTL for index.html to allow rapid updates without stale data
  • TLS certificate: ACM wildcard cert for *.queenofsandiego.com (existing)

DNS & Domain Routing

Route53 alias record created:

helm.queenofsandiego.com  ALIAS  d1234example.cloudfront.net

This allows the CloudFront distribution to be updated or rotated without changing DNS records.

Key Build Decisions

Single-File HTML Over Microservices

We chose a self-contained HTML file (no separate API, no build step) because:

  • HELM is a reference tool for engineers, not a customer-facing app—uptime requirements are lower than production booking flow
  • It eliminates backend complexity; all network requests are either CDN fetches (vis-network library) or health probes to existing GAS endpoints
  • Engineers can view source, copy the file locally, and modify visualizations without CI/CD overhead

vis-network Over D3/Cytoscape

vis-network was selected for its:

  • Physics engine that automatically arranges nodes without manual layout (force-directed simulation)
  • Built-in interactivity: drag nodes, zoom, pan, search
  • Low learning curve—no data binding framework required
  • CDN availability; no npm build step needed

Dark Navy/Gold Aesthetic

The color scheme matches JADA's brand and improves readability on engineer monitors. Gold edges highlight active data flows; dim grey edges show potential-but-inactive paths (future integrations).

Health Probes vs. Static Status

Rather than hard-coding "system is healthy," each node makes a real HTTP request to a backend endpoint (or GAS Apps Script trigger) and evaluates response time + status code. This trades minimal latency (30s polling window) for accuracy—if crew dispatch is actually slow, HELM will show it in red, not green.

Implementation Details

File Structure

/Users/cb/Documents/repos/sites/helm/index.html

Contains:

  • <style> block: CSS grid layout, node styling, health bar, detail panel
  • <script type="text/javascript"> block: vis-network initialization, physics config, node/edge definitions, health polling loop, drill-down logic
  • <div id="network">: Canvas container for force-directed graph
  • <div id="detail-panel">: Collapsible sidebar showing selected node's GAS functions, related dashboards, recent health history

Key Functions in the Script

  • initNetwork(): Sets up vis-network instance, physics simulation, click handlers
  • makeVisNode(nodeId, label, category): Creates a node with appropriate styling (color, size, icon)
  • pollHealth(): Fires every 30 seconds; makes HTTP HEAD/GET requests to health endpoints for each operational node
  • updateNodeHealth(nodeId, status): Updates node glow color based on probe result
  • showDetail(nodeId): Populates detail panel with GAS function signatures, dashboards, crew assignments

GAS Integration

HELM references function signatures extracted from Queen of San Diego's Google Apps Script files:

  • processViatorbooking(), processBoatsetterbooking(), etc. (from gas_booking_integrations)