Ask HN: Problems worth solving with a low-code back end?
14 comments
You aren't wrong - back around 2010 BPM/workflow automation was in a hype cycle, but many projects ended up being high-code anyway as they didn't live up to expectations.
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.
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.
WAAAAAAAY back when I was working for IBM briefly, I had an opportunity to play with Notes/Domnio briefly. I was impressed how far you could go with the system, and even in 2003-2004, pretty floored that the tech dated back to the late 80s.
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)
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)
Ha, I was a Domino person for WAY longer than anyone should have been. Even ran a modern SaaS off of it with a React front-end. I KTed it off to a new dev team just last year, believe it or not.
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.
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.
Interesting story! Sounds surprisingly adaptable technology, which makes me wonder why it has not been brought to this data - or maybe it has been...
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.
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.
Thank you for mentioning Lotus Notes Domino. ChatGPT gave a lot of interesting material: especially I can see some similarities between how I use functions and how Lotus Domino Notes Formula Language was used.
The builder uses OpenAPI spec to define and implement the API. The backend aims to do what "normal" backend does: fulfills requests by executing business logic (written as functions, a form of DSL) and querying database.
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!
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!
I think of lowcode tools in two classes.
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
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
Oh, your project is really nice! Maybe doing some marketing might bring more people to your project? I am having kind of similar issue: "What usecase did you have in mind when you were building it?" Actually, I wanted to make writing a backend as easy as it is for python developers to use Jupyter Notebook. Jupyter Notebook's UI is fantastic and great example of text-based interface although it is not only text-based.
[deleted]
I wanted to be able to quickly clean data frames and view them. I want sensible defaults, and even sets of defaults that I can quickly toggle between. I also want the widget to be extensible easily.
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.
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.
The code part of low code is the easy part. It's integration with other things: API's, database engines, etc. The point of low-code is to give people without a coding ability the ability to connect systems together and perform transforms on the way, wrapping a SQL database with unique business logic and routines, or respond to real world events in an easy fashion (user purchases product, object state transitions from X to Y, a file appears in an FTP directory or a cloud storage bucket, an email is received, etc)
Well, integration is one aspect, and there are low-code tools like node-red etc. for those use-cases. One category of low-code tools is workflow automation tools, which maybe you are describing mostly. For me, I am interested in writing the business logic using functions. And what comes to the actual backend the data flow is the "normal" one:
User <---> API <---> Business logic <---> Database
User <---> API <---> Business logic <---> Database
> Have you used a low-code backend builder already for some ambitious/cool problems/use-cases?
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.
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.
So you have examples of those proprietary tools? I know quite a lot and integrated with many of them; if you can do code, it’s trivial, so writing a no code solution to do it is usually really easy; I do that for my own consultancy. Just a few clicks and sellable for 1000s$ per client, but not in any mass/saas setup, as then it has to be a lot easier to use and a lot less error prone on wrong inputs when setting up everything. But for me it’s really fast; even faster with LLMs; now my tooling can work with human spec -> my spec language (which is industry and process specific) -> working code, iac, test data, benchmarks and tests.
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.
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.
That's simple - I just can't sell it like you do. I would love to, I am trying my best, but I just can't get the clients. Getting clients for a low/no-code tool is much easier, albeit way less profitable.
Any sales tips you could share, please?
Any sales tips you could share, please?
How I see it is that Integration applications are different from what I understand as a backend: API+business_logic+Database
I've worked pretty extensively with custom low-code stuff, but not for anything particularly technically ambitious.
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.
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.
Thank you for your response! I too think that Excel is a premier example of low-code success: especially if you think that who is it low-code for - business people. Many times I find technical people (me too) engaging these low-code discussions so that they forget that low-code and no-code should be powerful enough to bring power of programming to groups of non-technical people.
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.
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.
The only no/low-code backends I've seen that are worth anything are data migration tools like fivetran that do ETL/ELT from source data to target and let you apply some basic transformation. Even then, they have a very low ceiling before you need python or SQL to do anything useful.
Generally speaking, the golden rule of product development is to identify the problem first, then figure out what will solve it.
Generally speaking, the golden rule of product development is to identify the problem first, then figure out what will solve it.
"Generally speaking, the golden rule of product development is to identify the problem first, then figure out what will solve it. " You got me there, but it all started as a hobby project which got out of my hands :)
My most productive time was early-mid '90s using a 4GL for green screen applications.
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".
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".
And it just not flexibility without a reason. At least in B2B web apps, some customers always need to have something that's not in the core of the product but in order to get them on board business people push for a long tail of infrequently used features. More features and code is a liability - not an asset
In context of creating hyper useful applications low code means 5 things.
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
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
1) Good point about the "Humans in the circuit". I think that when people talk about process manager they are referring to long-standing processes
2) I'll take this to be the frontend part
3) I'll take this to be the database part
4) I'll take this to be one component of the frontend part
5) I'll take this to be tool for designing long-standing processes
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
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
This is similar to MUD style programming, just reduced to a poor minimum:
https://lmatteis.github.io/react-behavioral/
https://lmatteis.github.io/react-behavioral/
What you need is a MOO MUD.
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 and GUI, is something that would fit the old world where muds were special. It is an eventual consistency storage that you can just rsync folders.
If I was making a MUD I would develop it on Probably a RPI4 or equvalent SBC, but, I would try to see what it would take to get it all going on an RPI Zero ... it is a world of text, it will tell you when your MUD is slow. And when you bring it to modern machines, you can laugh at everybody else's performance.
Can't use Java here, so ANSI C or just something slightly above it, that is almost as fast.
Because you seem to be rejecting graphics, make it fast.
Look at https://en.wikipedia.org/wiki/RAML_(software) for an outside of the world editing perspective, as opposed to working from within the mud.
As to the rest, MUD it is just a colorful https://raw.githubusercontent.com/wiki/webmachine/webmachine... with emergent properties, that makes use of human abilities, such as navigation.
For the naysayers, this is LLM/AI compatible, so it could be a lot less effort than it seems.
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 and GUI, is something that would fit the old world where muds were special. It is an eventual consistency storage that you can just rsync folders.
If I was making a MUD I would develop it on Probably a RPI4 or equvalent SBC, but, I would try to see what it would take to get it all going on an RPI Zero ... it is a world of text, it will tell you when your MUD is slow. And when you bring it to modern machines, you can laugh at everybody else's performance.
Can't use Java here, so ANSI C or just something slightly above it, that is almost as fast.
Because you seem to be rejecting graphics, make it fast.
Look at https://en.wikipedia.org/wiki/RAML_(software) for an outside of the world editing perspective, as opposed to working from within the mud.
As to the rest, MUD it is just a colorful https://raw.githubusercontent.com/wiki/webmachine/webmachine... with emergent properties, that makes use of human abilities, such as navigation.
For the naysayers, this is LLM/AI compatible, so it could be a lot less effort than it seems.
Any low-code backend builder implies there is code being written. Functions/methods like the example you have are literally part of most Math libraries in whatever language is in the backend - Ruby, Python, PHP, Java, Perl, etc.
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. 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.
"Any low-code backend builder implies there is code being written." True, in my case functions form a DSL which means abstraction.
"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.
"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.
do people use "low-code backend builders"? i'd never heard of that concept at all
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?
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?
"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.
Backend builder like Xano that is somewhat visual builder whereas I try to do things by using text.
yes, for example the aforementioned Xano. And thank you for throwing out the idea to implement leetcode problem solutions. This helps to compare expressive power of the functions against established programming languages!
Check out Xano, a very mature tool that tackles that. They found an early fit supporting front end platforms like Glide, WeWeb, etc.
Good point about supporting frontend platforms like Glide! And indeed it is quite close to what I am building: https://www.xano.com/technology/ and it seems that they are doing it with funding too "Xano has raised a total funding of $15.4M over 3 rounds from 2 investors".
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.
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.
> If you would evaluate a low-code backend builder, how would you do it?
Firstly 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
Firstly 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
Checklist
- open source. This I would do my self too, but only because I am a technical person
- version control. Agree, but in my case only API will be available for you to version (versions are of course in backend too)
- testing. Agree and this is important. But what kind of testing? Would end-to-end tests be enough i.e. separated env with data set and Postman?
- self-hosting. Private SaaS anyone?
- functionality: thanks for reminding me of the importance of loops, variables, and conditions. These can be implemented.
- authentication and authorization. Definitely required for mature software!
Sounds like you just invented PHP.
Use cases range from dinky, spam riddled guestbooks to all of Facebook.
Use cases range from dinky, spam riddled guestbooks to all of Facebook.
Simplified, higher-order version of it because of the DSL!
Which sounds a lot like early versions of PHP: https://en.wikipedia.org/wiki/PHP#Early_history
how to open the hacked account on Facebook
### 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?