Architecture
Aether is built as a portfolio-connected commerce demo: a static customer experience backed by a Worker API, D1 persistence, Stripe sandbox payments, and deployment automation designed for a small production footprint.
The portfolio and Aether storefront are shipped together as a static front. Pages stay fast, cacheable, and independent from server-side rendering.
Hono routes own catalog, carts, contact messages, checkout, webhooks, request IDs, secure errors, and the API boundary used by the static front.
SQLite-backed D1 stores carts, orders, products, contact messages, webhook events, email events, and operational records for the demo.
Stripe, Clerk-ready auth, Resend, and Cloudinary configuration stay server-side in Worker secrets or deployment variables.
Runtime map
The front never owns secrets or final commerce decisions. It renders the experience, sends intent to the Worker, and receives normalized responses that are safe for the browser.
Infrastructure
Every push to main runs the same GitHub Actions workflow: build, test, then deploy each piece to its own Cloudflare resource. Nothing is deployed by hand.
Secrets & bindings (D1, Stripe, Resend, Clerk, Cloudinary)
Route handlers actually defined in the Worker API, counted straight from the source - not sample traffic.
79 endpoints · endpoints across 8 route groups
Every table declared across the D1 migrations, grouped by the part of the system it serves.
43 tables · tables across 7 domains
External product data is normalized into Aether contracts, filtered for usable images and names, merged with local overrides, then exposed through paginated API responses.
The browser keeps the cart responsive, while the Worker recalculates prices, validates quantities, creates Stripe test checkout sessions, and records orders after confirmed payment events.
Portfolio and store contact forms post to the same Worker API. D1 keeps the message history and Resend can deliver email notifications when credentials are configured.
GitHub Actions, Cloudflare Workers, Cloudflare Pages-compatible output, Wrangler, and environment-specific variables keep production deploys repeatable.
The demo uses public-safe behavior, protected checkout, API validation, idempotent webhook handling, and server-side secrets to avoid exposing sensitive keys in the client bundle.
The architecture favors static assets, Worker endpoints, D1, cached catalog reads, and sandbox payments so the project can run within practical Cloudflare demo constraints.