The one thing I worry about is security. How do you make low code tools flexible enough to be powerful while retaining security? On the other hand, maybe for the use cases that are well supported, these tools could provide security by default instead of relying on individual engineers to get it right.
A lot of it will be pushed down the stack into infrastructure. Infrastructure typically tails software, so over the next decade I would expect to see shifts in the infrastructure to accommodate this.
For example, I think we'll start to see more fine-grained ACLs in databases combined with passthrough authentication from the webapp. So the nocode app is basically just a layout engine that passes a query and your Okta token (or whatever) to the database, which runs the query and filters out results you personally can't access, and then nocode app formats it (basically, in a naive implementation).
IT gets to maintain control of the ACLs, and permissions become seamlessly uniform across applications. Marketing doesn't have to talk to IT get to credentials for the database and talk about security, they just set up a new app and the database makes sure that users are allowed to access that data.
That will also cause a cottage industry of tools for managing those permissions to spring up.
I would keep a serious eye on Microsoft in this space. Active Directory + SQL Server gives them serious inroads into major companies for something like this. Sharepoint is also already in the same vein. If they bought out a nocode platform, replaced Sharepoint with it and integrated the ACLs for AD and SQL Server, they could have a really compelling product in this space. It would be a perfect add-on product for Office 365, and the billing is already set up for a lot of companies.
I'd say Microsoft already has this with Dataverse/Power platform? It runs on Azure SQL Server but it is not exposed directly nor uses SQL server's ACL. Instead, the available access points -- mainly its web API -- honor the permission system configured on the platform, whether it's coming from apps themselves, custom JS code or reporting tools like PowerBI. Users are of course AD users.
Model-driven apps on Dataverse are exactly how you'd imagine MS Access if rebuilt as a SaaS product, and they integrate with Office in various ways. One Azure tenant gets one Dataverse database-- it's certainly intended to host multiple apps sharing the database.
Main problem is that building meaningful LOB applications on this type of low code platform is difficult. Works well for a toy project, or ends up being engineered solutions maintained by IT -- neither hitting the sweet spot mark. I guess general purpose low code is hard.
> For example, I think we'll start to see more fine-grained ACLs in databases combined with passthrough authentication from the webapp. So the nocode app is basically just a layout engine that passes a query and your Okta token
I think you can set that up with Postgres using row-level security and a generic "REST to SQL" frontend whose name escapes me. Harder business logic can go in stored procedures, which Postgres allows you to in a range of languages AFAIK. It seems like a great architecture to me, and it should also be some kind of simple to wrap a generator around it with a nice UI.
One of the important issues that the no-code world hasn't really come to grips with is security. Generally speaking, you have similar security issues (not exactly the same as there are no buffer overflows or js-eval/java-object injection attacks) but the code is being written by non-experts. That means all the subtle problems of faulty business logic in which end users or third parties are given too much control is going to bite you bigly.
Moreover, it's a myth that "no-code" code is easier to read or less buggy than traditional code. Moreover the lack of propery IDE support, often improper version control, and difficulty of extracting the no-code from the platform for proper analysis makes it very hard to audit in a systematic way. And the existing security tooling can't understand it. We are going to end up with piles of this stuff, often highly privileged code, written by non-experts, running on important high value systems.
