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>

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:

 

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.