---
title: "So Close: The Near Nirvana of Hono and Cloudflare Workers | DJ Petersen"
description: "Cloudflare's stack is powerful but lacks the integrated developer experience of past platforms. Here's why."
canonical: "https://www.thedjpetersen.com/llm-thoughts/so-close/"
---

# So Close: The Near Nirvana of Hono and Cloudflare Workers

## Cloudflare's stack is powerful but lacks the integrated developer experience of past platforms. Here's why.

Apr 9, 2025

![Cloudflare's stack is powerful but lacks the integrated developer experience of past platforms. Here's why.](https://www.thedjpetersen.com/_astro/so-close.A0uKFoBU.png)

If you were building web apps around, say, 2010, you might remember the combination of Ruby on Rails and Heroku. You'd run `rails new`, write your code, and deploy with `git push heroku master`. It wasn't perfect, but for a huge range of applications, it was a remarkably productive, low-friction way to get from zero to a running app. That kind of integrated experience is harder to find today.

Now look at Cloudflare. They offer Pages for static hosting, Workers for compute right at the edge, D1 for a database, and R2 for object storage. Paired with a framework like Hono, built for the edge, you get impressive speed and scale. Getting started is fast, and the deployment pipeline via Git integration is genuinely seamless – push your code, and Cloudflare handles the rest. For deploying static assets and serverless functions, the developer experience is excellent.

It's *so close* to a complete, integrated platform. The foundation is solid, and much of the workflow is automated beautifully. The friction point, the part that doesn't yet match the ease of the deployment pipeline, is integrating the database. Configuring D1 bindings in `wrangler.jsonc` and managing database migrations remain separate, manual steps compared to the automated flow for code deployment. It's the last piece needing that same level of seamless, schema-driven automation.

hypothetical wrangler.jsonc (Schema-Driven)\[1 highlights\]1

| 1 | // hypothetical wrangler.jsonc (Schema-Driven) |
| --- | --- |
| 2 | { |
| 3 | "name": "my-edge-app", |
| 4 | "main": "src/worker.ts", |
| 5 | "compatibility\_date": "2024-03-18", |
| 6 | "schema": "./prisma/schema.prisma" // Point to the schema file |
| Note This illustrates the **ideal** `wrangler.jsonc`. Instead of manual configuration sections (like `d1_databases`), a single `schema` key points to the definition file. In this scenario, Wrangler/Cloudflare would read `./prisma/schema.prisma` (shown next) and **automatically configure** the necessary D1 bindings (and potentially others like KV or R2 defined within) and handle database migrations during deployment. This declarative approach removes the manual wiring friction point. |  |
| 7 | } |

This manual configuration works, but it requires careful coordination. The ideal future, discussed in the blog post, envisions a more integrated system where configuration is derived directly from a declarative schema, similar to how ORMs like Prisma operate. Imagine defining your data structure like this instead:

hypothetical schema.prisma (The Ideal)\[1 highlights\]1

| 1 | // hypothetical schema.prisma (The Ideal) |
| --- | --- |
| 2 | datasource db { |
| 3 | provider = "sqlite" // Would map to D1 |
| 4 | url = "env(DATABASE\_URL)" // wrangler.jsonc binding handled implicitly |
| 5 | } |
| 6 |  |
| 7 | model User { |
| 8 | id Int @id @default(autoincrement()) |
| 9 | email String @unique |
| 10 | name String? |
| 11 | } |
| Note This illustrates the **ideal** scenario discussed in the blog post. By defining a schema like this (using a tool like Prisma), the necessary `wrangler.jsonc` bindings and database migrations could potentially be handled **automatically** upon deployment. This contrasts with the manual configuration required in the `wrangler.jsonc` example shown above, removing a significant friction point. |  |

The problem today is that defining that nice `schema.prisma` file doesn't actually \*do\* anything for your Cloudflare configuration or database state. You still have to manually edit `wrangler.jsonc` to add the `d1_databases` configuration, making sure the `binding` name matches what your code uses and the `database_id` matches the database you clicked to create in the dashboard. Then, you have to run `wrangler d1 migrations apply` separately. Get any of it wrong, and things just don't work. It's error-prone busywork.

What's needed is something closer to the old Rails magic. Imagine a`hono new --with-database` command that scaffolds your app, sets up the schema file, \*and\* links deployment to automatically configuring the bindings in `wrangler.jsonc` and running any necessary database migrations. You define your data model once, and the platform handles the plumbing. That's the goal.

Cloudflare clearly has the technical pieces. They have the network, the compute platform, the data services, and Hono is a great fit. They are very close to offering a genuinely integrated, batteries-included platform for edge development. They just need to provide that last layer of tooling and automation to smooth over the developer experience rough spots.