Choosing The Best Backend Framework
Why I Stopped Asking the Wrong Question
Most articles about backend frameworks compare Laravel, Django, Express.js, ASP.NET Core, and Ruby on Rails. They produce a table with performance scores and learning curves, conclude that "the best framework depends on your needs," and send you off none the wiser.
I spent years in that conversation. I have shipped things in .NET, worked with PHP projects, and know Express well enough to have opinions about it. But for the last few years, the backend stack I actually reach for on new projects is Cloudflare Workers with Hono - and the more I use it, the more I think the traditional framework comparison is asking a question that has quietly become less relevant for a wide range of web projects.
This is not a universal argument. Traditional frameworks are the right answer in plenty of situations, and I will be precise about that. But if you are building APIs, form handlers, data integrations, or lightweight backend logic for websites and applications - the kind of work that makes up most of what DignuzDesign does - the edge-first approach is worth understanding before you default to setting up a Django server.
What Edge Computing Actually Means for a Backend
When you run an application on a traditional server - whether it is Express on a VPS, Laravel on shared hosting, or ASP.NET Core on Azure - your server lives in one physical location. A user in Helsinki and a user in Singapore are both making requests to the same machine. The user who is geographically closer gets a faster response. This is a hard constraint of how the internet works.
Cloudflare Workers runs your code in over 300 data centres distributed globally. When a request comes in, it is handled by the location closest to the user. There is no round-trip to a central server. The code runs where the request originates.
For most of the projects I work on - property websites with contact forms, enquiry APIs, booking request handlers, content APIs that serve data to Astro front-ends - the difference between 200ms and 20ms response time is not academic. It is the difference between a form that feels instant and a form that feels like it might not have worked.
Hono: A Framework That Was Actually Built for This Environment
The reason traditional frameworks do not run on Cloudflare Workers is not a configuration problem - it is an architecture problem. Frameworks like Express were built in 2010 for Node.js. They assume a full Node.js runtime with access to the filesystem, TCP sockets, and a persistent process. Cloudflare Workers does not have those things. It runs on the V8 isolate model: lightweight, stateless, and deliberately constrained.
Hono was built from scratch for this environment. It uses only Web Standard APIs - the same APIs that work in every modern browser and every JavaScript runtime. Its core is under 14kB with zero dependencies. According to Hono's own benchmarks, it processes over 400,000 requests per second in Workers, significantly faster than alternatives designed for the same environment. On the Cloudflare platform, Hono is first-class: Cloudflare's own internal tooling runs on it.
Here is what a basic Hono API endpoint looks like on Workers:
import { Hono } from 'hono'
import { zValidator } from '@hono/zod-validator'
import { z } from 'zod'
type Bindings = {
DB: D1Database
}
const app = new Hono<{ Bindings: Bindings }>()
const enquirySchema = z.object({
name: z.string().min(2),
email: z.string().email(),
propertyRef: z.string(),
message: z.string().min(10),
})
app.post('/enquiry', zValidator('json', enquirySchema), async (c) => {
const data = c.req.valid('json')
await c.env.DB.prepare(
'INSERT INTO enquiries (name, email, property_ref, message) VALUES (?, ?, ?, ?)'
)
.bind(data.name, data.email, data.propertyRef, data.message)
.run()
return c.json({ success: true }, 201)
})
export default appThat is the entire handler. Zod validation, D1 database write, typed bindings. No middleware configuration file, no ORM to configure separately, no server to spin up. The Worker deploys globally in seconds with wrangler deploy.
D1: SQLite at the Edge Is a Bigger Deal Than It Sounds
One of the persistent criticisms of serverless backends is that the compute is stateless but the database is not - so you end up with low-latency compute routing requests to a high-latency database sitting in a single region. Cloudflare's answer to this is D1, a managed SQLite database that runs on their edge network.
D1 is not a replacement for Postgres or MySQL in every situation. It is SQLite, which means it has the strengths and limits of SQLite: excellent for read-heavy workloads, straightforward to query, portable, and genuinely fast when accessed from co-located Workers. The official D1 documentation covers the architecture clearly - D1 databases replicate reads globally, so query latency for reads scales with your geographic user distribution rather than being bottlenecked to a single server location.
For what I actually build - property enquiry databases, contact form logs, content data that backs Astro sites, user preference stores - D1 is entirely sufficient. The 10GB per-database limit encourages sensible schema design and discourages the pattern of piling everything into one sprawling database. I run multiple small databases, one per project, rather than a shared database that becomes a dependency between unrelated projects.
Pricing follows a scale-to-zero model. There are no charges when the database is idle, and no egress fees. For client sites that receive moderate traffic, the cost is effectively zero at the scale of their usage.
The Stack in Practice: What I Actually Ship
For a typical property developer website, the backend I build is:
Hono on Cloudflare Workers handles API routes - contact forms, property enquiry submissions, viewing request handlers, newsletter signups. Each route validates its input with Zod, writes to D1, and optionally triggers a downstream action like sending a notification via a queue.
D1 stores form submissions and lightweight application data. R2 stores uploaded files - floor plans, documents, anything that needs persistent object storage. Better-Auth handles authentication where the project needs a client portal or agent login.
The front-end is typically Astro, which calls these API endpoints from server-side route handlers during build or at request time. The whole system deploys from a single repository with GitHub Actions triggering Wrangler for the Workers side and Cloudflare Pages for the front-end. There is no server to SSH into, no deployment pipeline to maintain beyond the Actions file, and no hosting cost beyond what Cloudflare charges per request.
I have written about the real estate web application development context in more detail elsewhere, but the short version is that for this category of project, the edge-first stack consistently outperforms a traditional server setup on every dimension I care about: latency, maintenance overhead, cost at scale, and deployment simplicity.
Where Traditional Frameworks Are Still the Right Answer
Being honest about limits is more useful than overselling an approach.
Cloudflare Workers has a CPU time limit per request - the free tier is 10ms, the paid tier allows up to 30 seconds for most operations. This is not a problem for API handlers and database queries, but it rules out CPU-intensive work like image processing, PDF generation, or running ML inference synchronously in the handler. For those tasks, Workers can offload to a queue or call an external service, but if your application is fundamentally compute-heavy, a traditional server is the right architecture.
Workers also runs in the V8 isolate model, which means no access to the full Node.js API surface. If you have existing Node.js code that relies on fs, native bindings, or a long list of npm packages that assume a full runtime, porting that to Workers requires effort. For greenfield projects this is a non-issue. For migrating an existing Express or Fastify application, it may not be worth it.
For complex, data-intensive applications with deep relational models, complicated queries, and multiple teams working across the codebase - Django and Laravel both provide genuinely excellent tools. Django's ORM is mature and powerful. Laravel's ecosystem is large. If you are building something like a full property portal with hundreds of thousands of listings, complex search indexing, and application-level access control across multiple user roles, you may be better served by a framework that has evolved specifically for that pattern.
My heuristic is this: if the backend is primarily moving data between a client and a database, validating inputs, and triggering downstream actions, the edge-first stack is almost always better. If the backend contains significant business logic, complex relational operations, or integrates deeply with an existing ecosystem, a traditional framework warrants consideration.
The Maintenance Argument Is Underrated
Something that rarely appears in framework comparison articles is the ongoing cost of keeping a server alive. A VPS running Express or Django requires operating system updates, dependency updates, security patches, monitoring, and occasional debugging of infrastructure problems that have nothing to do with the application. Over a year of running five client sites, this cost accumulates.
Cloudflare Workers has no server to maintain. There is no operating system, no Node.js version to keep current, no SSH access to lose track of. The platform handles security at the infrastructure level. When Cloudflare updates their runtime, your code benefits without any action on your part.
For a solo developer managing multiple projects simultaneously - which is the reality of running a studio rather than working inside a large engineering team - this operational simplification is not a minor convenience. It is a meaningful reduction in the cognitive load of keeping client work healthy. The time I am not spending on server maintenance is time I am spending on building things.
The custom web development work I do is shaped by this constraint: projects need to be maintainable after delivery, by a team that may not have deep infrastructure expertise. A Workers + D1 backend is significantly more maintainable in that context than a self-hosted application server.
How to Actually Decide
Skip the comparison table. Ask these questions about your specific project:
What does your backend actually do? If it is mostly request handling, validation, and database reads and writes, Cloudflare Workers is a serious candidate. If it involves significant CPU work per request or deep integration with existing Node.js infrastructure, look at traditional options.
Who maintains it after launch? If the answer is "a non-technical client team" or "a small agency with multiple projects to manage", prioritize the option with the lowest operational overhead. This is almost always the edge-first stack.
What is the traffic pattern? Workers scales to zero automatically and charges per request. For sites with irregular traffic - a property development that launches with a surge and then settles - this is cheaper and simpler than a server sized for peak load.
Do you have TypeScript experience? The entire Workers + Hono + D1 + Drizzle stack is TypeScript-native, with type safety that propagates from database schema through to API response and into the front-end client if you use Hono's RPC features. If your team is comfortable in TypeScript, this is a genuinely excellent developer experience. If they are not, Django or Laravel may be a better fit given their more established documentation and community resources.
FAQ: Backend Framework Questions I Actually Get Asked
Is Cloudflare Workers reliable enough for production use?
Yes. Workers processes tens of billions of page views monthly on Cloudflare's infrastructure, including Cloudflare's own internal tooling. Hono is used by Baselime (acquired by Cloudflare) and in production by large engineering teams. The reliability question comes from conflating the early days of serverless - when cold start times and instability were genuine issues - with the current state of Workers, which runs in V8 isolates rather than containerised processes and has effectively zero cold start time.
Can I use an ORM with Cloudflare D1?
Yes. Drizzle ORM works well with D1 and is the ORM I use in production. It is TypeScript-first, has a minimal footprint that fits within Workers' size constraints, and generates type-safe query builders from your schema definition. Prisma also supports D1 through an adapter, though its bundle size is larger and requires some configuration to work within Workers limits. For simple projects I write raw SQL directly - D1's prepared statements API is clean and the queries are straightforward enough that an ORM adds more abstraction than value.
How does Hono compare to Express for developers who know Express?
The mental model is similar enough that Express developers pick up Hono quickly. Routing, middleware, and handler patterns all work in familiar ways. The main differences in practice are that Hono uses Web Standard APIs rather than Node.js-specific APIs (so c.req is a standard Request object, not Express's req), and that Hono's TypeScript support is significantly better - the context object carries type information through middleware, and the RPC client generates typed functions from your route definitions. The adjustment from Express to Hono took me less than a day on the first project.
What about Laravel or Django for real estate projects specifically?
Both are capable of building real estate backends, and there are mature ecosystems of tools for property search, IDX integration, and content management in both. The question is whether those capabilities justify the operational overhead relative to what your project actually needs. A property developer website with a contact form, a listing database, and an enquiry handler does not need the depth of Django's ORM or Laravel's Artisan tooling. The complexity matches the problem, and in this case the problem is not complex enough to justify the traditional server approach. If the project is a full property portal with advanced search, saved listings, user accounts, and complex business rules - that conversation changes.
Is there a resource for learning the Cloudflare Workers + Hono stack?
The Cloudflare Workers documentation is well-maintained and covers the platform comprehensively. Hono's documentation at hono.dev is clear and includes practical examples. The official Hono guide for Cloudflare Workers covers environment bindings for D1, R2, and KV with working code examples. I would recommend starting by building a small API with a single D1 database, deploying it with Wrangler, and making real requests to it before drawing conclusions about whether the architecture fits your project.
