DEV Community

Cover image for I Built a REST Microservice With a Database in 3 Files — and Wrote Zero Code
Matías Denda
Matías Denda

Posted on • Edited on

I Built a REST Microservice With a Database in 3 Files — and Wrote Zero Code

#go #microservices #devops #showdev

HCL-based runtime for rapid Go prototyping

TL;DR — Mycel is an open-source runtime that turns configuration into a real microservice. You describe what you want (this endpoint reads from that database); Mycel handles the how (HTTP server, query, marshalling, validation, retries). Same binary for every service — only the config changes. It's pure Go, speaks standard protocols, and there's one running in production behind this post. Repo at the end.

The boilerplate tax

Be honest about how your last microservice started. A router. A handler. A DTO struct. A validation layer. A database pool. A query. Marshalling the result back to JSON. Error handling around all of it. Then the next service, where you write the same seven things again with different nouns.

Most microservices aren't interesting code. They're plumbing — data comes in through a protocol, gets reshaped and checked, goes out to a store or another service. We keep rewriting that plumbing because the shape changes even though the pattern never does.

What if you didn't write the plumbing at all? What if you just declared the shape and something else ran it — the way nginx runs a web server from a config file instead of making you write the socket loop?

That's Mycel.

The whole service, in three files

Here's a complete REST API backed by SQLite. Full CRUD. No application code — just configuration.

config.mycel — what the service is:

service {
  name    = "users-service"
  version = "1.0.0"
}
Enter fullscreen mode Exit fullscreen mode

connectors/connectors.mycel — what it talks to:

# An HTTP server on :3000
connector "api" {
  type = "rest"
  port = 3000
}

# A SQLite database
connector "sqlite" {
  type     = "database"
  driver   = "sqlite"
  database = "./data/app.db"
}
Enter fullscreen mode Exit fullscreen mode

flows/flows.mycel — how data moves:

flow "list_users" {
  from {
    connector = "api"
    operation = "GET /users"
  }
  to {
    connector = "sqlite"
    target    = "users"
  }
}

flow "get_user" {
  from {
    connector = "api"
    operation = "GET /users/:id"
  }
  to {
    connector = "sqlite"
    target    = "users"
  }
}

flow "create_user" {
  from {
    connector = "api"
    operation = "POST /users"
  }
  to {
    connector = "sqlite"
    target    = "users"
  }
}
Enter fullscreen mode Exit fullscreen mode

That's it. A connector is a bidirectional adapter — it can be a source (data comes from it) or a target (data goes to it). A flow wires a source to a target. Read the config out loud and it tells you exactly what the service does: "GET /users reads from the users table."

Mycel scans the config directory recursively, so the file layout is yours to choose — one file or fifty. I keep one flow per file in real projects; here they're grouped to keep the example short.

Running it — in a container

SQLite needs its table to exist first (Mycel serves the schema you give it; it doesn't invent one). One command:

mkdir -p data
sqlite3 data/app.db 'CREATE TABLE users (
  id    INTEGER PRIMARY KEY AUTOINCREMENT,
  email TEXT,
  name  TEXT
);'
Enter fullscreen mode Exit fullscreen mode

Now run Mycel as a container, mounting your config in and exposing the port:

docker run --rm \
  -v "$(pwd)":/etc/mycel \
  -p 3000:3000 \
  ghcr.io/matutetandil/mycel
Enter fullscreen mode Exit fullscreen mode

It boots and tells you exactly what it wired up:

    ███╗   ███╗██╗   ██╗ ██████╗███████╗██╗
    ████╗ ████║╚██╗ ██╔╝██╔════╝██╔════╝██║
    ██╔████╔██║ ╚████╔╝ ██║     █████╗  ██║
    ██║╚██╔╝██║  ╚██╔╝  ██║     ██╔══╝  ██║
    ██║ ╚═╝ ██║   ██║   ╚██████╗███████╗███████╗
    ╚═╝     ╚═╝   ╚═╝    ╚═════╝╚══════╝╚══════╝
    Declarative Microservice Runtime v2.1.0

    Service: users-service v1.0.0
    Environment: development
    Port: 3000

    Connectors:
    ✓ api (rest) listening on :3000
    ✓ sqlite (database) → ./data/app.db

    Flows:
      GET    /users → sqlite:users
      GET    /users/:id → sqlite:users
      POST   /users → sqlite:users
    ✓ admin (http) health + metrics + debug on :9090

    ✓ Ready! Press Ctrl+C to stop.
