Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

Building HELM: An Interactive Operations Map for Multi-Platform Booking & Dispatch Systems

Over the past development session, we designed and deployed HELM — an interactive, real-time operations visualization dashboard that maps the entire customer journey from initial contact through sail completion and payment reconciliation. This single-page application unifies visibility across email campaigns, web search traffic, referral partnerships, booking platforms, payment processors, and crew dispatch operations into one force-directed graph interface.

What Was Built

HELM is a self-contained HTML application deployed to helm.queenofsandiego.com that visualizes the complete operational flow:

  • Traffic Sources: Email campaigns, organic search, referral partner codes, direct traffic
  • Booking Platforms: Viator, Boatsetter, GetMyBoat, internal web booking (with greyed-out nodes for planned integrations)
  • Payment Processors: Stripe, PayPal, platform-native payment systems
  • Internal Systems: Crew dispatch, email automation, customer database, crew scheduling
  • Operations Dashboards: Analytics, crew management, financials — each surfaced as a drill-down node

The interface uses a physics-based force-directed layout (vis-network library) with dark navy/gold styling. Users can click any node to drill down into operational details, with live health diagnostics showing system status via color indicators (green for healthy, red for issues).

Technical Architecture & Key Decisions

Why a Single-File HTML Solution?

We chose a self-contained HTML file over a deployed Node.js or React application for three reasons:

  • Operational Resilience: No build step, no runtime dependencies. The file works anywhere, even if CI/CD is down.
  • Performance: Minimal latency for visualization rendering; vis-network runs entirely client-side.
  • Rapid Iteration: Single file edits map directly to production updates without rebuilding or redeploying application code.

Node & Edge Design

The graph includes two primary node categories:

  • System Nodes: Booking platforms, payment processors, internal services (Google Apps Script functions for email automation, crew dispatch, analytics)
  • Dashboard Nodes: Each major operational view (crew management dashboard, financial reconciliation, email campaign analytics) appears as a clickable node with drill-down capability

Edges represent data flow and operational dependencies. For example, "Viator → Payment Processor → Financial Reconciliation" shows how booking platform revenue flows through payment systems into accounting. Crew dispatch edges map to individual crew assignment workflows, dynamically pulled from gas_crewdispatch function signatures.

Live Health Monitoring

Each node performs lightweight health diagnostics via HTTP probes:

  • GAS scripts respond with status endpoints returning {"status": "ok"} or error messages
  • S3 buckets are pinged via CloudFront edge locations
  • Node color shifts from green (healthy) to red (degraded) based on probe response times and HTTP status codes
  • A system health bar at the top aggregates all node statuses

Infrastructure & Deployment

S3 & CloudFront Setup

We created a dedicated bucket and CDN distribution for HELM: 


# Bucket created for helm.queenofsandiego.com content
S3 Bucket Name: helm.queenofsandiego.com
Region: us-west-2 (co-located with primary infrastructure)

# CloudFront distribution for fast global edge delivery
CloudFront Distribution ID: [retained from deployment logs]
Origin: helm.queenofsandiego.com S3 bucket (via Origin Access Control)
Caching: index.html (TTL 300s) for rapid iteration; assets (TTL 86400s)
Security: HTTPS only, TLS 1.2+

We used Origin Access Control (OAC) instead of legacy OAI — OAC provides better security boundaries and automatic credential rotation without manual S3 policy updates.

DNS & Route53

Added an ALIAS record to Route53: 


Record Name: helm.queenofsandiego.com
Type: A (ALIAS)
Target: CloudFront distribution domain
Evaluate Target Health: true

The ALIAS record (AWS-specific) avoids additional DNS lookups and automatically follows CloudFront failover behavior.

S3 Bucket Policy

The bucket policy restricts access to CloudFront OAC only: 


Principal: "CloudFront Distribution OAC ID"
Action: s3:GetObject
Resource: helm.queenofsandiego.com/*
Effect: Allow
Condition: CloudFront OAC present in request

This prevents direct S3 access, ensuring all traffic routes through CloudFront for caching and DDoS protection.

Content Upload & Cache Invalidation

The deployment workflow: 


# 1. Write/edit the file locally
File: /Users/cb/Documents/repos/sites/helm/index.html

# 2. Upload to S3
aws s3 cp index.html s3://helm.queenofsandiego.com/index.html \
  --content-type "text/html; charset=utf-8" \
  --profile [your-aws-profile]

# 3. Invalidate CloudFront cache (forces immediate refresh globally)
aws cloudfront create-invalidation \
  --distribution-id [DISTRIBUTION_ID] \
  --paths "/*" \
  --profile [your-aws-profile]

# 4. Verify deployment (2-3 min for full global propagation)
curl -I https://helm.queenofsandiego.com/

Extracting Function Signatures for Drill-Down

HELM dynamically integrates GAS function signatures to allow drill-down into specific operations: 


// Extracted from gas_crewdispatch, gas_emailautomation, etc.
// Functions appear as sub-nodes under their parent system

gas_crewdispatch:
  - assignCrewToSail(sailId, crewId)
  - notifyCrew(crewId, sailDetails)
  - updateCrewSchedule(crewId, availabilityWindow)

gas_emailautomation:
  - sendConfirmationEmail(customerId, sailId)
  - sendReminderEmail(customerId, sailId, daysUntilSail)

When a user clicks the "Crew Dispatch" node, a side panel displays available functions and their current health status, enabling engineers to quickly trace operational issues to specific automation steps.

Key Decisions & Rationale

  • Greyed-Out Platform Nodes: Visually differentiate planned integrations (e.g., additional booking platforms) without cluttering the interface. When a platform goes live, toggle the node state from "inactive" to "active".
  • Client-Side Physics Engine: vis-network's force-directed layout runs entirely in the browser