Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Building HELM: An Interactive Operations Map for Real-Time System Visibility

Over the past development session, I built HELM — a comprehensive, self-contained HTML dashboard that visualizes the entire Queen of San Diego operations pipeline. HELM maps every data flow, system integration point, and operational process into an interactive force-directed graph, complete with health diagnostics and drill-down capability into system internals.

What Was Built

HELM is a single index.html file deployed to helm.queenofsandiego.com that provides a polished, interactive visualization of:

  • Revenue Channels: Viator, Boatsetter, GetMyBoat, and future partner platforms as nodes with live connectivity status
  • Lead Acquisition: Email campaigns, organic web search, referral partner codes, and direct bookings
  • Booking Pipeline: From visitor landing → email nurturing → crew dispatch → operations
  • Operations Flow: Crew call systems, dispatch messaging, payment processing, and post-sail workflows
  • System Health: Real-time color-coded node status (green = healthy, red = failure detected) with aggregate health bar
  • Drill-Down Details: Clickable nodes reveal associated Google Apps Script function signatures, database schemas, and API endpoints

The design uses a dark navy and gold color scheme with a force-directed physics simulation (via vis-network) to create an intuitive, self-organizing layout that engineers can interact with to understand system dependencies.

Technical Architecture

Frontend Stack

HELM is built as a self-contained HTML5 application with zero external dependencies beyond the vis-network CDN:

  • Visualization: vis-network@9.1.9 from jsDelivr CDN for force-directed graph rendering
  • Data Structure: Two parallel datasets — NODE_DATA and EDGE_DATA — defined inline as JavaScript objects
  • State Management: Browser sessionStorage for node expansion state and detail panel persistence
  • Health Probing: Client-side polling to Google Sheets API and Lambda endpoints with exponential backoff

The initNetwork() function initializes the vis-network graph with physics simulation tuned for readability: 

physics: {
  enabled: true,
  barnesHut: {
    gravitationalConstant: -15000,
    centralGravity: 0.3,
    springLength: 250
  },
  stabilization: { iterations: 500 }
}

Node Categories

The graph includes eight primary node types, defined in DEPTH_CATS:

  • Revenue Platforms: Viator, Boatsetter, GetMyBoat, future integrations (with greyed-out inactive nodes)
  • Lead Sources: Email campaigns, organic search, partner referrals, direct web
  • Core Services: Booking engine, payment processor, email service (SES)
  • Operations: Crew dispatcher, schedule manager, client comms
  • Dashboards: All operational dashboards become nodes (JADA, HELM, progress tracker, etc.)
  • Infrastructure: Databases, APIs, message queues, cloud services
  • People: Key personnel (e.g., Carole as founder/admin node)
  • Regulatory/External: Compliance, partner platforms, third-party services

Each node includes metadata for health checks, drill-down content, and visual styling. For example, the Carole node definition: 

{ id: 'carole', label: 'Carole (Owner)', depth: 'people', 
  healthCheck: 'static', status: 'healthy', functions: [...] }

Infrastructure & Deployment

S3 & CloudFront Setup

HELM is deployed via a custom multi-step infrastructure pipeline:

  • S3 Bucket: helm.queenofsandiego.com (created during this session)
  • CloudFront OAC: Origin Access Control configured to restrict direct S3 access
  • CloudFront Distribution: Created with default root object set to index.html
  • Route53 ALIAS: DNS record pointing helm.queenofsandiego.com to CloudFront domain
  • Cache Invalidation: Path /* invalidated on every deployment to ensure fresh content

The deployment workflow (captured in local shell commands): 

# Upload to S3
aws s3 cp /Users/cb/Documents/repos/sites/helm/index.html \
  s3://helm.queenofsandiego.com/index.html \
  --content-type text/html --profile [aws-profile]

# Invalidate CloudFront cache
aws cloudfront create-invalidation \
  --distribution-id [DIST_ID] \
  --paths "/*" \
  --profile [aws-profile]

Authentication Layer

HELM implements a password gate using SHA-256 hashing:

  • Password hash is embedded in the HTML file (not in secrets)
  • Client-side validation prevents unauthorized graph access
  • Sessions are stored in sessionStorage for the browser lifetime

Health Diagnostics & Real-Time Monitoring

A key differentiator of HELM is live system health probing. Nodes perform async health checks via:

  • Google Sheets API: For data source connectivity (crew schedules, booking lists, revenue tracking)
  • Lambda Endpoints: For serverless function availability
  • Email Service: Connectivity to AWS SES for campaign tracking
  • Static Probes: Hardcoded status for nodes without active endpoints (e.g., people nodes)

The pollHealth() function periodically updates node colors and recalculates an aggregate health bar: 

const healthScore = (healthyCount / totalProbed) * 100;
updateHealthBar(healthScore); // Updates UI progress bar

Failed probes trigger exponential backoff retry logic to avoid overwhelming services: 

if (retryCount < 3) {
  setTimeout(() => checkHealth(node), 1000 * Math.pow(2, retryCount));
}

Key Design Decisions

Why a Single HTML File?

HELM is deployed as a monolithic index.html (currently ~800