Enter fullscreen mode Exit fullscreen mode

Note the last line before Ready: you also got a /health, /metrics (Prometheus), and a debug endpoint on :9090 for free — nobody declared those. Now hit the API like any other REST service:

# Create a user
curl -X POST localhost:3000/users \
  -H 'Content-Type: application/json' \
  -d '{"email":"ada@example.com","name":"Ada Lovelace"}'
# {"affected":1,"id":1}

# List them
curl localhost:3000/users
# [{"email":"ada@example.com","id":1,"name":"Ada Lovelace"}]

# Fetch by id
curl localhost:3000/users/1
# [{"email":"ada@example.com","id":1,"name":"Ada Lovelace"}]
Enter fullscreen mode Exit fullscreen mode

A working CRUD microservice. Zero lines of Go, JavaScript, or anything else. From the wire it's indistinguishable from one hand-written in Go or NestJS — it speaks plain HTTP and JSON, and a client can't tell the difference. That's the point.

(The write returns {"affected":1,"id":1} — rows affected and the new id — and reads come back as JSON arrays. That's the raw database flow talking; the next section is how you shape it into whatever contract you want.)

"Okay, but real services need more than raw CRUD"

They do. And this is where declarative stops being a toy. You add capabilities by declaring more inside the flow — not by dropping into code. Everything below lives in the same create_user flow you already saw.

Validation — define a type and attach it:

type "user" {
  email = string
  name  = string
}

flow "create_user" {
  from {
    connector = "api"
    operation = "POST /users"
  }

  validate {
    input = "type.user"
  }

  to {
    connector = "sqlite"
    target    = "users"
  }
}
Enter fullscreen mode Exit fullscreen mode

Now a bad request is rejected before it ever reaches the database:

curl -X POST localhost:3000/users \
  -H 'Content-Type: application/json' \
  -d '{"email":"x@y.com"}'
# {"error":"validation error on 'name': field is required"}
Enter fullscreen mode Exit fullscreen mode

Transforming the data — reshape the payload between from and to, with CEL expressions. The transform block sits inside the flow, right where the data passes through:

flow "create_user" {
  from {
    connector = "api"
    operation = "POST /users"
  }

  validate {
    input = "type.user"
  }

  transform {
    external_id = "uuid()"
    email       = "lower(input.email)"
    name        = "trim(input.name)"
  }

  to {
    connector = "sqlite"
    target    = "users"
  }
}
Enter fullscreen mode Exit fullscreen mode

Each line is field = "<CEL expression>". Send a messy payload and watch it get normalized on the way in:

curl -X POST localhost:3000/users \
  -H 'Content-Type: application/json' \
  -d '{"email":"ADA@EXAMPLE.COM","name":"  Ada Lovelace  "}'

curl localhost:3000/users
# [{"email":"ada@example.com","external_id":"870339c1-9e53-498c-8217-c350556f284b","id":1,"name":"Ada Lovelace"}]
Enter fullscreen mode Exit fullscreen mode

Email lowercased, name trimmed, a UUID generated — declared in three lines, applied before the write.

Retries with backoff — for when a downstream is flaky, add an error_handling block to the flow:

error_handling {
  retry {
    attempts = 3
    delay    = "1s"
    backoff  = "exponential"
  }
}
Enter fullscreen mode Exit fullscreen mode

Want to swap SQLite for PostgreSQL? Change the connector — the flows don't move. Want to consume from RabbitMQ instead of HTTP? Change the from. The flow is the stable thing; the edges are pluggable. Mycel ships connectors for REST, PostgreSQL, MySQL, MongoDB, Kafka, RabbitMQ, gRPC, GraphQL (Federation v2), Redis, S3, WebSocket, and more — all behind the same connector block.

What this isn't

Two honest disclaimers, because the concept invites two wrong assumptions:

  • It's not an orchestrator. Mycel doesn't supervise other services — it is a microservice. If the process dies, Kubernetes (or Docker, or systemd) restarts it, exactly like any service in any language. What Mycel handles is keeping your in-flight data safe across that restart — broker redelivery, idempotency, retries. (That's its own post.)

  • It's not magic for genuinely custom logic. When you need behavior no connector or transform expresses, Mycel runs WASM plugins — you write that one piece in Rust or Go, compile to WebAssembly, and the runtime calls it. The declarative model bends to real logic; it doesn't pretend logic doesn't exist.

Why I built it

I got tired of the gap between "this service is conceptually trivial" and "this service is still 800 lines of boilerplate I have to write, test, and maintain." nginx closed that gap for web serving. Terraform closed it for infrastructure. Mycel closes it for microservices: the binary is the same everywhere, and the configuration is the program.

It's pure Go, no CGO, one static binary. There's a real service running on it in production right now — which is what convinced me this wasn't just a neat idea.

Try it

If the idea of declaring a microservice instead of writing one is interesting (or infuriating), I'd genuinely like to hear it in the comments. Next post: what happens to a config-driven service when the power goes out — the part everyone assumes a declarative tool gets wrong.

Mycel is open source and early. Stars, issues, and "this would never work because…" arguments all welcome.

Top comments (6)

Collapse
 
mickyarun profile image
arun rajkumar •

Love the concept for rapid prototyping and internal tools. The zero-code approach is perfect for getting something running fast.

Where it gets interesting is what happens when you need to add the non-obvious parts: input validation that goes beyond type checking, retry logic with specific backoff curves, health checks that actually test downstream dependencies, and env management across multiple services.

Those are the things that turn '3 files' into a real production service. The scaffolding gets you to the starting line — the engineering gets you across the finish line.

Collapse
 
mdenda profile image
Matías Denda •

Totally agree — that's exactly the line between a demo and a service, and it's the part I care most about. The bet Mycel makes is that those four things are configuration concerns, not code concerns, so they stay declarative instead of becoming the 2,000 lines of glue you write by hand. Quick tour of how each one looks today:

Validation beyond types — constraints on the field plus custom validators (regex, CEL, or WASM):

type "signup" {
   email    = string({ format = "email" })
   age      = number({ min = 18, max = 120 })
   password = string({ min_length = 12, pattern = "..." })
   plan     = string({ enum = ["free", "pro"] })
   tax_id   = string({ validator = "valid_vat" })   # custom CEL/WASM rule
}
Enter fullscreen mode Exit fullscreen mode

Retry with real backoff curves — not just "retry N times":

error_handling {
  retry { 
    attempts = 5  
    delay = "1s"  
    max_delay = "30s"  
    backoff = "exponential" # or linear / constant
  }  
}
Enter fullscreen mode Exit fullscreen mode

(plus circuit breaker, and per-error-class dispositions like ack/retry/requeue/reject).

Health that actually probes dependencies — /health/ready doesn't just return 200; it pings every connector (db.PingContext, Redis PING, etc.) and reports per-component status. mycel check runs the same probes before the service accepts traffic.

Env management — an env() function, per-environment overlays (environments/prod.mycel), .env support, environment-aware defaults (debug logs + hot reload in dev, JSON logs + locked-down errors in prod), and connector profiles to swap backends per environment.

You're right that the engineering is what gets you across the finish line — the goal here is just to make as much of that engineering declarative as possible, so what's left is your actual business logic. Docs for each are in the repo if you want to poke holes in it (genuinely welcome — that's how it gets to production-grade). 🙏

Collapse
 
harjjotsinghh profile image
Harjot Singh •

zero-code-to-running-microservice is the fun demo, but the honest test is what happens at file #4. the 3-file version is clean; the question is whether it stays clean when you add auth, a migration, rate limiting, error handling. that's usually where 'zero code' quietly becomes 'a lot of code i didn't write and don't understand'. did you push it past the demo into something with real auth + persistence yet?

Collapse
 
mdenda profile image
Matías Denda •

That's exactly the right test, and the fairest pushback I've gotten — a 3-file demo is easy to make look clean. So let me answer directly: yes, it's pushed well past the demo. The runtime already does real auth (JWT, argon2id hashing, TOTP, WebAuthn, brute-force lockout), DB-backed persistence, migrations, rate limiting (incl. a distributed variant), and error handling (retry, circuit breaker, DLQ, per-error-class dispositions). If you want to see file #4 rather than take my word for it, the auth example in the repo is a single config with persistence + JWT + MFA + brute-force + sessions + audit — that's the "what happens when you add the hard stuff" file.

But the part I want to push back on is "a lot of code I didn't write and don't understand." That framing assumes codegen. Mycel isn't a generator — it's a runtime, like nginx. There's no generated code to inherit. File #4 is more config, not a pile of opaque Go.

So the real tradeoff isn't "clean → hidden code," it's "clean → more config." And I'll own the honest version of that: complexity doesn't vanish. Auth is inherently complex, so the auth config is genuinely more involved than a 3-line flow. What you trade is writing and maintaining the how for learning the vocabulary for the what. Your nginx.conf grows as you add TLS, caching, and rate limiting, but it never becomes C you maintain.

Where the "zero code" promise has to stay honest is when you outgrow the vocabulary. For that, there's an explicit escape hatch — a WASM plugin — and that is code you write and own. I'd rather have a clear seam than pretend the declarative model covers 100% of cases.

Collapse
 
syedahmershah profile image
Syed Ahmer Shah •

This experiment highlights the rapid evolution of no-code tools and their growing role in prototyping. While this approach is excellent for validating concepts quickly, I would be interested in seeing how it handles complex business logic or migrations as the project scales beyond three files.

Are you looking to explore how these no-code microservice architectures compare to traditional frameworks in terms of long-term maintainability?

Collapse
 
mdenda profile image
Matías Denda •

Great questions — and they get at the thing I probably undersold in the post: the "3 files / zero code" is the headline, but Mycel isn't no-code in the Bubble/Zapier sense. It's declarative — closer to nginx or Terraform than to a visual builder. The runtime interprets config; you're not clicking boxes, you're describing what you want and the engine owns the how. And it's built to run in production, not just to prototype — I run it in prod today.

On your specific points:

Scaling beyond 3 files: it scales by composition, not by one giant file. Config is split by concern across recursively-scanned directories — connectors/, flows/, types/, transforms/, aspects/, etc. A real service is dozens of small files, each reviewable in isolation. Three files is just the minimal demo.

Complex business logic: there's a ladder. Most logic is CEL expressions in transforms/filters; multi-step orchestration uses step blocks; cross-cutting concerns (audit, notifications, auth) are aspects (AOP) applied by pattern-matching flow names; validation is declarative types + custom validators. And when something genuinely doesn't fit declaratively, the escape hatch is WASM plugins — you write that piece in Rust/Go/etc. and the runtime calls it. So the declarative layer handles the 90% and you never lose the ability to drop to real code for the 10%.

Funnily enough, I shipped a feature today that's exactly about "more than a trivial write": a transactional, multi-statement write primitive — clean previous rows, insert a parent, capture its autoincrement id, loop over N children that reference it, all atomic in one DB transaction, declared in HCL. That's the kind of "complex" that used to force you back into code.

Migrating an existing service into Mycel (say a NestJS service, or a Mulesoft/iPaaS flow): the key enabler is that a Mycel service is indistinguishable on the wire — same REST/GraphQL/gRPC endpoints, same queues. So it's not a big-bang rewrite; you do it strangler-fig style: stand Mycel up behind the same contract and cut over route-by-route (or flow-by-flow / queue-by-queue), keeping the old service running until each piece is proven.

The fit depends on what the service actually is. Integration-heavy services map almost 1:1 — Mulesoft especially: a Mule flow → a Mycel flow, DataWeave → CEL transforms, Mule connectors → Mycel connectors. NestJS depends on the glue-vs-domain-logic ratio: the integration/orchestration glue re-expresses cleanly as config, while rich domain logic either becomes a WASM plugin or simply stays where it is — Mycel can call your existing service as a step and orchestrate around it, so migration is incremental rather than all-or-nothing. To be straight: there's no automated NestJS→Mycel transpiler. It's a manual re-expression — but a mechanical one, and the stable-protocol boundary means you're never forced to move it all at once.

Maintainability vs traditional frameworks: the trade is real and worth being honest about. What you gain: config diffs are trivially reviewable, there's no framework-upgrade churn (same binary, your config doesn't rot), and hot-reload means changes apply without redeploys. What you watch out for: logic that's awkward to express declaratively — that's the signal to reach for a WASM plugin rather than contort the config. I'd genuinely like to write up that comparison properly; it's a fair thing to want data on.

Appreciate the thoughtful read 🙏