Crafting Cloud-Ready Web Adventures: Resilient and Accessible for All

Context: These practices apply to my small projects (Car-Match, Interactive Pokédex, Triangle Shader Lab, CheeseMath). They run on GitHub Pages, Netlify, or Render—not on enterprise infra.
AI assist: ChatGPT helped reorganize my scattered checklists into readable sections; every item maps to real repos and docs.
Status: Student perspective. Think “personal SRE playbook” more than “platform engineering manifesto.”

Reality snapshot

• Front ends: GitHub Pages (PWA/React/Vite builds) or Netlify (Gatsby). Build logs live in Actions + Netlify dashboards.
• Back ends / APIs: Render free tier (Express + Mongo Atlas) or small serverless functions. Cold starts are real, so every README states the wake-up delay.
• Observability: DevTools, Netlify analytics, basic CloudWatch dashboards, and manual smoke tests. No PagerDuty, no multi-region failover.
• Goal: Publish demos that anyone can run, show how I think about resilience, and be transparent about what’s missing.
• Metrics tracked: Lighthouse (accessibility/perf), axe scans, cold-start timing on Render, uptime via simple curl smoke tests, and budget tables in Notion.

Table of contents

• My five-part pre-launch checklist
• Case study: Interactive Pokédex
• Other examples
• Deployment patterns I use
• Risks and mitigations
• Takeaways
• What still needs work

My five-part pre-launch checklist

1. Accessibility

• Semantic HTML (main, nav, button) before considering ARIA; headings are nested correctly.
• Keyboard walkthrough recorded before each deploy (tab through, ensure focus outlines, confirm skip links).
• Automated scans: axe CLI + Lighthouse (desktop + mobile). Failures block the release.
• Manual screen reader pass (VoiceOver on Mac). Rough edges get logged in the README “Reality” block if I can’t fix them immediately.
• Prefers-reduced-motion respected; animations gated behind that check.

2. Performance

• Bundle budgets in Vite/Gatsby (performanceBudget file). If LCP > 2.5 s locally, I trim images/fonts before publishing.
• Lazy-load heavy sections (Three.js demos, code examples); heavy shaders get screenshots + “open demo” links instead of auto-loading.
• Use Netlify deploy previews to test throttled 3G speeds. I log actual numbers in the PR description.
• Cache strategy noted: IndexedDB/localStorage for recent results; explicit statement of what is cached and for how long.

3. Reliability

• GitHub Actions handles lint/tests/builds. Netlify + Render webhooks notify Slack so I see failures quickly.
• Each repo has a /healthz endpoint (backend) or /status.json file (frontend) describing what “healthy” means.
• Feature flags live in JSON or env vars to hide in-progress sections while still deploying often.
• Manual smoke script (scripts/smoke.sh) for each project; I run it after deploys and log pass/fail in PRs.
• Cold-start notes: README and UI call out Render wake-up times; front ends show a “waking API” banner instead of failing silently.

4. Security

• Secrets live in GitHub Actions secrets or Render dashboard. READMEs show exactly what to set (REACT_APP_API_BASE_URL, MONGODB_URI, etc.).
• npm audit + OWASP ZAP baseline workflows run at least weekly. Issues get logged, even if the fix is “upgrade when maintainer releases patch.”
• If a project uses third-party scripts, I document why and add subresource integrity hashes when possible.
• No PII; if a demo touches user data, it’s clearly fake data.
• CORS rules documented per environment; default is least privilege (same-origin where possible).

5. Cost & honesty

• Keep a tiny Notion table of monthly spend (Render free tier, Atlas, Netlify). Anything that risks a charge gets an alert.
• README “Reality Check” section spells out cold starts, missing features, and TODOs so nobody mistakes a demo for production.
• When something’s down (e.g., Render sleeping), the site tells you up front. No silent failures.
• “Not production” banner on study sites (Triangle Shader Lab, CheeseMath) plus AI disclosure where relevant.

Case study: Interactive Pokédex (GitHub Pages)

Other examples

• Car-Match: Frontend on Pages, backend on Render/Atlas. README and /projects/car-match/ warn about 5-minute cold starts. Health checks + logs in Render dashboard show when the API is up.
• Triangle Shader Lab: Static Next.js site on GitHub Pages. Observability is a simple log overlay + Netlify analytics—enough for a study project.
• CheeseMath: Next.js demo + Jest practice repo. Accessibility checklist stored in docs/a11y.md, deploys automated via GitHub Actions → Pages.
• Targeted SPA résumés: CodePen → static export; honesty blocks + accessibility checklist; PDF-first so recruiters aren’t forced through the SPA.

Deployment patterns I use

• Static (GitHub Pages/Netlify): Vite/Gatsby/Next static exports; GitHub Actions builds with axe + Lighthouse.
• Render + Atlas (APIs): Express + Mongo free tiers; health checks wired; cold-start warnings in UI.
• Serverless bits: Small functions for email/contact forms; logged to CloudWatch or a simple log endpoint; env vars managed per provider.
• Infra as docs: No heavy IaC here; I keep diagrams + runbooks per project so anyone can recreate the setup manually.

Risks and mitigations

• Cold starts: Mitigation—UI banner for “waking API,” keep endpoints lean, document expected delay.
• Rate limits / outages: Mitigation—catch errors client-side, show friendly fallback, log the event in browser console for repro.
• Accessibility drift: Mitigation—block merges on axe/Lighthouse failures; manual keyboard pass before release.
• Cost creep: Mitigation—Notion budget table + provider alerts; kill switches are “delete Render service” since these are demos.
• Security gaps: Mitigation—no PII, secrets in env, ZAP baseline weekly, note known vulns in README if upstream unpatched.

Takeaways

• “Reality” blocks earn trust: calling out cold starts and missing features upfront prevents surprises.
• Accessibility + perf as gates: axe/Lighthouse as blockers force me to ship leaner, more usable demos.
• Proof over polish: health checks, smoke scripts, and error banners matter more than animations for these demos.
• Write it down: runbooks and README honesty notes are the difference between a cute demo and something someone else can reason about.

What still needs work

• End-to-end synthetic tests that run after each deployment (Playwright/Checkly). Right now smoke tests are manual.
• Better logging for front-end demos (would love to send errors to Sentry or a lightweight endpoint).
• Document cost impacts when I experiment with larger datasets or GPU workloads.
• Expand the checklist into a real template repo so I stop copy/pasting between projects.

References