A community mission with a practical digital foundation
I co-founded Grateful Giving Foundation and built its digital presence to support community participation. The foundation describes itself as youth-led and community-powered in Monterey Park, California, with giving activities dating to 2020.
Its work brings young people, families, and neighbors together to gather supplies, pack hand-decorated Gratefulness Bags with everyday essentials, and deliver them with care. The website makes the mission understandable and gives visitors clear paths to learn about the organization, explore events, and get involved. The foundation’s website supplies that organizational context.
The actual technology stack
The local repository uses plain HTML, CSS, and JavaScript for the public interface. Cloudflare Workers serves the assets and handles API requests, with Wrangler providing runtime configuration. Resend handles outbound contact messages and newsletter contact operations. The contact setup documentation preserves Google Workspace receiving-mail configuration while adding verified sending-domain records.
This is a deliberate split between cacheable public content and dynamic submissions. Navigation, mission pages, photography, and updates do not require a client framework or a database round trip. Contact and newsletter requests cross into the Worker only when a visitor submits a form.
Frontend structure and progressive interaction
Semantic page structure supplies landmarks, headings, a skip link, and a mobile navigation control with expanded state. JavaScript supports navigation and visual reveal effects while the core content remains readable as HTML. Deferred scripts avoid blocking document parsing, and below-the-fold photography uses lazy loading.
Canonical URLs, social metadata, robots directives, and Organization/WebSite JSON-LD describe the foundation consistently to crawlers and sharing tools. The implementation keeps the public mission separate from submission logic so content maintenance does not expose email credentials.
Contact processing at the edge
The contact handler validates method, origin, content type, bounded request size, and individual fields before contacting the email provider. A honeypot and a per-location IP rate limiter provide basic abuse controls. Names and emails reject control characters; the phone field has an explicit character and length policy.
A UUID idempotency key is reused across uncertain client retries and sent to Resend. That addresses a common distributed-system failure: the provider accepts a message, but the client does not receive confirmation and submits again. The submitted visitor email is a Reply-To value, while the From address remains on the verified sending domain.
Illustrative, simplified code explaining the implementation pattern. This is not a copy of private production source.
// Simplified contact boundary, matching the repository's design.
const response = await fetch("https://api.resend.com/emails", {
method: "POST",
headers: {
Authorization: `Bearer ${env.RESEND_API_KEY}`,
"Content-Type": "application/json",
"Idempotency-Key": `contact/${submissionId}`
},
body: JSON.stringify({
from: env.CONTACT_FROM_EMAIL,
to: configuredRecipients,
reply_to: validatedEmail,
subject: "New Get Involved inquiry",
text: validatedPlainTextMessage
}),
signal: AbortSignal.timeout(12000)
});
if (!response.ok) return providerFailure(response.status);
const result = await response.json();
if (!result.id) return invalidProviderResponse();
return Response.json({ ok: true });Success means provider acceptance, not guaranteed inbox delivery. The code distinguishes configuration failures, rejected provider requests, timeouts, and invalid responses. Visitor values remain available for retry in the interface, while sensitive details and credentials are excluded from diagnostic logging.
Newsletter consent and subscription state
The newsletter endpoint verifies explicit consent and a consent-version identifier, normalizes the email, and records a server-generated timestamp and source in provider contact properties. Existing contacts are looked up before a segment membership is added.
The implementation preserves a prior global unsubscribe choice instead of silently overriding it when someone submits another form. Contact creation, property updates, and segment membership are separate provider operations; an intermediate failure returns an error instead of presenting false success. Provider throttling has a bounded retry and individual requests have timeouts.
Validation and operational maintenance
Node’s built-in test runner exercises the contact handler with mocked email responses, avoiding real messages during automated checks. Boundary cases include invalid submissions, provider rejection, missing configuration, and successful acceptance. Production verification additionally checks the form feedback and actual receiving mailboxes.
The operational design concentrates secrets in Worker configuration, leaves receiving-mail DNS intact, and gives volunteers a predictable inquiry and newsletter process. The impact here is participation and organizational reliability. No donation totals or financial outcomes have been supplied, so the case study does not attach an invented revenue figure.