Skip to content

enytc/zetsu

Repository files navigation

Zetsu API

License: MIT Framework: Hono Runtime: Cloudflare Workers CI codecov

Zetsu is a highly opinionated, production-ready, and battle-tested Edge API template built on Hono and designed exclusively for Cloudflare Workers. It was created to provide a bulletproof foundation for capturing waitlist signups securely, but its modular architecture makes it the perfect starting point for any high-performance Edge API.

🚀 Why Zetsu?

Zetsu doesn't just "work"; it is engineered for absolute resilience, observability, and scale at the Edge:

  • Edge Native: Zero Node.js dependencies. Runs directly on the V8 isolate via Cloudflare Workers for sub-millisecond cold starts and global distribution.
  • Bot Mitigation: Built-in, invisible CAPTCHA integration using Cloudflare Turnstile to ensure your API only processes requests from real humans.
  • Robust Observability: Context-injected, structured JSON logging using Pino, complete with requestId distributed tracing and Server-Timing headers.
  • Fail-Safe Configuration: Manual, strict environment variable validation ensures the Worker fails fast with clear errors rather than crashing silently mid-request.
  • Type-Safe Validation: Payload validation via Zod, with schemas decoupled from routes for maximum reusability.
  • Modular Architecture: Strict separation of concerns (Routes → Implementations → Services) makes testing and scaling the codebase trivial.

🛠 Tech Stack


📂 Architecture

Zetsu follows a clean, highly decoupled architecture:

src/
├── index.ts                 # Master entry point, global middleware, error handlers
├── types.ts                 # Global type definitions (Bindings, Context Variables)
├── lib/
│   ├── config.ts            # Manual, fail-safe environment validation
│   └── logger.ts            # Edge-optimized Pino logger factory
├── schemas/
│   └── waitlist.ts          # Zod validation schemas
├── services/
│   ├── resend.ts            # Resend API integration logic
│   └── turnstile.ts         # Cloudflare Turnstile verification logic
├── implementations/
│   └── waitlist.ts          # Core business logic (orchestrating services)
└── routes/
    ├── health.ts            # Health check definitions
    └── waitlist.ts          # Route-to-middleware/implementation mapping

⚙️ Local Development Setup

1. Prerequisites

2. Installation

Clone the repository and install dependencies:

git clone https://github.com/enytc/zetsu.git
cd zetsu
npm install

3. Environment Variables

Cloudflare Workers use .dev.vars for local secrets instead of standard .env files.

  1. Copy the example file:
    cp .env.example .dev.vars
  2. Open .dev.vars and fill in your actual credentials:
    • RESEND_API_KEY: Your API key from the Resend dashboard.
    • RESEND_SEGMENT_ID: The specific Segment ID where waitlist users should go.
    • TURNSTILE_SECRET_KEY: Your Secret Key from the Cloudflare Turnstile dashboard.

4. Start the Local Server

Run the application using Wrangler's local development simulator:

npm run dev

The API will be available at http://localhost:8787.


🛡 Quality Control

Zetsu enforces strict code quality standards to prevent regressions. Before committing or deploying, run:

# Type checking without emitting compiled files
npm run type-check

# Ultra-fast linting (will fail if deprecated APIs are used)
npm run lint

# Code formatting
npm run format

🚢 Production Deployment

Deploying to Cloudflare's global edge network takes seconds, but requires properly configuring your production secrets first.

Step 1: Authentication

Login to your Cloudflare account via the Wrangler CLI:

npx wrangler login

Step 2: Configure Production Secrets

CRITICAL: Never hardcode secrets in wrangler.toml. You must inject them securely into Cloudflare's infrastructure. Run the following commands and paste your keys when prompted:

npx wrangler secret put RESEND_API_KEY
npx wrangler secret put RESEND_SEGMENT_ID
npx wrangler secret put TURNSTILE_SECRET_KEY

Step 3: Configure Domains and Environments

Open wrangler.toml. By default, Zetsu deploys to a *.workers.dev subdomain. If you want to use a custom domain, add a routes array to your environment block in wrangler.toml:

[env.production]
name = "zetsu"
route = { pattern = "api.yourdomain.com/*", custom_domain = true }

Step 4: Deploy

Once your secrets are set and your wrangler.toml is configured, launch it:

npm run deploy

Note: This command uses wrangler deploy, which automatically reads the wrangler.toml configuration and pushes your code to the Edge.


🧠 Design Philosophy & Best Practices

If you contribute to or extend this template, please adhere to these core philosophies:

  1. Fail-Fast Initialization: If a required environment variable is missing, the application should throw a critical error during middleware initialization, rather than failing silently deep inside a service.
  2. Context is King: Never rely on global state (process.env). Always inject dependencies (like logger and config) into the Hono Context (c.set/c.get). This ensures safe execution in the shared V8 isolate environment.
  3. Log Everything (Securely): Use the request-scoped Pino logger for all operations. Ensure requestId is always attached. Never log secrets.
  4. Graceful Degradation: When integrating with external APIs (like Resend), handle their failures gracefully. If a user tries to join a waitlist they are already on, or if the email service has a minor hiccup, log the error internally but return a success message to the frontend to maintain a frictionless UX.
  5. No Deprecated Code: The linter is strictly configured to reject any code marked with @deprecated. Always use the modern alternative (e.g., z.email() instead of z.string().email()).

🧪 Testing Strategy

Zetsu is designed to be mathematically verified before it ever reaches production. We use Jest for a comprehensive suite of Unit and End-to-End (E2E) tests.

  • Unit Tests (tests/unit/): Verifies discrete functions and services (like configuration validation and external API SDKs). External HTTP calls are strictly mocked.
  • E2E Tests (tests/e2e/): Validates the entire request lifecycle. Thanks to Hono's native Fetch API support, app.request() allows us to test the full middleware stack (routing, validation, headers, error handling) in milliseconds without binding to a local port.

To run the test suite and generate a coverage report:

npm run test:coverage

Our CI pipeline guarantees that code is never merged unless the test suite passes with high coverage.


📄 License

This project is licensed under the MIT License - see the LICENSE file for details.

About

Waitlist system

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published