Table of Contents
The Plumbing Problem Nobody Talks About Honestly
Most microservices are not difficult because they contain uniquely hard business logic. They are difficult because each one arrives carrying the same luggage: an HTTP server, routing, request parsing, validation, database access, query handling, JSON responses, error paths, configuration, and operational endpoints. A team may have solved those problems before, perhaps many times over, but a new service still tends to begin with another scaffold and another stack of familiar files.
That repetition is not always waste. Custom code can be the right choice when the service has complicated rules, unusual security requirements, long-running work, or behaviour that does not map neatly to a database operation. But a great deal of internal API work is simpler than that. It is a controlled way to read and write records. For those cases, hand-writing every layer can become ceremony mistaken for engineering.
That is the problem a developer named Matute Tandil is trying to address with Mycel, an open-source runtime that replaces application code with configuration. Mycel is a zero code microservice runtime that turns plain config files into working REST APIs with full CRUD support. Rather than asking developers to construct a service from handlers upward, it asks them to describe the shape of the service: which endpoint reads from which database table, which components are connected, and how requests should move through the system.
The runtime then takes responsibility for the repetitive machinery. Mycel handles HTTP routing, query execution, JSON marshalling, and validation automatically, with no application code required. The distinction matters. This is not simply a code generator that produces a project developers must then own and maintain. The pitch is that the same binary runs every service and only the configuration changes.
It is an nginx-style mental model applied to microservices. Nobody expects an nginx user to write the socket loop before defining a route; the binary supplies that machinery and configuration expresses the desired behaviour. Mycel asks why the layer above the network should always be rebuilt by hand, especially when the endpoint is essentially an interface to stored data.
What a Zero Code Microservice Actually Looks Like
The structure is deliberately small. A complete zero code microservice backed by SQLite needs exactly three configuration files and a single Docker command to run. The first file defines service identity, including its name and version. The second declares connectors: one for the HTTP server and one for the database. The third wires those components together using flows.
That economy is the central appeal. A service definition can be reviewed as a statement of intent rather than as an implementation spread across routers, data-transfer objects, query code, validation code, and response models. For a developer or operator trying to understand a basic CRUD API, the important questions become visible quickly: what comes in over HTTP, which database is involved, and how the request is connected to it.
A connector in Mycel is a bidirectional adapter. It can be a data source, a data target, or both. An HTTP REST connector listens for incoming requests. A database connector speaks to SQLite, PostgreSQL, or whatever driver has been configured. A flow is the binding between them: it states how the HTTP side and the database side are connected so the runtime can carry out the request.
That model puts Mycel in a useful middle ground. It is more structured than a loose collection of scripts and more direct than building a conventional service for every database-facing endpoint. It also avoids a common trap in “low-code” discussions: treating reduced typing as the only benefit. The larger benefit is consistency. If routing, validation, query execution, and JSON marshalling are provided by one runtime, they do not need to be separately designed—or inconsistently designed—inside each small service.
The Operational Parts Are Included, Not Deferred
A quick API demo often leaves out the things that make a service supportable after it is deployed. Mycel does not. Built-in Prometheus metrics, health checks, and a debug endpoint come free with every Mycel service, declared or not.
That “declared or not” detail is more consequential than it first sounds. Observability is routinely treated as work to add later, after the endpoints are operating. In practice, later can mean never, particularly for small internal services that appear too simple to warrant attention. When a service is behaving badly, however, the absence of health information and metrics is not a minor omission. It turns a straightforward operational question into a hunt through logs, infrastructure settings, and assumptions.
Making those facilities universal also establishes a baseline. A service built from a small configuration should not have to sacrifice the basic signals expected from an application written by hand. Mycel’s approach suggests that operations should be a property of the runtime, not a reward for teams with enough time to add it themselves.
Where the Model Fits—and Where It Does Not Pretend to Fit
Zero code is a deliberately provocative label, and it should be read precisely. Mycel removes application code for the kind of REST API it is designed to express; it does not remove the need to understand the data model, the API surface, validation, or the consequences of exposing database-backed operations. Configuration is still a form of engineering. A bad flow or a poorly considered endpoint remains bad, even if it is much shorter than the equivalent code.
Nor is the value proposition that all microservices should become configuration files. The further an application moves from ordinary CRUD work, the more likely custom behaviour becomes the important part. The useful claim is narrower: developers should not need to reimplement standard HTTP-to-database plumbing every time the problem is standard HTTP-to-database plumbing.
For small APIs, prototypes, internal tools, and services whose job is principally to expose existing data, that is a credible challenge to convention. A three-file SQLite service launched with a single Docker command is not merely a party trick if it lets a team move from an agreed data interface to a running REST service without maintaining another pile of boilerplate.
Mycel’s bet is that the unglamorous parts of microservices have become standardized enough to be infrastructure. If that bet holds for a given service, the payoff is not that developers write less for its own sake. It is that they spend their attention on the parts that actually differ: the data, the contract, and the decisions behind both.
