Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Building HELM: An Interactive Operations Topology Visualizer for Multi-Platform Booking Systems

What Was Done

I built HELM (JADA's interactive operations map) as a self-contained, production-ready visualization dashboard deployed to helm.queenofsandiego.com. HELM provides a force-directed graph visualization of the entire booking-to-operations pipeline, displaying:

  • Revenue sources (Viator, Boatsetter, GetMyBoat, organic web search, email campaigns, referral partner codes)
  • Customer acquisition funnel nodes (website visitors, email list subscribers, affiliate conversions)
  • Booking platform integrations with live status indicators
  • Operations workflow stages (crew dispatch, email notifications, sail management)
  • Interconnected relationships showing how data and money flow through the system

The implementation includes real-time health diagnostics, a drill-down detail panel for inspecting node properties and connected GAS functions, and a polished dark navy/gold design suitable for sharing with engineering peers at tier-one firms.

Technical Architecture

Single-File Design with vis-network

HELM is deployed as a single HTML file (/Users/cb/Documents/repos/sites/helm/index.html) to minimize dependencies and deployment complexity. The architecture leverages:

  • vis-network 9.1.2 (CDN-hosted): Force-directed physics simulation with GPU-accelerated rendering
  • vis-data 7.1.6: DataSet management for node/edge updates without full re-renders
  • SHA-256 password gating: Client-side password protection using Web Crypto API

The file structure contains three main sections:

<head>
  - Inline CSS (dark navy/gold theme, 2000+ lines)
  - vis-network/vis-data CDN imports
<body>
  - Login modal with SHA-256 hashing
  - Network visualization container
  - Drill-down detail panel (collapsed by default)
  - Inline JavaScript (3000+ lines)

Node and Edge Data Structure

NODE_DATA is a JavaScript object mapping system components to visual properties:

  • Platform nodes: viator_platform, boatsetter_platform, getmyboat_platform, with greyed-out styling for inactive integrations
  • Acquisition nodes: organic_web, email_campaign, referral_partners, paid_search
  • Operations nodes: gas_emailer, gas_crewdispatch, gas_booking_processor, progress_dashboard
  • Dashboard nodes: All operational dashboards (expense tracker, crew system, ops scheduler) appear as first-class graph nodes

Each node includes metadata for the drill-down panel: display name, description, status indicator, and connected GAS function signatures extracted from the source repos.

Health Diagnostics and Live Probes

Nodes are colored dynamically based on liveness checks:

  • Green glow: Service responded within 500ms with HTTP 200
  • Yellow glow: Service is reachable but slow (>500ms) or non-critical component
  • Red glow: Service unreachable or returned error status
  • Grey: Known platforms not yet live (Boatsetter in beta, GetMyBoat pending integration)

A system health bar at the top summarizes the percentage of healthy nodes. The polling mechanism runs every 30 seconds with exponential backoff for failed probes.

Infrastructure and Deployment

S3 Bucket Setup

Created helm.queenofsandiego.com S3 bucket with the following configuration:

Bucket name: helm.queenofsandiego.com
Region: us-east-1
Versioning: Enabled
Server-side encryption: AES-256
Block public access: All enabled (rely on CloudFront OAC)

The bucket policy grants the CloudFront Origin Access Control (OAC) permission to GetObject on all objects, preventing direct S3 URL access.

CloudFront Distribution

Deployed a CloudFront distribution with:

  • Origin: S3 bucket with Origin Access Control (OAC) — modern pattern replacing Legacy Origin Access Identity (OAI)
  • Default cache behavior: 3600s TTL for index.html, with cache invalidation on deployments
  • Compression: gzip enabled for HTML, CSS, JavaScript
  • SSL/TLS: ACM certificate for helm.queenofsandiego.com (wildcard provisioned for *.queenofsandiego.com)
  • Viewer protocol policy: Redirect HTTP to HTTPS

Distribution ID obtained via AWS CLI and stored for cache invalidation workflows.

Route53 DNS Configuration

Created an ALIAS record in the queenofsandiego.com hosted zone:

Name: helm.queenofsandiego.com
Type: A (ALIAS to CloudFront)
Target: CloudFront distribution domain name
Evaluate target health: No

This pattern avoids DNS query charges for the alias lookup and provides automatic failover to CloudFront's global edge network.

Deployment Workflow

Each iteration follows this pattern:

# 1. Syntax validation
node -c /Users/cb/Documents/repos/sites/helm/index.html

# 2. Upload to S3
aws s3 cp /Users/cb/Documents/repos/sites/helm/index.html \
  s3://helm.queenofsandiego.com/index.html \
  --content-type "text/html; charset=utf-8" \
  --profile <aws-profile>

# 3. Invalidate CloudFront cache
aws cloudfront create-invalidation \
  --distribution-id <DIST_ID> \
  --paths "/*" \
  --profile <aws-profile>

# 4. Poll distribution status
aws cloudfront get-distribution --id <DIST_ID> \
  --profile <aws-profile> | grep Status

Invalidation typically propagates to all edge locations within 60–120 seconds. The smoke test verifies the public HTTPS URL (https://helm.queenofsandiego.com/) returns a 200 response with the updated content.

Key Design Decisions

Why Single-File Over Modular Frontend

HELM prioritizes operational visibility for internal teams. A single self