Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

Deploying a Receipt Management System for quickdumpnow.com: S3 Static Hosting, CloudFront Caching, and Google Sheets Integration

This post covers the technical implementation of a new receipts management system for a trailer rental business operating under the quickdumpnow.com domain. The solution combines static site hosting on AWS S3, CloudFront edge caching, and Google Sheets integration via Apps Script for backend data collection.

What Was Done

We deployed a new receipts intake page at https://quickdumpnow.com/books, configured S3 and CloudFront to serve it properly, and integrated it with an existing Google Sheets-based port log to capture charter payment data. The implementation required careful attention to S3 object key naming conventions, CloudFront error handling, and the Google Sheets API for programmatic data entry.

File Structure and Local Development

The quickdumpnow project is organized as follows:

/Users/cb/Documents/repos/sites/quickdumpnow.com/
├── index.html (main landing page)
├── robots.txt
└── books/
    └── index.html (receipts management page)

The books directory was already present in the repository but hadn't been deployed. The /books/index.html file contained the receipts intake form, but it required verification before deployment to ensure it matched the site's visual design and functional requirements.

S3 Bucket Configuration and Object Keys

The quickdumpnow.com static site is hosted in an S3 bucket configured for website hosting. When deploying the books page, we uploaded the content to two S3 object keys to support both pretty URL access and direct object retrieval:

  • books/index.html — The canonical object, accessible via /books/index.html
  • books — A second object containing the same content, allowing CloudFront to serve /books without the index.html suffix

This dual-key approach is necessary because S3's static website hosting feature (which handles index document resolution) may not be visible to CloudFront when CloudFront is configured with an S3 REST API endpoint as the origin. By uploading to both keys, we ensure the content is available regardless of how the request reaches S3.

CloudFront Distribution and Error Handling

The site uses a CloudFront distribution with S3 as the origin. The distribution was configured with a custom error response that redirects 404 errors to the homepage. This behavior was intentional for the main landing page but required careful handling for the new /books path.

After deploying the S3 objects, we invalidated the CloudFront cache for the following paths:

  • /books
  • /books/index.html
  • /robots.txt (updated to block the receipts page from search indexing)

Invalidation was performed using the AWS CloudFront invalidation API. In the AWS CLI, this would look like:

aws cloudfront create-invalidation \
  --distribution-id [DISTRIBUTION_ID] \
  --paths "/books" "/books/index.html" "/robots.txt"

We verified the distribution configuration to confirm the error response settings and origin configuration were appropriate for this use case. The 404 redirect to homepage is acceptable for user-facing pages but we needed to ensure our new receipts page deployed successfully before the cache invalidation took effect.

Robots.txt and Search Indexing

The robots.txt file was updated to include a disallow rule for the /books path. This is appropriate because the receipts management system is an internal business tool, not a public-facing feature that should appear in search results.

User-agent: *
Disallow: /books

This file was uploaded to the S3 bucket root and included in the CloudFront invalidation to ensure search engines receive the updated directive promptly.

Google Sheets Integration via Apps Script

The port log used to track charter payments is maintained in Google Sheets via a Google Apps Script project. The session involved several operations on this backend system:

Sheet Identification and Data Structure

The Port Log sheet contains the following columns (identified via API calls to read the first five rows):

  • Charter date
  • Vessel/customer name
  • Payment amount
  • Notes

To programmatically access this sheet, we identified the correct sheetId parameter for the Port Log tab. Google Sheets uses numeric IDs for tabs (separate from the sheet name), and these IDs are required when using the Google Sheets API for direct cell manipulation.

Data Entry Process

A new charter entry for Joseph Zurek was added with the following details:

  • Date: Previous day's charter
  • Customer: Joseph Zurek
  • Amount: $1,845.72

The entry was appended to the Port Log using the Google Sheets API's appendValues method, which automatically finds the first empty row and inserts the data. This approach is more reliable than manual row manipulation because it doesn't require knowing the exact row number in advance.

Initial attempts to append the data failed due to an incorrect sheetId. We resolved this by querying the Apps Script manifest to retrieve the correct sheet metadata, then retrying the append operation with the correct parameters.

Technical Stack Summary

  • Origin: S3 bucket with static website hosting enabled
  • CDN: CloudFront distribution with custom error responses
  • Backend data collection: Google Sheets + Google Apps Script with programmatic API access
  • Local development: Git repository at /Users/cb/Documents/repos/sites/quickdumpnow.com/
  • Deployment method: S3 upload with CloudFront cache invalidation

Key Decisions and Why

Why the dual S3 object keys? CloudFront doesn't directly leverage S3's static website hosting feature when configured with a REST API origin. By uploading to both books/index.html and books, we ensure the pretty URL works correctly regardless of how CloudFront processes the request.

Why block /books in robots.txt? The receipts system is an internal business tool. Blocking it from search indexing prevents accidental disclosure in search results and reduces unnecessary crawl traffic.

Why use Google Sheets for the port log? Sheets provides a simple, familiar interface for business users to review payment records without requiring custom database infrastructure. Apps Script bridges the gap between the web interface and the sheet data.

What's Next

The receipts page is now live at https://quickdumpnow.com/books. The next phase should involve:

  • Frontend form validation and user experience improvements for the receipts intake form
  • Automation of port log updates directly from the receipts page submissions
  • Access control for the receipts system (authentication/authorization)
  • Integration testing to verify end-to-end data flow from web form to Google Sheets