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

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"
}

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"
}

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"
  }
}

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
);'

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

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.

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"}]

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"
  }
}

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"}

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"
  }
}

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"}]

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"
  }
}

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

• Repo: https://github.com/matutetandil/mycel
• This example: it's in examples/basic — clone it and docker run (or grab the binary)
• Docker: ghcr.io/matutetandil/mycel

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.