Liwiro: Making Service Delivery Less Dependent on Manual Plumbing

The limiting factor in software is no longer only the ability to write code. Ideas can be explored quickly, but turning them into reliable software still takes a lot of people-hours: define an API, create the project, connect data and authentication, deploy it, document it, test it, and keep it healthy after requirements change. Each task is reasonable on its own. Together, they make developers the narrow point through which every product idea has to pass.

Liwiro is built to widen that narrow point. It does not treat a service as a folder of generated code that is forgotten after day one. It treats a service as a living contract with a managed lifecycle.

Start with a contract, not boilerplate

Liwiro uses LAPIS, a JSON-based service definition. A LAPIS document captures four things:

• service metadata
• authentication rules
• data models
• API endpoints

An operator can compose that document in the Service Builder, edit the raw JSON, or upload an existing file. The platform validates it before generation. This matters because the same structured definition is later used for inspection, updates, documentation, testing, and regeneration.

That is a meaningful difference from a one-off scaffold. With a scaffold, the original intent and the running system tend to separate over time. With a living contract, the platform has a shared description of what the service is supposed to be.

What happens after generation

When a LAPIS contract is submitted, Liwiro validates it, generates a Flask-based API, allocates a free local port, starts the service as a managed child process, waits for it to become available, and stores its contract and runtime information. The service can then expose ordinary CRUD routes, more controlled VQL data operations, or Versa-powered procedural endpoints.

The generated service also has a documented operational path. In the Service Manager, an operator can inspect health and logs, replay example requests, update the contract, restart or stop the process, and delete the service when it is no longer needed. Runtime documentation is generated from the contract as well.

Why the operational layer is the point

Code generation only saves time at the beginning if the team has to leave the generator to manage everything that follows. Liwiro keeps the lifecycle together:

1. Describe the service.
2. Validate the description.
3. Generate and launch it.
4. Test and document it.
5. Change the same contract as the service evolves.
6. Restart only when runtime-affecting behaviour changes.
7. Clean up the process, registry entry, and service data when it is removed.

This gives teams a faster default path for the repeatable parts of service delivery, without hiding the system from the people responsible for it.

Clear boundaries make automation safer

Liwiro does not give the browser direct control over the database or language runtime. The frontend talks to the backend, and the backend owns validation, credentials, transport selection, process management, and permission checks. Generated services handle their own requests, while platform authentication, generated-service authentication, and database authorization remain separate concerns.

Those boundaries are practical. Automation can make change cheap, but cheap change without clear authority makes systems fragile. Liwiro is designed to make the common path faster while keeping consequential operations inspectable.

The role of Verun

Liwiro sits on top of Verun. VDB provides persistent data operations, while the Versa interpreter provides a route for custom logic when plain data operations are not enough. The frontend and backend turn those low-level capabilities into a service-design and operations workflow.

The combined result is simple: humans should spend more of their time deciding what software ought to do, checking that it does it safely, and improving the edge cases. They should spend less time recreating the same service plumbing for every new idea.