Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Rebuilding Queen of San Diego's Booking Platform: Homepage-to-Payment Integration & Multi-Environment Deployment

What Was Done

Over this session, we rebuilt the core user journey for queenofsandiego.com's booking platform—from homepage CTA through payment collection. The work involved:

  • Replacing a broken Google Maps embed with a payment QR code panel (Stripe, Zelle, Venmo)
  • Adding direct 2hr/3hr booking duration buttons in the hero section, wired to the Google Apps Script calendar modal
  • Fixing asset references and extending the GAS booking automation to return booked dates
  • Setting up a private P&L calculator environment with basic auth protection at pnl.queenofsandiego.com
  • Integrating booking visibility into ops/HELM dashboards for internal tools

Technical Details: Frontend Changes

The primary work centered on /Users/cb/Documents/repos/sites/queenofsandiego.com/index.html, which receives multiple iterations to fix cascading issues:

Payment QR Panel Replacement

The original Google Maps iframe was broken and served no functional purpose. We replaced it with a payment options panel containing three QR codes. The panel uses flexbox layout with card-style containers, each linking to a different payment method. Asset references were corrected—specifically fixing a filename from zelle-qr.jpg to zelle-qr.jpeg to match what was actually in the repository.

Hero CTA & Booking Modal Wiring

The hero section's "Reserve Now" button and two new duration buttons (2hr, 3hr) now call the jadaOpenBook(duration) function. Previously, the modal had no awareness of session duration; we added a duration parameter that gets passed to the Google Apps Script booking endpoint. This allows users to select their preferred duration before entering the calendar picker.

The reserve button in the navigation bar was updated to trigger the same flow with a default duration, ensuring consistency across entry points.

Technical Details: Backend & GAS Integration

The Google Apps Script backend in /Users/cb/Documents/repos/sites/queenofsandiego.com/BookingAutomation.gs was extended to:

  • Accept a duration parameter from the frontend modal
  • Return a booked_dates endpoint that supplies the calendar picker with already-booked time slots
  • Integrate with the existing CalendarSync logic to pull data from the JADA calendar

Changes were deployed using clasp push, and the web app deployment was updated to expose the new booked_dates endpoint alongside the existing doGet handler. The GAS script ID was read from the clasp config and deployments were verified before pushing changes to production.

Infrastructure: Private P&L Calculator Setup

A new private environment was created at pnl.queenofsandiego.com to host a P&L calculator with basic HTTP authentication. This required:

AWS S3 & CloudFront

  • Created a private S3 bucket specifically for P&L files (no public access)
  • Uploaded pnl-calculator.html as the bucket's index.html
  • Generated an Origin Access Control (OAC) to allow CloudFront to access the private bucket without public credentials
  • Created a CloudFront distribution with the bucket as origin, applying the OAC policy
  • Applied a bucket policy restricting access only to the CloudFront distribution's service principal

SSL/TLS & Domain Setup

  • Requested an AWS Certificate Manager certificate for pnl.queenofsandiego.com
  • Validated the certificate via DNS CNAME record in Route 53
  • Added A and AAAA alias records pointing the subdomain to the CloudFront distribution

Basic Authentication via CloudFront Function

Rather than implement authentication at the application level, we used a CloudFront Function—a lightweight edge compute capability—to enforce basic HTTP authentication before requests reach the origin. The function:

  • Intercepts all requests to the distribution
  • Checks the Authorization header for valid base64-encoded credentials
  • Returns a 401 Unauthorized response if credentials are missing or invalid
  • Forwards requests with valid credentials to the origin

This approach keeps authentication logic at the edge, reducing load on the origin and avoiding the need for per-user session management. The function was published to the LIVE stage and tested to confirm 401s return without auth and 200s return with correct credentials.

Infrastructure: Ops & HELM Dashboard Integration

The internal ops.queenofsandiego.com and HELM dashboards were updated to surface booking data alongside existing tools:

  • Downloaded existing ops/index.html and helm/index.html from their respective S3 buckets
  • Inspected the tool node structure and ROOT_NODES array to understand the dashboard architecture
  • Added booking/calendar references to the financial/ledger section of HELM, allowing internal teams to monitor booked sessions
  • Updated S3 bucket contents and invalidated CloudFront caches for both distributions to serve the new versions

CloudFront distribution IDs were looked up via the AWS CLI, and cache invalidation was requested for the primary HTML files to ensure the new versions were served immediately.

Key Decisions & Rationale

Why CloudFront Functions for Auth?

CloudFront Functions execute at edge locations with sub-millisecond latency and no charge per request (only a small monthly fee). This is ideal for basic authentication because it's a simple, stateless operation. Alternatives like Lambda@Edge offer more flexibility but with higher latency and per-invocation costs. For a simple password check, CloudFront Functions are the right fit.

Why OAC Over Origin Access Identity?

AWS recommends Origin Access Control (OAC) over the older Origin Access Identity (OAI) for new distributions. OAC supports a wider range of S3 request signing patterns and is better integrated with current AWS best practices. The bucket policy explicitly grants access only to the CloudFront distribution, preventing direct public access to the S3 bucket while CloudFront manages the distribution.

Why Multiple Duration Buttons?

Users often have a good sense of how long they need before opening a calendar. Offering 2hr and 3hr shortcuts in the hero section reduces friction—they skip the modal and go straight to date selection for their preferred duration. The modal still supports custom durations for edge cases.

Deployment & Validation

All changes were deployed through a coordinated series of steps: 


# GAS changes pushed to production
clasp push

# Homepage updates deployed to S3
aws s3 cp index.html s3://queenofsandiego.