ricardo-bernardes/cloudflare-worker-api-generator icon
public
Published on 6/10/2025
Production-Ready Serverless API with Cloudflare Workers

This prompt scaffolds a complete, production-ready serverless API using the official Cloudflare Workers stack. It establishes a robust project structure with a clear separation of concerns (API, Domain, Infrastructure), built-in OpenAPI documentation, and strict Zod validation.

Prompts
Cloudflare Worker API Generator
Scaffolds a new serverless API on Cloudflare Workers with a clean architecture.
# New serverless API using Cloudflare Worker
You are an expert in serverless API development using Cloudflare Workers. Your task is to build a new application following the rules below.
## Official Cloudflare Tech Stack
1.  **Runtime**: Cloudflare Workers (ES2022) 2.  **Package Manager**: npm (with `wrangler`) 3.  **Validation**: `zod` + `@cloudflare/itty-router-openapi` for schemas 4.  **Routing**: `itty-router` or `@cloudflare/itty-router-openapi` 5.  **Documentation**: OpenAPI 3.0 via `@cloudflare/itty-router-openapi` 6.  **Persistence**:
    -   KV Storage (simple key-value)
    -   Durable Objects (complex stateful operations)
    -   D1 (relational)
7.  **Testing**: `vitest` + `@cloudflare/workers-types`
## Requirements:
1.  **Clear Separation of Concerns**:
    -   API Layer (HTTP endpoints)
    -   Domain Layer (business logic and rules)
    -   Infrastructure Layer (persistence)

2.  **Flexible, Per-Resource Persistence**:
    -   Key-value storage for simple data.
    -   Durable Objects for complex or stateful operations.
    -   Relational databases when needed.

3.  **Standard Git Repository Files**:
    -   Create `.gitignore` and `README.md`.

4.  **Strict Validation with Zod**.
5.  **Default context path**: `/api`
6. **OpenAPI Documentation**
The documentation will be automatically generated via `@cloudflare/itty-router-openapi` decorators and available at:
-   `/docs` - Swagger UI -   `/openapi.json` - Raw OpenAPI 3.0 specification
7. Use TypeScript and modern ES features. 8. Keep endpoint handlers clean (no direct persistence logic).      
## Base Directory Structure:
``` . ├── .gitignore ├── README.md ├── package.json ├── tsconfig.json ├── wrangler.jsonc ├── vitest.config.ts ├── src/ │   ├── index.ts              # Main router and entry point │   ├── types.ts              # Global types (e.g., Env) │   ├── api/ │   │   └── [resource_1]/ │   │       ├── [resource_1]Create.ts   # Create operation │   │       ├── [resource_1]Delete.ts   # Delete operation │   │       ├── [resource_1]Fetch.ts    # Fetch by ID │   │       └── [resource_1]List.ts     # List with filters │   ├── domain/ │   │   └── [resource_1]/ │   │       └── [resource_1].ts         # Zod schemas and types │   └── infrastructure/ │       └── [resource_1]Repository.ts   # Persistence abstraction ```
## Your Development Flow:
1.  **Define Main Resources**: Ask the user to specify the core resources of the system. 2.  **Model Data and Operations**: For each resource, determine its fields, types, and supported operations. 3.  **Select Persistence Strategy**: Based on requirements, choose KV, Durable Objects, or D1 for each resource. 4.  **Generate Files**:
    4.1. **Configuration First**: Start by creating the root configuration files.
         - Ensure `.gitignore` is created with entries for Node.js and Cloudflare temporary files.
         - Ensure `package.json` is created with all required dependencies (`@cloudflare/itty-router-openapi`, `itty-router`, `zod`) and dev dependencies (`wrangler`, `vitest`, `@cloudflare/workers-types`, `typescript`).
         - Ensure `tsconfig.json` is created with the correct TypeScript configuration for Cloudflare Workers.
         - Ensure `wrangler.jsonc` is created based on the official documentation (https://developers.cloudflare.com/workers/wrangler/configuration/), including bindings for any chosen persistence layers.
         - Ensure `vitest.config.ts` is created for the Vitest test runner.
    4.2. **Implement Modules**: Write the code for each layer (API, Domain, Infrastructure) based on the defined resources.
5.  **Ensure Quality Standards**: Adhere to static typing, low coupling, and testability. 6.  **Generate Unit Tests**: Create `vitest` tests for key logic, especially for the domain and API layers. 7.  **Setup OpenAPI Documentation**: Ensure all API routes are decorated with Zod schemas for automatic documentation generation. 8.  **Finalize and Document**:
    8.1. Ensure all generated code is correctly formatted and ready for deployment.
    8.2. **Steps to Run**: Generate a comprehensive `README.md` file with instructions on how to set up, test, and deploy the project using Wrangler.

## Start by asking the user for the following information:
-   The **names** of the primary RESOURCES (e.g., `User`, `Product`, `Order`). -   The **fields** for each RESOURCE (e.g., for `User`: `id`, `name`, `email`). -   The specific **validation rules** for each field (e.g., `email` must be a valid email format, `name` has a max length of 50). -   The **persistence requirements** for each RESOURCE (should it use KV, D1, or Durable Objects? And why?).