Seeking an Answer: Low Code

I'm fairly sure No Code is an abysmal pit of despair for just about everyone who actually knows anything about code. But "Low Code" is a bit more nebulous. How much code is "low" code? And is it a good thing.

I think done right that the answer is "yes". But, I'm going to put it to the test and actually try something. My personal philosophy is this:

Low code should refer ONLY to the effort required to produce the final project. The actual output should be "all" code.

First what I mean by that:

• Providing a combination of libraries, components and code generation tools which reduce the amount of code required and to a limited extent reduce the amount of upfront knowledge required.
• Examples are things like "dotnet new" or "ng add component" or the toolkit in Visual Studio for adding WinForms elements or even the just something like a NuGet that makes it easy to add a new feature like FastEndpoints or YARP.
• Put another way, it is any tooling or code generation which produces actual code or provides functionality which makes it quicker and easier to deal with either domain specific boiler-plate code (getting a new project created, creating basic CRUD endpoints, etc...) or tooling which helps address non-domain specific challenges (authentication, proxies, etc...)

And why:

• If you chose "low" code instead of No-Code you either know or fear that your project is more complex than an out of the box offering can solve. But, that also means that so long as there are constraints which stop you from fully controlling the code, there is a likelihood that even a low code solution will put up barriers if what it actually produces is black-boxed at any point.
• Generating the full code and making it available makes it portable. The user can take the code and maintain it. If my tooling fails to keep up on security best practices or the project dies, it doesn't take your project down with it.
• Repeatability. A project which produces code in one framework or language can (especially if designed as such) be reworked to output in other languages or frameworks.

And why not:

• Downgrading developers. Too much emphasis on tooling which makes things too easy and completely abstracts away the actual code results in a workforce which is unable to cope with complex and novel issues.

With that, I'm starting my project which will basically take a YAML description of the server and UI and "transpile" that definition into a .Net 7 based back end and Angular UI. It will add some tooling to assist with on-going development and code re-generation. 

The goal is to produce something which can generate 80-90% of the UI for the app I wrote for my brother's shop and 80-90% of the scaffolding for the back end. I will still own 100% of the business logic aside from what is purely boilerplate. And that is because I don't believe it is feasible to do that effectively in a no/low code setup to begin with.

The longer term goal will be to add future transpilation targets and prove (or improve until) it is able to quickly and easily iterate on new technologies leaving only the need to port the guts of the business logic.