Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

Building a Printful-Integrated T-Shirt Store on Next.js 14 with AWS CloudFront and Stripe: The 86dfrom.com Infrastructure Setup

Over the past development session, we constructed a full-stack t-shirt e-commerce platform for 86dfrom.com, integrating Printful's print-on-demand API, Stripe payment processing, and serverless Google Apps Script backends—all deployed across AWS CloudFront, S3, and Vercel. Here's the technical breakdown of what was built, why, and how it all fits together.

Project Architecture Overview

The 86dfrom.com project follows a hybrid deployment model:

  • Frontend: Next.js 14 application deployed to Vercel (production via npx vercel@latest --prod)
  • Print fulfillment API: Printful REST API for product variant management and order creation
  • Payment processing: Stripe for credit card transactions, with webhook handlers for order status updates
  • Static assets & legacy redirect: AWS S3 + CloudFront CDN for HTML/CSS fallback and domain redirects
  • Backend automation: Google Apps Script (GAS) for order logging and inventory sync

This hybrid approach allows us to use Vercel's optimized Node.js runtime for dynamic routes (/api/webhook, /api/create-checkout) while maintaining AWS CloudFront as a failover and redirect layer.

Next.js 14 Build Verification

The project directory at /Users/cb/Documents/repos/sites/86dfrom.com contains a clean Next.js 14 build with zero compilation errors. The build includes five API routes:

  • /pages/api/create-checkout.js — Creates Stripe checkout sessions
  • /pages/api/webhook.js — Handles Stripe webhook events (payment intent succeeded, failed, etc.)
  • /pages/api/printful-variants.js — Retrieves product variant IDs from Printful API
  • /pages/index.js — Main storefront landing page
  • /pages/success.js — Post-purchase confirmation page

Build verification was performed via npm run build to ensure all routes compile cleanly before any deployment.

Printful API Integration

The Printful integration uses a two-step approach:

  1. Variant discovery: The script /scripts/get-printful-variants.js queries the Printful API for all available product variants. For this project, we target the Bella+Canvas 3001 Black t-shirt line (variants 4016–4020) to keep the initial catalog focused.
  2. Runtime lookup: During checkout, the API route /pages/api/printful-variants.js uses the variant IDs stored in environment variables to map user selections (size, color) to Printful's internal SKU system.

The Printful API key is organization-level with full scopes across all stores, allowing centralized variant management. The script outputs variant metadata (size, color, price) in JSON format, which is then embedded into .env.local for zero-latency lookups during checkout.

Environment Configuration

The .env.local file at project root contains:

  • PRINTFUL_API_KEY — API token for Printful REST calls
  • STRIPE_SECRET_KEY — Stripe secret key (test or live) for backend payment operations
  • STRIPE_PUBLISHABLE_KEY — Public-facing Stripe key for frontend checkout initialization
  • PRINTFUL_VARIANT_IDS — JSON array of variant IDs (e.g., {"4XL": 4020, ...})

These variables are injected into the Vercel deployment via the Vercel CLI during the --prod push, ensuring no secrets are committed to git.

AWS CloudFront and S3 Configuration

Parallel to the Next.js deployment, we set up AWS infrastructure for static assets and domain management:

  • S3 bucket: 86dfrom.com (created in us-east-1 for CloudFront compatibility)
  • CloudFront distribution: Primary distribution (ID: generated during creation) caches index.html and serves HTTPS traffic for 86dfrom.com
  • CloudFront redirect distribution: Secondary distribution handles the legacy domain 86from.com (typo variant) and redirects all traffic to https://86dfrom.com via a CloudFront Function

The redirect function, deployed at /aws-cloudfront-redirect-function.js, intercepts all requests to 86from.com and returns a 301 HTTP response. This pattern allows legacy links to remain functional without duplication of content.

SSL/TLS Certificate Management

Two ACM (AWS Certificate Manager) certificates were requested and validated:

  • 86dfrom.com — Primary domain certificate
  • 86from.com — Redirect domain certificate

Both certificates use DNS validation via CNAME records added to Route53. This approach is superior to email validation because it's fully automated and doesn't require manual intervention each renewal cycle. The validation records are:

Type: CNAME
Name: _acm-challenge.86dfrom.com
Value: _acm-validation-token.acm-validations.aws.
TTL: 300

ACM checks these records within minutes, and certificates auto-renew 30 days before expiration.

Route53 DNS Configuration

The hosted zone for 86dfrom.com in Route53 contains two A records (alias records pointing to CloudFront distributions):

  • 86dfrom.com → Primary CloudFront distribution
  • 86from.com → Redirect CloudFront distribution (301 to primary)

Both are alias records (AWS-native records, not traditional CNAME), which incur no additional Route53 query charges and provide health checking capabilities.

Google Apps Script Backend

For order logging and multi-channel inventory sync, a Google Apps Script project (/gas/Code.gs) was configured with manifest file /gas/appsscript.json. This script:

  • Receives POST requests from Stripe webhooks (via Vercel function)
  • Logs order details to a Google Sheet for team visibility
  • Triggers inventory updates to the Printful store

Deployment uses clasp (Google Apps Script command-line), with configuration stored in /gas/.clasp.json.

Deployment Workflow

The deployment script at /scripts/deploy.sh