I can't help but wonder how that basic engine that drove Notes/Domnio could be replicated with HTML/JS/SQLite/REST/OAuth2 nowadays, and be right at home aside these low-code systems, especially if modern UI/tooling/graphing/data connections could be iterated on the system. (As well as eliminating/solving all the jank that came with notes/domino)
Because you are absolutely correct - while the client side of that platform was a disaster, the underlying database and its built-in everything was a powerhouse. We ran about 50 million daily requests to the databases, and although we did load balance it to multiple data centers, we also tested it successfully all running off a single server.
Not that I recommend it today - too little talent who knows it, too much baggage around the bad UX from people who don't actually know it, the wrong pricing, and while it does scale quite well up to tens of millions of records and requests, it gets complex after that point, requiring integration with external resources to hold indexes, etc, so even if you did scale it to billions, you've lost that "one server to rule them all" concept that made it so easy to work with.
All that being said, the killer feature of it was how baked in auth was - It had groups, roles, and granular security baked into the platform, even down to field-level security and encryption. So anywhere you wanted to write code, you knew exactly who the user was and what access they had. Everything else about that platform is sufficiently replicated in modern frameworks, except for that
To bring this nostalgic review back to the current point, if I wanted to build a low-code system that would truly meet a variety of use cases, that is were I would focus - auth.
And thank you for your answer: auth in terms authentication of authorization is usually the first of "hard" things when real usage is tried. Basically nothing prevents me from integrating Keycloak to my backend as functions are just higher level abstractions.
The very basic example of calculating average is just another type of "hello world" example. Separated frontend like a static html page can call API with an integer sequence and gets the average as the response.
But your example of processing a form resonates, because most of the webapps are represented as some sort of forms. I will work with it to further develop the DSL. Thank you for the suggestion!
But your example isn't low-code in the same way as any of that - it is just a different syntax for a fairly simple function. So I'd ask what your builder actually does?
At a "table stakes" level, low code back-end needs to focus on business needs, not running basic functions: Approval cycles, form submissions, those kinds of things. I'm biased from all my old Enterprise IT experience, but I'd say that if your builder cannot show how you'd build a basic process of: "Create Form" -> "Send to Approver" -> "Approve" -> "Send the approved data somewhere", then you probably aren't at MVP yet.