Ask HN: Problems worth solving with a low-code back end?
I have built a low-code (textual) backend builder that allows writing a backend as functions. For example, a (part) of a backend that calculates average of an integer array and then prints it out:
### average=AVERAGE([1,1,2,3,5,8]) ECHO(average) ###
Now I am trying to find problems worth solving with it to verify builder's expressiveness and limitations. So far I haven't really encountered suitable problems. I have researched many lowcode/workflow automation tools/builder and their shared use-cases or success stories, but to me they just show-case how little they can achieve.
Have you used a low-code backend builder already for some ambitious/cool problems/use-cases? Or do you have a such problem/use-case in mind? If you would evaluate a low-code backend builder, how would you do it?
40 comments
[ 1.6 ms ] story [ 101 ms ] threadFirstly I would check if it’s open source. There’s a reason companies & individuals use open source programming languages… because it’s way less risky. The same is true for a low-code language/system.
Can I version it in git? Can it be reliably tested? Can I self-host it?
As far as functionality of the low-code: is it expressive? Can I make loops, variables, conditions? Can I bundle things into reusable Lego blocks? Can I use libraries or make fetch requests? Can I add environment variables? Can I add authentication, users, permissions?
There’s a lot to evaluate with a new system, low-code or not
You should consider finding business problems that need solving with no/low code solutions which will lead you to what might need to be built. For example, if I'm building a no-code app for a Realtor persona then I might want various features that do a mathematical average.
"You should consider finding business problems that need solving with no/low code solutions which will lead you to what might need to be built." Yes, I don't want to implement more functions until I know which functions would be needed.
User <---> API <---> Business logic <---> Database
if you're testing the builder, you could just see how it goes answering leetcode problems, that sounds like the kind of problem you're talking about with the array average example.
are there any pre-existing low-code backend builders out there to compare to? i'm trying to think when i would use it. is it a code generator or will i just call the thing without reading the code myself?
Backend builder like Xano that is somewhat visual builder whereas I try to do things by using text.
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.
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!
Yes, proprietary integration tools that are the only sane way to integrate proprietary systems. You'd be better off learning some proprietary tool and selling your consulting services than rolling your own half-baked solution.
Do note that my field is quite specific; human spec does not mean some drivel with ‘I want an input box here and a login there’; it’s pretty technical specs with a lot of references to specific proprietary (the tool that’s being integrated with) language.
For me openly sold no code tools are like those ‘billionaires’ that write books and give talks about how to make money; why would I do that if it actually works? I would keep it to myself and make more money, unless, you know, it doesn’t work. Then you make more selling it to many until you get caught out.
Any sales tips you could share, please?
What I don't like about Xano is integrating database tightly, which basically means that the data is hosted by Xano. I don't know if this is required or not. Many of the BaaS platforms do this, but I prefer just connecting and processing data and not hosting data.
1. workflow tools like zapier or the BPM example. These focus on integration of external systems with minimal code.
2. A better interface than text to a complex model. Think CAD Software.
I built a lowcode UI for pandas called Buckaroo[1], along with a datatable, it works in the jupyter notebook. I wanted to make it quick to visualize and clean dataframes. I built the lowcode UI because I knew the transformations I wanted to apply to a dataframe, and I wanted a faster way to express it then typing code. Specifically I built the lowcode system to enable an expert user to express themselves more quickly, it's not built as training wheels for beginners.
Here is how I built the system:
1. I adapted Peter Norvig's lispy2.py [2] to read JSON, called it JLisp.
2. I built a simple react frontend that emits JSON commands in the format of JLisp.
3. It was very easy to define new lowcode commands, and have the frontend add them to the palette. Each command defines two methods "transform" which manipulates the dataframe, and "transform_to_py" which takes the same arguments but emits python code.
Adoption of my library in general, and the low code UI specifically has been very limited. I'm in the middle of plumbing the lowcode support back in after a refactor of other parts.
I would like to build a whole ecosystem around JLisp and Buckaroo. Specifically I have some "auto-cleaning" functionality that emits JLisp cleaning and normalization commands, these commands can then be editted in the UI (delete, edit parameters). It's easier to emit JLisp than raw python syntax, it's also much easier to make a UI to manipulate it.
Do you have a repo to look at? What usecase did you have in mind when you were building it?
If I were evaluating a low-code backend builder I'd be interested in the examples, and tests. Hopefully the tests would double as examples. For a Workflow type low-code-builder I'd be most interested in the cron functionality.
[1] https://github.com/paddymul/buckaroo
[2] http://norvig.com/lispy2.html
Already using the widget, every time I load a dataframe, I have 3-5 less notebook cells than I would normally use for adhoc analysis.
Generally speaking, the golden rule of product development is to identify the problem first, then figure out what will solve it.
Use cases range from dinky, spam riddled guestbooks to all of Facebook.
You could pound out a trivial screen or report in an hour. With SQL being a first class participant, you just interlaced SQL and logic to get your bidding done. Turn around was really fast. Having a functional TUI meant there was no time lost fiddling with placement or colors or any of that. The hardest part was squeezing everything on to a single 80x24 screen, and those high density screens were really rare. "Any color you like, as long as it's green."
I won't say it was low code, but it was certainly a lot less code. If the application fit well into the "CRUD screen/reports" paradigm, it was a lot less code. It was almost pure logic, with little need for formatting or UI. Mostly validation and deciding what fields to skip and when.
With flexibiliy comes complexity. For back office data processing, this solved an enormous swath of problems. It was pre-web, pre-json. It was not OO in any way. Code reuse was perhaps a bit more difficult that one may have liked, but at the same time, it wasn't really that necessary. Each program did its own thing, rarely did that overlap with other programs, so less need to actually share logic.
Unix processes, CRON for scheduling. We had no need for a message queue, beyond stuffing things into tables and processing stuff in batches. Workflows based on end-of-day, end-of-week, and end-of-month processes.
Honestly, never felt constrained by the limitations of the system. Not really. And, despite all of the gains and modern UXs, how pretty, and flashy, and such it is, it's just not that much better IMHO. Not for most back office use cases, not for the complexity and time it takes to create modern apps.
Still, its very hard to go back. As much as "You're not going to need it", it's hard to leave that flexibility behind, "Just in case".
1 Process manager, where you think in terms of users. Each step is a state machine. Ex: Anonymous visit has signup and contact. Registered user has update profile, upload video. To understand what process management means read up on the Mechnical Turk that played chess, and understand that a self checkout machine occasionally backed by a cashier is the same thing. Then realize you can email people asking them to do a task. And now you are programming not just with a CPU, but AI, and Humans in the circuit as well.
2 Drag and Drop Web page designer, here each of the states above, are expressed as web pages, that can shift state via UI interaction. ex. Clicking update profile, or upload video buttons. Think HyperCard, and look at the modern Bento Box Web Page Builders.
3 Visual Relational Database Builder, here you define tables, and their relationships, the form designer below will use those to help you make forms. See File Maker.
4 Form designer, just think of the form as a complex UI component. But, the button here, does not immediately shift state. So signup, must not shift state to registered until checks are made. Here a drag and drop visual programming language comes in to picture.
5 Drag and Drop Visual Programming Language, the click of a button is interpreted as a source of an object stream. Think packet oriented programming, of reactive functional programming, or RxJs, or Node-RED.
To answer your question: you evaluate a low-code builder by the ease with which it can generate entire website applications. And by generate, I mean code generation as well, because you want these programs to emit beautiful code that is indistinguishable from hand made code. For code generation see yeoman, especially AST parsing and that nifty var function: https://yeoman.io/
And of course any one of the 5 above is a good test, but all 5 in harmony are better.
As to non-visual/tui tools, its bash. shells are low code tools take a look:
AT&T Archives: The UNIX Operating System: https://www.youtube.com/watch?v=tc4ROCJYbm0
See here maybe as well: https://github.com/topics/visual-programming
So what I gather from your post is that you are describing one class of low-code designs. Maybe in your post the "backend" is within the process manager, but in BPM engines the process manager is actually more complex entity in a system what a "normal" backend would be.
So to me this is a lot more than what I want to focus on, which is the backend part in:
User <---> API <---> Backend (business logic) <---> Database
You have to disguise it, I suppose. Just make a MUD about process management things.
This will uniformly handle both you authentication needs and long standing-processes. It is only a matter of thinking up the world.
The reason this is my recommendation, is you don't seem to be interested in graphics, you want to cut them out and focus on the marrow. This is a text system.
And, you are facing a massive design challenge, this is many years of work if you want success.
How?
Well, this thing you have here "average=AVERAGE([1,1,2,3,5,8]) ECHO(average)" can become a very large device:
"Refinery is a container, it contains the averaging station, that is connected via pipe to an echoing station...
Or a very tiny device:
"User inventory contains a data pipe named echoAverage. The pipe consists of two parts, a number accumulator, and a number printer. It accepts a list of numbers and immediately returns response."
Now, let me add, you have two ways of thinking about data pipes.
The first way is where each element of a pipe is a well defined program such as "Average", "Echo". Blender has this, they have little boxes for everything you need to wrangle nodes.
And the second way, is synthetic, used in Node.js and the old languages, it is clean, and PVC white. Here you don't have components, can you believe it? No components, pure pipes. So you have, source, destination, tee (splitter), filter (drop packets), transform (map/mangle), and reduce (accumulate, queue).
In the second way you first create a beautiful data network made of tees, filters, reducers and transformers, and then you attach functions, so you would say:
source---->reducer1----transformer1---transformer2---void
and reducer1 function = take 10 nubers, or collect until transformer1 function is return add values and divide transformer2 function is echo input value, return perhaps null
So in the first approach you make a network of functions, and in the second approach you first build pipes and then attach functions.
In the MUD, I would build the pipes first, and then come in with unit tests, which would instantly fail. And then I'd make a thing that lists all the failures, and that would serve as a todo.
Now, authentication specifically, I would go for DOOM, as a heads up, and because it is funny. And when you are logged into the MUD as a developer you can enter IDKFA cheat code and get all the keys.
The reason this is not stupid, is because it is simple, and uses our navigation abilities, memory palace right? And allows you to create the graphic world in your mind, instead of in SVG.
Ask AI to create a simple MUD server for you.
Lot at Notes/Domino screenshots, or any other effort in this area, and how garbage that UI gets, it is UI gore
If you ever created a G-UI for it, it would just be Containers that can contain things (room, inventory) and things (that don't have anything inside, but may have actions, functions)
So, the developer version of your tool might as well be a heads up to Zac McCraken, or King Quest, It can be circles for rooms and lines for doors, but AI gan give you graphics.
If I was doing this, I would go for aliens (https://www.youtube.com/watch?v=efolLO2zcpc) as the UI can show AI generated door, and objects in your MUD.
You can also have an inform 7 Skein, which can be used as a unit test, as it captures moving though the MUD.
A security system can include a feature where hackers get eaten by a Grue, and maybe things from Neuromancer and Snowcrash.
Use an ORM, so you will get long lived processes for free, by default, as a function of the system.
This system is by design, multi-user, you can have many AI working to make the world better. And many developers, if you are that kind of a person.
Go with a regular database, but be mindful of how CouchDB works. The idea of a doc and revision...
https://lmatteis.github.io/react-behavioral/
I use it for simple unambitious systems in room escapes and similar, in situations where you want to be able to monitor the state of a system and make changes on the fly. The low code framework adds lots of debugging, monitoring, and logging hooks.
The system is very explicitly not meant to ever support any real programming.
You can't even create reusable functions, there's just IFTT style rules and Excel inspired =expressions.
Anything beyond that, Python already does, and I don't wanna design a new DIY general language.
I think low-code has a lot of potential, as a way to connect pieces of existing code. Things like VVVV and Excel are really nice.
But when it tries to be as general as code, it has to be careful not to just become.... code. I'll choose the common well known language over the "just right" special purpose language every time.
To me, Excel is the premier example of low-code success. It covers it's range of use cases very well with just a few high level primitives.
The interesting part isn't exactly the language although the way that they have a fairly standard and compatible batteries-included library is nice, it's the premade structure and tools optimized to work with that structure.
It's real "software" not a pure diy software kit.
In my case, I wanted to start with Excel functions, but it could be valuable to add even more functions. And to be able to write these functions in a different way than Excel does is what I am after: think of it as sequences of functions instead of placing them inside cells. Another thing is that you can't really run Excel as a backend i.e. without human intervention. Or well, there are nowadays some tools for that too, but that gets quite technical quickly.