Low-code approaches have been effective for building simple systems for reading and writing data. However, they fall back to low-level code for business logic. The underlying assumption is that domain-specific logic requires domain-specific-code.
That’s a problem – backend business logic often comprises nearly half the system. Manual coding is slow, which can be frustrating to Business Users, who can state requirements in terms that are both clear, and many-fold more concise than code.
Our Solution: Low Code Plus Logic Model Automation
Ideally, we can build on the concept of Low Code, and extend the notion of models to include Logic Models, that express our backend business logic in Business User terms, and are n-fold more concise than code.
We describe here such an approach, called API Logic Server (open source, available on GitHub).
Model Driven Creation
API Logic Server creates complete, executable projects from a database schema. Use your existing tools and techniques to create a schema, and then use the API Logic Server Command Line Interface to create a system like this:
ApiLogicServer create-and-run --project_name=ApiLogicProject --db_url=<db-location>

Creation of a new project (with its associated models) with API Logic (click on the image to enlarge it)
Let’s see in more details some of the key aspects of our approach.
Note: the created sample project is available on github, here, where you can explore the models and code.
Model Generation – not Code Generation
Code generation is not a new technique. It can be fast, but is viewed with skepticism since it is often rigid, and results in code that is hard to read and maintain.
The diagram above shows that API Logic Server creates models, not code. It requires no background in Python or complex Web technology (APIs, UI frameworks) to understand the created models which are mostly self-explanatory. They can be easily understood, and modified – they are declarative models that describe what to do, not how.
These models are executable, using runtime engines that are part of API Logic Server. The created system provides an Admin User Interface and API as shown below:

Generated API to access the business data
Promotes Agile Collaboration, Based on Working Software
In moments, that single create command has created a project – working software, ready for collaboration with Business Users or review with clients. Business Users can review the running screens, and provide feedback about the data model (“wait, customers have multiple addresses”), or business logic requirements (“we need to check credit”). More about that shortly.
Model Driven Customization – Alter and Extend the Created Models
As noted above, it’s quite simple to use your IDE or text editor to alter the UI and API models above. For example, you can drop end-points in the API, or alter the UI for captions, attribute ordering and so forth.
Extensible Automation – Add Logic Models, Code as Required
In addition to altering created models, you can add new functionality as described below.
Add Logic Models
As they explore the created application, Business Users will naturally identify logic requirements. We can capture these in a tool such as Behave (a Test Driven Development tool that captures requirements and executes test suites). In our example shown below, line 15 identifies a Check Credit requirement. How do we turn this into a design understood by developers, and an implementation understood by computers?
The logic design is captured as comments (lines 55-60). In this non-automated process, we translate business terms into something developers can understand and implement. While this is really just free text, it is a good design – it’s declarative, in that it states what is required, not (much more voluminous) pseudocode that describes how to do it.
In fact, the logic design is so clear we can infer the logic not only for adding orders, but a whole set of additional User Stories. For example, it’s clear we should reduce the balance if the order is deleted, or the ShippedDate is set). Or, more subtly, we should adjust 2 balances if the order is moved to a different customer.
Traditionally, we turn this design into code. If we wrote all this code by hand, it totals over 250 lines.
By contrast, lines 63-74 illustrate a Logic Model. You declare spreadsheet-like rules, which are a direct, parseable translation of the logic design: an Executable Design. The actual entry process uses the code completion services of the IDE.
Rule declaration is performed in your IDE (shown below) using code completion. The IDE is also used for debugging. Other code management tools (e.g, source control such as git) also work naturally.
Unlike the traditional design / code process, there is no further translation of this model into code. These rules are directly executable by a logic engine, which operates as a listener to SQLAlchemy (Object Relational Manager for Python). Like a spreadsheet, the engine:
- Watches for changes to attributes reference by rules
- Reacts, by executing the referencing rule,
- Chains, to execute other rules dependent on the referencing rule (e.g., a Quantity change computes the Amount, which chains to adjust the AmountTotal, which chains to adjust the Balance)
So, 5 rules instead of 200 lines of code, automating multi-table transaction logic:
For logic that cannot be automated by rules, the system also provides for conventional events, coded in Python (not shown here).
Note: logic is implemented by incorporating the Logic Bank project. If you already have approaches for SQLAlchemy model creation, Admin Apps and APIs, Logic Bank is separately available, designed to be used with any SQLAlchemy project.
Extend the API
In addition to the end-points resulting from each table in the API Model, you can code your own end-points as shown below. Note the code is short, since it utilizes the declarative logic shown above.
Use Existing Tools – IDE (Code Edit/Debug), Source Control (e.g., git)
The screenshots above illustrate that the project can be customized and debugged in popular IDEs, such as VSCode or PyCharm.
Plans
The current implementation has many downloads, and is in use at a number of sites. There is interest in extensions, such as:
- User Interface (hide/show based on condition, improved master/detail add)
- Security
- Aggregate multiple databases in a single API
- NoSQL
- Infrastructure – serverless, kubernetes
Summary: Models Provide Low Code for Developers
Model-based automation provides an effective Low-Code environment that can dramatically reduce time to market, and reduce risks from complexity and requirements mis-match. Provisions for extensibility mean that developers can complete the non-automated tasks using familiar tools and languages.
This system is open source, available on github. You can install and create the sample app in well under an hour. The created sample project is available on github, here, where you can explore the models and code. The authors would love to get your feedback.

For years, my focus has been to make it as simple and easy to deliver database systems, as it is to imagine them. I have been deeply engaged with App Dev for many decades.
I led the design and implementation of PACE, Wang’s highly regarded DBMS with over 6500 installed sites. It provided a relational query engine with rule enforcement, an application builder, and a query/report writer. I was awarded several patents for rules and application generation.
I was a technical co-founder and CTO of Versata, a J2EE app dev system with over 700 sites. Funded by the founders of Microsoft, SAP, Ingres and Informix, it went public in 2000 with an IPO exceeding $3B.
I co-founded Espresso Logic with Max Tardiveau, where we created a rule-based API Server. It was acquired by CA (now Broadcom).
I am now an independent consultant, residing in the Bay Area. Having a ball on Open Source & Python with API Logic Server: 1 command to create an API, and a basic web app, with spreadsheet-like rules for transaction logic – extensible in Python: https://github.com/valhuber/ApiLogicServer#readme
Beyond Brilliant, Val, Congratulations. What’s the minimum size for a VPS to run the Dockerized stack?
Thanks so much for your kind comments.
Sorry, I am not a Docker/Linux expert, but I test it on a 16g MacBook Air, runs well.
Thanks, Val. I just bought a 2.5G Ubuntu VPS…I think it’s going to be sufficient, as 0.5 to 1 GB is recomended for Ubuntu, and a bit for Docker, MySQL, and Python…
Not familiar with VPS, but as I said, a MacBook Air works fine.
If you are fiddling with MySQL, I have done that too. To save a bit of time:
ApiLogicServer examples # will show sample URLs
This page can provide access to some docker DBs, including MySQL, just to get started quickly: https://github.com/valhuber/ApiLogicServer/wiki/Testing#docker-databases
Thanks very much, Val. I instinctively lean toward the most recently updated, but APT makes it really easy to update. Thanks for the suggestion, and all the work maintaining the Docker images.