# Deno project blueprints

These are more than Hello World demos. Each blueprint can be implemented, tested, and deployed in vertical slices. Finish one end-to-end slice before adding features.

## 1. [Fresh blog](/en/docs/projects/fresh-blog)

```text
fresh-blog/
├── routes/posts/[slug].tsx
├── routes/admin/posts.tsx
├── islands/PostEditor.tsx
├── components/
├── src/db/{client,schema}.ts
└── deno.json
```

Stack: Fresh 2, PostgreSQL, and Drizzle. Phase one covers a post list, detail page, and protected create endpoint. Markdown, drafts, images, and search belong in later slices.

Acceptance: posts remain readable without JavaScript, the slug constraint works, only the editor island hydrates, and migrations run as a separate release step.

## 2. [Deno MCP server](/en/docs/projects/mcp-server-project)

```text
mcp-project/
├── main.ts
├── tools/{search,read}.ts
├── schemas.ts
├── fixtures/
└── deno.json
```

Begin with stdio and read-only tools. Validate arguments with Zod and protocol-test fixtures before adding Streamable HTTP, authentication, or writes. Follow the [MCP server guide](/en/docs/ai/mcp-server).

## 3. [Cron service](/en/docs/projects/cron-service)

```text
cron-service/
├── jobs/daily-report.ts
├── services/report.ts
├── main.ts
└── deno.json
```

Write the job as a normal testable function, then trigger it with `Deno.cron()`. Make it idempotent with a database constraint or execution key, and expose delayed, failed, and replayed runs to observability.

## 4. [Image-processing API](/en/docs/projects/image-api)

```text
image-api/
├── routes/transform.ts
├── services/image.ts
├── storage.ts
└── main.ts
```

Use Hono plus `npm:sharp` to accept size-limited images, validate MIME and pixel dimensions, transform, and write to object storage. `sharp` includes native code, so smoke-test the target Deno version and container or Deploy environment before committing to it.

## Shared definition of done

- `deno fmt --check && deno lint && deno check && deno test` passes;
- `deno.lock` is committed and install scripts have an explicit allowlist;
- development, migration, tests, and production use separate least-privilege commands;
- health checks, structured logs, timeouts, error mapping, and secret management are wired;
- README documents local startup, database setup, deployment, and rollback.