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

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

#go #microservices #devops #showdev

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 (2)

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 🙏