I got tired of writing the same 200 lines of boilerplate for every API, so I built a compiled language to eliminate it

Nayan Rathod — Thu, 16 Apr 2026 13:00:00 +0000

Every side project I start does the same thing to me. New idea. Open editor. Spend 2-3 days on things that had nothing to do with the idea itself. Setting up auth, writing CRUD handlers I'd written a hundred times, configuring Docker, wiring up CORS, writing validation logic, setting environment variables, pushing to a repo, figuring out deployment.

By the time I was done with the setup, I'd lost momentum on the actual product.

I tried every shortcut. Supabase. Firebase. Express boilerplates. They either locked me into someone else's decisions, added runtime overhead I couldn't control, or still required too much manual wiring.

So I did the unreasonable thing.

I spent 7 months building a compiled, statically typed programming language from scratch. Specifically designed so that your data schema is your API definition. There were at least three weekends where I was convinced I'd built the wrong abstraction entirely.

What I built and why
The language is called Doolang. I built the compiler in Rust using LLVM (via Inkwell). The core idea: if the type system understands your data model at compile time, the entire API layer, endpoints, validation, auth, rate limiting can be generated automatically. No runtime reflection. No magic strings. Just a compiler that knows what your API should look like before you do.

Here's the entire definition for a production-ready User API:

struct Task {
    id: Int,
    title: Str,
    content: Str,
    status: Int,
}

That generates:

POST /tasks
GET /tasks
GET /tasks/:id
PUT /tasks/:id
DELETE /tasks/:id

With JWT authentication, CORS handling, and rate limiting already wired in. No config needed.

The compiled binary benchmarks at 1.3+M RPS for plain text and 1.2+M RPS for JSON responses. That's not a toy. Benchmark repo

Then I built the deployment layer
A fast language that still requires you to manage Docker, DNS, Git, and cloud infrastructure isn't solving the real problem. So I built DooCloud on top of Doolang.

# Push to DooCloud

=== Deploy started: my-api ===
Generating code...
Provisioning database...
Building...
Deploying service...
Domain live: my-api-abc123.doocloud.dev

✓ Deployed to https://my-api-abc123.doocloud.dev

That deployment handles:

Git commit and push
Docker build
Container deployment on Cloud
SSL certificate
Custom domain routing
Environment variables

The whole flow schema definition to live production API takes under 5 minutes. I've timed it.

What this actually looks like
There's a live interactive playground on doocloud.dev where you can define structs and see the generated Doolang code and API endpoints in real time. No signup needed. If you want to actually deploy it, there's a free tier.
The Doolang compiler is fully open source on GitHub. 7+ months of active development.

What I learned building a language to solve a deployment problem
1. The language design forces good API design. Because your schema is your contract, you can't accidentally build inconsistent endpoints. The compiler rejects ambiguity.
2. Native binaries solve a class of problems people have accepted as normal. Most API frameworks are interpreted or JIT-compiled. The performance ceiling is set by the runtime. With a compiled binary, you're talking to the OS directly. 1.3+M RPS on my local machine. No special optimization. That's just what you get when there's no runtime in the way.
3. The hardest part wasn't the compiler. It was resisting scope creep. I caught myself planning a query language, a graph layer, and realtime sync. Then I stopped and shipped instead. Building a language makes you want to solve every problem with the language. The MVP discipline had to be applied to the language itself, not just the product.

What I genuinely want feedback on

I'm one person. This is live.

Does the schema → auto-generated API abstraction feel right, or does it feel like too much magic?
What's the first thing you'd try to break about this approach?
What's missing that would stop you from trying it for a real project?

Be mean, I can take it. That's actually why I'm posting here.

doocloud.dev - playground works without signup
github.com/nynrathod/doolang - compiler source

DEV Community: Nayan Rathod

I got tired of writing the same 200 lines of boilerplate for every API, so I built a compiled language to eliminate it