I've seen "low code" and "no code" solutions running at huge enterprises and it always inevitably ends up resembling a house of cards.
Proponents often cite how much quicker they can ship things and how it lets users define and automate their own workflows without waiting for engineers. The reality is that these time savings come by cutting corners from the development cycle. Because you're not doing "code", the code review step gets skipped. The authoring of automated test suites get skipped. The authoring of performance regression testing gets skipped. There's no waiting for things to bake in non-prod environments because people are changing settings directly on prod. No ones doing phased deployments with automated rollbacks here in these low code and no code environments. No design reviews mean you get solutions that are the absolute worst hacks.. Why go through the work of making "priority" a first class property on your ticket type when you can just string scan for "high" | "medium" | "low" on case titles when doing assignments?
Engineering teams could also move fast if they just threw maintainability to the wind. There's a reason they don't. If you do things the right way in these low/no code environments, the complexity is even worse, because the features are so half-baked that you can't setup proper safeguards without doing crazy amounts of escape-hatches.
From a coding perspective taking over these houses of cards are my favorite kind of project. If the spreadsheet (or whatever) is used to build a system that people start relying upon then the proof of concept is already done, the underlying domain model is fleshed out and the task prioritization is obvious.
Greenfield projects where requirements are vague, priorities are vague, the underlying domain model is vague and the need for the project to exist at all is dubious bug the shit out of me.
One of the most successful companies I ever worked at kickstarted many new business processes with a few guys importing, munging and exporting data from a spreadsheet and sending emails. It was manual and often repetitive. But, all the iteration happened in the background until they nailed down what was needed and then came to me with a set of crystal clear, validated requirements.
It was quite a contrast to all of those other companies where I was given a feature to write that took a week to knock out because a powerful customer said it would be cool to have. Inevitably, even they only played with it for 5 minutes before never using it again and nobody else even touched it once.
Or the other companies that went to the other extreme and treated random excel spreadsheets as fully fledged production systems that would trigger catastrophe if you looked at them funny.
I can't help but feel that there's a sweet spot somewhere here that most people (& low code companies) miss.
I been at one very large enterprise for the last 15 years; the amount of low/no code apps I've been through is...well you know when neo is in the matrix, he is shown the previous matrix versions by the architect? its that feeling, but in this case there is no version of reality where there is a win. The biggest problem I see even if this were to work, is that you don't really want non-developers using these tools. Who's to blame when the low/no code user makes a booboo ? These people typically don't want this burden, so I've always seen it pushed back to a developer...and the requests are usually beyond the scope of the low/no code tool such that it eventually always becomes a worse burden for devs than code
In my experience there is one situation where no code shines, namely, in enterprise support and deployment assisting software.
I've worked at a company that sold products to enterprise. There you have programmers writing complex features but you also have complex per-client requirements. Basically, software engineers maintained a nocode product that support / solution engineers use (not so much end users). So yes, there is a real programmer in the loop, but surprisingly, things also often get done without involving this programmer.
So many good points here, best summary of the problem of no code I've read yet. Whether you write lots of code or no code, all the principles you mentioned remain i.e. testing, deployment complexity, maintainability, rollback, release strategies etc. If you tried to do all that in a no code environment it would be horrendous. If you skip it, as a non engineer might, you're courting catastrophe.
No code will often make little sense for a lot of "proper" software if you want something maintainable, extensible, safe, performant (add other engineering principles here). It's probably very useful for non devs to build tools and cobble things together, in a similar fashion to how Excel can replace certain programming tasks. Just don't build your whole system from these things.
I think it's important that people respect the limits of these, no doubt useful, tools. We should also respect us software engineers and understand why we do things in the way we do. It might seem too complex but you might be suprised how complex, potentially unsafe and limiting the alternatives can be.
It turns into a house of cards even when professionals use it.
Oracle Apex is a great tool for simple CRUD and reporting apps. But as systems grow big, you start to have complex flows, integrations with other tools (for file conversion, image manipulations, etc). and it becomes a big mess.
Yeah, the biggest flaw with the low/no code solutions is that end users want, and get, access to how the workflow works and/or it ends up this giant hero workflow handling every single possible scenario.
Best to keep the task simple, pick up the response, do some sort of identification, pass on it to where it should go. That's it. Let the next destination handle more stuff.
The challenge of programming is not really about writing in a programming language - it's about thinking, problem solving, and organization.
What low/no-code does is remove the setup and tooling barrier. I believe it's this barrier which scares most people away from programming. After all, even as an experienced software developer, I find some languages more intimidating because of the many tooling choices and setup options required before one can actually do something useful (front end development, anyone?).
Ruby on Rails did this for web development 20 years ago. It's way more complex now (partly because our expectations and desires are so much more complex), but when it was new it was essentially low-code compared to alternatives. And just with modern low-code systems, people who aren't good at thinking or structuring often create bad or unreliable things.
I'm sure more than a few of us have seen some of the monstrosities created by users with Excel. On the other hand, some non developers have created brilliant solutions in Excel. The same will be true of official no-code tools.
Where no-code can really benefit most, is by allowing some end users to attempt to solve their own problems. Chances are they won't end up with complete solutions, but they may end up with a clearer picture of what it is they want; and then they can go to professional developers and better communicate their needs. Maybe we'll end up throwing away less work as our solutions will better match the users' needs.
Exactly that. Also in my expereince as a Data Science consultant was that by far the best approach was to just rebuild what they attempted in excel in python. Also now that I think of it Excel is the original low code solution haha
Let me tell you: no/low-code solutions can be just as hard as if not harder than actual code in some cases. One of the more difficult engineering solutions I have had to implement in my career was with a tool called Tasktop, which synchronizes different requirements analysis tools like Jira, Jama, GitHub Issues, etc. No actual code is involved (unless you need to add customization scripts), but you definitely want experienced engineers creating these integrations, as there are a great deal of software engineering concepts that need to be understood in order to understand and create successful integrations. So “democratization” of programming is misleading for low/no-code solutions, as non-programmers will quickly find themselves in trouble and eventually hand off the solution to a an actual software engineer.
Yeah, my face twitches whenever I see "no-code" solutions erect edifices of loops, conditionals, workflows, formulae, versioning and clever IDEs. I wonder if whoever POs this stuff is just oblivious to just how deep this rabbit hole of turing completeness goes.
It's bad enough when ansible does conditionals and loops with YAML. It's 10x worse when somebody thought they'd made the process easier because you have to drag and drop a box. There comes a point when most of these systems should just hand over control to a popular programming language with decent tooling OR a person and they almost always fly right past it.
It’s not that low code isn’t hard, it’s that it isn’t code. Which for the life of me I will never understand. But I’ve seen entire businesses run on linked spreadsheets with formulas that would melt your brain. All built by people terrified of “code”.
The problem with many low-code platforms is three fold:
- many over-promise and under deliver. Low code platforms are great for simple CRUD apps, defined automations, etc.
- some, like Bubble, are anti-code to their own detriment - code is good, your platform was created with code
- only a few, like Budibase [1], Tooljet [2], n8n [3] are open source. I cannot understand how users are willing to bet their data and processes on closed source tooling
Looks like you are associated with Budibase from your previous submissions & ideally you should have disclosed it to let others reading your comment understand your bias
You can checkout Obsei as well: https://github.com/obsei/obsei. It is Apache 2.0 licensed.
It an open-source low-code cognitive automation tool. It observes unstructured text from various sources like app reviews, social accounts etc and then apply NLP tasks like sentiment analysis, classification and then inform/intimate user at given platform like slack, api etc. Currently support text based automation workflows but in future plan to include audio, video, and image as well.
All this posts miss the best low code environments of all time: Microsoft Access and FileMaker Pro. Unfortunately these two never made it to Internet era in big time and we have greatly come down from 90s RAD movement.
I got into real software development by writing a inventory management tool using MS Access back in the day.
It worked great! The application even looked almost like a normal Windows app. I wrote all of it by myself without knowing much coding (though I did write lots of VBA).
What I'm generally amazed by is MatLab. They went from a general Math IDE to being an actual physics simulation environment...that now transpiles the symbolic flow based programming view to an external C-compatible library.
With this solution they are the only alternative, dominating whole industries with it. There are so many engineers with a no-coding background that literally build programs that end up as parts of firmwares on controllers...through MatLab.
Whether that's good or not (from the security point of view) is up for discussion. But I'm kind of amazed by the "compiler pipeline" that they achieved.
Imagine something like this combined with LLVM and an LSP based backend that also integrates a no-code way to implement fuzz and unit tests.
Am I the only one here who remembers MS Access? It was a great no-code/low code product that created silos of information in many organizations and it was a real PITA to transfer it to other technologies.
The advantage in MS Access was that it was part of the MS ecosystem and used VBA which is well documented. What will happen when you'll want to transfer something you've made in today no-code solutions to another platform?
What if i tell you, code is the "no code" tool itself.
Why ?
You of course could run any code with assembly or machine language, but now we have high level programming languages, it's because we want "low-code", or "low machine-code".
The point is we want to map business problems/solutions into machine, code is just a "no code" tool which allows u to do that.
Yep. The problem is not that that programming languages are create an undemocratic force field around programming, it's that only very few people can efficiently translate any sort of requirements into any sort of machine-comprehensible instructions, doesn't matter if it's code, excel formulas, multitude of ERP checkboxes or something else.
The high demand and pay of the last few decades brought a lot of people into trying to be those few but it looks like the percentage of the "worthy" people remains as low as it was decades ago and move from Fortran to lowcode did nothing.
The thing I'm finding hard to get my head around is people who are arguing that various languages such as COBOL or Python are, or might be considered low code or no code.
To anyone who needs to hear this: if it's code based programming then it's not no-code or low-code - it's code.
Well, the goal of COBOL was to make something that everyone could use, so that professional programmers would be obsolete. It didn't succeed, and it doesn't look like "no code" to us today, but the goal was the same.
But it's never really "no code". There's always "code", because you always have to tell the system what you want the program to do. However you tell it that, that description becomes the code.
COBOL and 'modern' Fortran (aka FORTRAN 66) where very much designed with the goal of making programming something that 'everybody' could do without having to learning about actual programming and computers and all that 'boring' stuff.
Each one involves telling your computer some logic, but on the left you have to be much more detailed and the computer makes fewer assumptions than on the right. Is Hasura Code or No Code™? I write some SQL or a GraphQL query, but I also click around and set permissions and relationships in a GUI.
For me, the low code perspective is a little different.
I think that no/low code is the secret end goal for any B2B line of business product. You eventually want to be able to have sales engineers directly setting up your products for customers, with developers standing by to support or enhance the shared code pile. You never want to be in a situation where you need 1 developer and code pile per customer when you are trying to capture an entire market segment with hundreds or thousands of businesses.
Once you figure out all the likely paths through the jungle, you can expose configuration and scripting at the various decision points.
Our specific flavor of "low" code leverages SQL and projections of business state to allow for very precise tuning of certain logic. Being able to employ SQL to solve problems implies a very intimate understanding of the problem domain. You have to do battle with the business and iterate the model until you know 99% of it will never have to change. Anything less than this is walking across quicksand, as changes to schemas per already-configured customers quickly turns into a nightmare factory of regressions and otherworldly suffering.
There aren't enough people who go into coding because most people simply dislike coding. I've seen it many times and don't blame them. I love coding, but dislike chemistry and statistical analysis. It's just not my thing
Since this is likely not going to change, these no-code tools expand the number of workers who can do stuff. But it clearly isn't as good as coding and never will be
> In the past decade, the growth in low-code and no-code solutions...
The articles then shows that it is far from a "past decade" thing.
Low-code, no-code, RAD, or whatever you want to call it has always been a thing. Code is an obscure thing to the uninitiated, and it costs a lot of money to hire the initiated. So of course people want to make it more accessible. Today is nothing new, if anything, it tends to go the other way: people are getting more comfortable with code.
And the article explains it very well, in fact, it is one of the best overview I've seen. It takes about Excel, the most successful "low-code" platform, UML, which is mostly a failure, and modern takes like Copilot which offer guidance but do not try to hide the code.
The conclusion however seems to be "I don't know", told in a particularly convoluted way in entire chapters. I think the article would have been better if it didn't try to predict the future.
The contributions of communities in the growth of programming languages is huge. If no-code/low-code is looking at a similar trajectory, open-source frameworks might prove to be the best options.
> Extending fundamental software development practices like version control, automated testing, and continuous deployment to other low-code and no-code tools sounds like a job for programmers, and one that’s still on the to-do list.
This, so much this!
The amount of wilfull low-code ignorance of standard, 20-year+ old best practices for producing reliable software is mind-boggling.
Integrate with standard version control. Have a textual representation of your source. Integrate with standard CI/CD.
No, you are not a special snowflake. And no, no one wants to have to use your cloud SaaS build tools vs something they can own, integrate, and run themselves.
Like isn't a turing complete language proven to be the highest level one can go to be able to do anything required with code?
Everything past that reduces the amount of code but also reduces the number of things the code can do and at some point in the code reduction, it's just a declarative language?
Its all shades of gray between imperative/functionsl and declarative.
Democratization of code will be the same as the democratization of medicine: anyone can go to a pharmacy and buy aspirin, ibuprofen, vitamins, etc. That doesn't mean physicians are jobless. Also if you have some serious problem or disease you shouldn't self medicate, but get professional treatment.
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.
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.
[+] [-] bilalq|4 years ago|reply
Proponents often cite how much quicker they can ship things and how it lets users define and automate their own workflows without waiting for engineers. The reality is that these time savings come by cutting corners from the development cycle. Because you're not doing "code", the code review step gets skipped. The authoring of automated test suites get skipped. The authoring of performance regression testing gets skipped. There's no waiting for things to bake in non-prod environments because people are changing settings directly on prod. No ones doing phased deployments with automated rollbacks here in these low code and no code environments. No design reviews mean you get solutions that are the absolute worst hacks.. Why go through the work of making "priority" a first class property on your ticket type when you can just string scan for "high" | "medium" | "low" on case titles when doing assignments?
Engineering teams could also move fast if they just threw maintainability to the wind. There's a reason they don't. If you do things the right way in these low/no code environments, the complexity is even worse, because the features are so half-baked that you can't setup proper safeguards without doing crazy amounts of escape-hatches.
[+] [-] pydry|4 years ago|reply
Greenfield projects where requirements are vague, priorities are vague, the underlying domain model is vague and the need for the project to exist at all is dubious bug the shit out of me.
One of the most successful companies I ever worked at kickstarted many new business processes with a few guys importing, munging and exporting data from a spreadsheet and sending emails. It was manual and often repetitive. But, all the iteration happened in the background until they nailed down what was needed and then came to me with a set of crystal clear, validated requirements.
It was quite a contrast to all of those other companies where I was given a feature to write that took a week to knock out because a powerful customer said it would be cool to have. Inevitably, even they only played with it for 5 minutes before never using it again and nobody else even touched it once.
Or the other companies that went to the other extreme and treated random excel spreadsheets as fully fledged production systems that would trigger catastrophe if you looked at them funny.
I can't help but feel that there's a sweet spot somewhere here that most people (& low code companies) miss.
[+] [-] beanjuiceII|4 years ago|reply
[+] [-] adrianN|4 years ago|reply
[+] [-] amitport|4 years ago|reply
I've worked at a company that sold products to enterprise. There you have programmers writing complex features but you also have complex per-client requirements. Basically, software engineers maintained a nocode product that support / solution engineers use (not so much end users). So yes, there is a real programmer in the loop, but surprisingly, things also often get done without involving this programmer.
[+] [-] jmfldn|4 years ago|reply
No code will often make little sense for a lot of "proper" software if you want something maintainable, extensible, safe, performant (add other engineering principles here). It's probably very useful for non devs to build tools and cobble things together, in a similar fashion to how Excel can replace certain programming tasks. Just don't build your whole system from these things.
I think it's important that people respect the limits of these, no doubt useful, tools. We should also respect us software engineers and understand why we do things in the way we do. It might seem too complex but you might be suprised how complex, potentially unsafe and limiting the alternatives can be.
[+] [-] forinti|4 years ago|reply
Oracle Apex is a great tool for simple CRUD and reporting apps. But as systems grow big, you start to have complex flows, integrations with other tools (for file conversion, image manipulations, etc). and it becomes a big mess.
[+] [-] hk1337|4 years ago|reply
Best to keep the task simple, pick up the response, do some sort of identification, pass on it to where it should go. That's it. Let the next destination handle more stuff.
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] blunte|4 years ago|reply
What low/no-code does is remove the setup and tooling barrier. I believe it's this barrier which scares most people away from programming. After all, even as an experienced software developer, I find some languages more intimidating because of the many tooling choices and setup options required before one can actually do something useful (front end development, anyone?).
Ruby on Rails did this for web development 20 years ago. It's way more complex now (partly because our expectations and desires are so much more complex), but when it was new it was essentially low-code compared to alternatives. And just with modern low-code systems, people who aren't good at thinking or structuring often create bad or unreliable things.
I'm sure more than a few of us have seen some of the monstrosities created by users with Excel. On the other hand, some non developers have created brilliant solutions in Excel. The same will be true of official no-code tools.
Where no-code can really benefit most, is by allowing some end users to attempt to solve their own problems. Chances are they won't end up with complete solutions, but they may end up with a clearer picture of what it is they want; and then they can go to professional developers and better communicate their needs. Maybe we'll end up throwing away less work as our solutions will better match the users' needs.
[+] [-] lysecret|4 years ago|reply
[+] [-] temporallobe|4 years ago|reply
[+] [-] pydry|4 years ago|reply
It's bad enough when ansible does conditionals and loops with YAML. It's 10x worse when somebody thought they'd made the process easier because you have to drag and drop a box. There comes a point when most of these systems should just hand over control to a popular programming language with decent tooling OR a person and they almost always fly right past it.
[+] [-] listless|4 years ago|reply
[+] [-] foxbee|4 years ago|reply
- many over-promise and under deliver. Low code platforms are great for simple CRUD apps, defined automations, etc.
- some, like Bubble, are anti-code to their own detriment - code is good, your platform was created with code
- only a few, like Budibase [1], Tooljet [2], n8n [3] are open source. I cannot understand how users are willing to bet their data and processes on closed source tooling
[1] https://github.com/Budibase/budibase
[2] https://github.com/ToolJet/ToolJet
[3] https://github.com/n8n-io/n8n
[+] [-] kinj28|4 years ago|reply
[+] [-] lalitpagaria|4 years ago|reply
Disclaimer: I am creator of Obsei
[+] [-] miohtama|4 years ago|reply
[+] [-] brabel|4 years ago|reply
It worked great! The application even looked almost like a normal Windows app. I wrote all of it by myself without knowing much coding (though I did write lots of VBA).
[+] [-] andrewstuart|4 years ago|reply
Far, far ahead of its time.
[+] [-] nielsbot|4 years ago|reply
Surprisingly you can pay to have your DB hosted on AWS. That said, it's very expensive.
[+] [-] ksec|4 years ago|reply
I still think Low-Code is a problem worth solving and it should start with spreadsheet like structure.
I am wondering if there are any Low-Code / No-Code solution for Web CRUD Apps? Something like Yahoo! Pipes...
[+] [-] cookiengineer|4 years ago|reply
With this solution they are the only alternative, dominating whole industries with it. There are so many engineers with a no-coding background that literally build programs that end up as parts of firmwares on controllers...through MatLab.
Whether that's good or not (from the security point of view) is up for discussion. But I'm kind of amazed by the "compiler pipeline" that they achieved.
Imagine something like this combined with LLVM and an LSP based backend that also integrates a no-code way to implement fuzz and unit tests.
[+] [-] bodhiandphysics|4 years ago|reply
[+] [-] JamesAdir|4 years ago|reply
[+] [-] revskill|4 years ago|reply
Why ?
You of course could run any code with assembly or machine language, but now we have high level programming languages, it's because we want "low-code", or "low machine-code".
The point is we want to map business problems/solutions into machine, code is just a "no code" tool which allows u to do that.
[+] [-] jojobas|4 years ago|reply
The high demand and pay of the last few decades brought a lot of people into trying to be those few but it looks like the percentage of the "worthy" people remains as low as it was decades ago and move from Fortran to lowcode did nothing.
[+] [-] snarfy|4 years ago|reply
[+] [-] tomc1985|4 years ago|reply
[+] [-] andrewstuart|4 years ago|reply
To anyone who needs to hear this: if it's code based programming then it's not no-code or low-code - it's code.
Put more simply:
code != no-code
[+] [-] AnimalMuppet|4 years ago|reply
But it's never really "no code". There's always "code", because you always have to tell the system what you want the program to do. However you tell it that, that description becomes the code.
[+] [-] dagw|4 years ago|reply
[+] [-] HKH2|4 years ago|reply
[+] [-] rory|4 years ago|reply
<--Assembly----C----Scala----Django----Hasura----Bubble-->
Each one involves telling your computer some logic, but on the left you have to be much more detailed and the computer makes fewer assumptions than on the right. Is Hasura Code or No Code™? I write some SQL or a GraphQL query, but I also click around and set permissions and relationships in a GUI.
[+] [-] wiseowise|4 years ago|reply
[+] [-] bob1029|4 years ago|reply
I think that no/low code is the secret end goal for any B2B line of business product. You eventually want to be able to have sales engineers directly setting up your products for customers, with developers standing by to support or enhance the shared code pile. You never want to be in a situation where you need 1 developer and code pile per customer when you are trying to capture an entire market segment with hundreds or thousands of businesses.
Once you figure out all the likely paths through the jungle, you can expose configuration and scripting at the various decision points.
Our specific flavor of "low" code leverages SQL and projections of business state to allow for very precise tuning of certain logic. Being able to employ SQL to solve problems implies a very intimate understanding of the problem domain. You have to do battle with the business and iterate the model until you know 99% of it will never have to change. Anything less than this is walking across quicksand, as changes to schemas per already-configured customers quickly turns into a nightmare factory of regressions and otherworldly suffering.
[+] [-] collaborative|4 years ago|reply
Since this is likely not going to change, these no-code tools expand the number of workers who can do stuff. But it clearly isn't as good as coding and never will be
[+] [-] GuB-42|4 years ago|reply
The articles then shows that it is far from a "past decade" thing.
Low-code, no-code, RAD, or whatever you want to call it has always been a thing. Code is an obscure thing to the uninitiated, and it costs a lot of money to hire the initiated. So of course people want to make it more accessible. Today is nothing new, if anything, it tends to go the other way: people are getting more comfortable with code.
And the article explains it very well, in fact, it is one of the best overview I've seen. It takes about Excel, the most successful "low-code" platform, UML, which is mostly a failure, and modern takes like Copilot which offer guidance but do not try to hide the code.
The conclusion however seems to be "I don't know", told in a particularly convoluted way in entire chapters. I think the article would have been better if it didn't try to predict the future.
[+] [-] navaneethpk|4 years ago|reply
Examples: ToolJet: https://github.com/ToolJet/ToolJet Obsei: https://github.com/obsei/obsei n8n: https://github.com/n8n-io/n8n
[+] [-] lalitpagaria|4 years ago|reply
[+] [-] ethbr0|4 years ago|reply
This, so much this!
The amount of wilfull low-code ignorance of standard, 20-year+ old best practices for producing reliable software is mind-boggling.
Integrate with standard version control. Have a textual representation of your source. Integrate with standard CI/CD.
No, you are not a special snowflake. And no, no one wants to have to use your cloud SaaS build tools vs something they can own, integrate, and run themselves.
[+] [-] Borrible|4 years ago|reply
https://www.christies.com/lot/lot-a-sumerian-clay-cuneiform-...?
By the way,do you think anybody will pay that much for an 4000 year old Excel Sheet about let's say pork belly futures in that 4000 years?
[+] [-] albertopv|4 years ago|reply
[+] [-] nickthemagicman|4 years ago|reply
Like isn't a turing complete language proven to be the highest level one can go to be able to do anything required with code?
Everything past that reduces the amount of code but also reduces the number of things the code can do and at some point in the code reduction, it's just a declarative language?
Its all shades of gray between imperative/functionsl and declarative.
[+] [-] islon|4 years ago|reply
[+] [-] throwawaysea|4 years ago|reply
[+] [-] curryst|4 years ago|reply
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.
[+] [-] rsj_hn|4 years ago|reply
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.
Frankly, it's a nightmare.
[+] [-] dpayonk|4 years ago|reply