Ask HN: Experiences with low-code systems?

[alphalima]

I'm thinking about introducing a low-code system to handle internal operational processes. I'm thinking things like viewing/handling dead-letter messages, manual intervention decision points, short lived operational tasks that haven't yet/won't be automated.

I'd expect the software engineering team to manage these apps, so the benefit I can see is the quick turnaround on the UI, rather than handing over to non-engineering users for development.

What are people's experiences with these tools? More specifically:

Can you do an effective SDLC with them? e.g. code on a staging environment, push to version control, promote to prod, rollback to old version

Have you actually saved time with them?

Did you avoid introducing unworkable complexity?

[gwbas1c]

It's critical that; what ever you're trying to accomplish in a low-code environment; can be accomplished with minimal abstraction-based concepts, like variables and methods. You environment should be as easy / hard as Excel programming.

In the 1980s there was a major effort to make programming intuitive through visual-based programming tools. There was even a journal dedicated to visual programming. I happened to read through some of these articles in 2002-03 for a college project.

The conclusion in the last journal was that programming requires concepts that can only be expressed in words. Visual (intuitive) programming eventually failed because it wasn't expressive enough.

At the same time, Excel took off. Although it doesn't have "variables," it does allow for expression of abstract concepts.

> I'd expect the software engineering team to manage these apps, so the benefit I can see is the quick turnaround on the UI, rather than handing over to non-engineering users for development.

IMO, make sure the team that's going to manage these apps is involved in choosing the toolchain and has complete buy-in. (Or at least has a healthy skepticism.) There's nothing worse than an edict coming from down on high to use a bad tool.

Also, keep in mind that, if you're using well-educated software engineers; lightweight scripts in languages like Python, Javascript (via NodeJS), LINQPad (lightweight C#), ect can go very far. Because you're working with mature languages, you can minimize your technology risk. When I was at Intel, we had a rather robust batching system for VBScript. It could call into custom COM objects, usually written in C++ or C#, when needed.

[speedgoose]

I tested Retool a bit, which is great, but it is way too expensive for my projects, so I went with the open-source Appsmith instead.

It has been successful, but I recently had to patch it to remove a new annoying «made with appsmith» ad on our applications that can only be disabled on the enterprise edition or if you edit the source code of the open source one and are willing to share your patch of course. Another important planned feature, SAML/OpenID has also recently been announced to be only for the not open source enterprise edition. Their Kubernetes helm chart is a mess too. They want to be noob friendly with everything in a single stateful container. I understand the reasons, but I don’t like it.

On the good parts, we build applications in a few days, and it’s great for prototyping and simple applications. One large application we build has reached the limits of no-code platforms, in our opinion. It will be rewritten in code, but we think it was not a waste of time and resources as we could iterate fast, and we didn’t know whether a more expensive development would be worth it.

[mohanarpit]

Creator of Appsmith here.

First of all, thank you for trying the product and sharing your feedback. I appreciate it.

While you can modify the source code to remove the watermark, you can also upgrade to the paid edition which helps keep the project sustainable. :) Additionally, you don't have to put in additional effort in keeping the fork up to date with our main repo.

I understand that our choice of single Docker container for hosting Appsmith may be counter-intuitive. We took that route because we were seeing lots of developers struggle with k8s (especially with multiple pods). That's why we actually simplified the experience to optimize for quick starts.

I look forward to your feedback and support for a growing open source project :)

[speedgoose]

I recently wasted a lot of time talking to salesmen who thought my (non profit research) company had bags of money to give away, and I decided to stop requesting quotes for SaaS because of that. I know that everyone needs to eat though, but it doesn’t soften the managers.

I wish you the best, you have a great product already.

[algo_trader]

For appsmith, were u able to make some dynamic features?

e.g. a count down field which count down seconds to zero OR a list display with automatically updates from the source

(Ironically, i will happily spend time build a custom back end source, if AS will take care of front end)

BTW, playing with appsmith right now, it crushed and is now down for more than 15 minutes

[mohanarpit]

Hey, creator of Appsmith here. Thanks for trying out the product.

To answer your first question; yes, it's possible to build dynamic apps that can countdown the seconds to zero or build a timer dynamically. The sample application: https://app.appsmith.com/app/input-widget/input-counter-reva... shows a counter. In this example, while a user is required to click a button, this can be modified to be triggered automatically every 1 sec.

It's currently not possible to power the UI via websockets yet. This is an open feature request that we are yet to implement.

Having said that, I'm sorry that Appsmith crashed for you. Were you trying us out on Appsmith Cloud (https://app.appsmith.com) or were you self-hosting Appsmith via Docker/k8s?

Please feel free to email me at arpit [at] appsmith.com & we'll help you out succeed with the product.

[algo_trader]

I completed the cloud tutorial - very helpful -then launched ok.

Started some of the templates on the cloud - crushed for more than 10 minutes

Right now, very slow. Multi-second latency with smartlook.cloud and iam-something....

Best of luck!!!

Good luck. Hope this helps.

[anakaine]

Hey, thanks for Appsmith. I've just started trialing it.

Got a question: is it possible to operate without something like docker, on Windows? The place I would like to deploy it is a VM, and nested VMs are not a good option with what I have available.

[speedgoose]

One of our apps has some kind of auto refresh but it was not smooth to set it up from what I understood.

[foxbee]

Curious if you tried Budibase? No annoying ad :-) https://docs.budibase.com/docs/kubernetes-k8s

[speedgoose]

Yes I did around December, from my notes I found it a bit more cumbersome to use for more than a few forms but I consider it a descent alternative.

[foxbee]

Ahh. It's changed a lot. You should give it another try if you find a minute.

[nulbyte]

> if you edit the source code of the open source one and are willing to share your patch of course

As I read the Apache license, you are allowed to modify the code, but I see nothing to compel you to distribute the modification.

[speedgoose]

You are right, you don’t have to.

[alphalima]

Thanks for the detailed feedback! Yeah, I'm not a fan of the SSO tax (though I respect that they've got to eat).

Agreed on the all in one docker solution, it seems like a choice made to get things off the ground, not one predisposed to effective prod operations (storage being the major headache, though I assume there's not too much stored on disk).

Regarding the more complex application, do you think you could pinpoint what quality caused the low-code version to be too complex?

[powerhour]

> Their Kubernetes helm chart is a mess too.

To be fair, I have yet to see a single helm chart that was not a mess. Messiness is endemic to the file format (YAML) and templater (text based). Further, there are no enforced standards defining how to format ingress, service, etc configuration keys in values.yaml so every chart developer is on their own.

[speedgoose]

The qualities varies for sure.

The appsmith helm chart works out of the box, which is better than many.

My main issue is to put everything in the same stateful pod using supervisord. It doesn’t scale, I don’t want to use supervisord inside a kubernetes pod, it’s huge and slow to get ready. The helm chart does also weird things such as having a namespace définition or an autoupdate by default.

[powerhour]

Ooh, yeah, supervisord doesn't sound like a good fit. Good catch.

[mohanarpit]

Disclaimer: I'm the creator of Appsmith.

The primary reason for creating Appsmith was because, as a backend engineer, I didn't enjoy mucking around with HTML/CSS just to build admin panels. Hence, we created a way to build such apps really quickly.

Appsmith also has a deep integration with Git. This allows you to create feature branches, raise pull requests and have different branches for your staging and prod environments. This also allows you to rollback your application to an older version.

While there are obvious pitfalls of using a low code application, I'd wager that you'd be able to go much further, much more quickly than you initially estimated.

[alphalima]

Great, thanks for responding! I'll be taking a serious look. I completely understand the motivation behind Appsmith, it's kind of exactly why I'm evaluating tools like these.

Out of interest, what proportion of your creators are engineers vs SMEs? Reason why I'm asking is that I'd be very nervous of letting non-engineers (without an understanding of just how much damage they could do) create write apps.

[sgammon]

Any planned support for gRPC or OpenAPI?

[jusonchan81]

So this is not really a low-code system. But we manage a lot of our workloads using Netflix Conductor. Its a great platform that naturally promotes re-use of expensive functions. And it has a lot of resiliency features built in, which avoids a lot of code. There is a bunch of things it supports out of the box which has reduced the amount of code we write and over time we have built a repository of re-usable running workers (Netflix Conductor terminology) which makes building new use cases really fast.

But the real benefit we gained is the overall support time for issues during on-call. Without any additional tooling such as Datadog or other expensive products, we are able to manage support really easily with the UI that comes with it. So yes - we reduced complexity, save a lot of time, and are still able to code everything we must and this platform connects everything really well.

[alphalima]

That does seem like a neat solution. Does it support user-tasks in workflows (i.e. block until someone clicks a button)?

[Nimsical]

I've been using Superblocks (https://superblockshq.com/) to do this.

I'm generally a fan of reducing complexity for building internal tools. We used to use Retool with a combination of Google's App Engine, Google Cloud Scheduler, and Mode Analytics to support our internal teams but we consolidated all of it under Superblocks.

They have charts, you can build backend functions (and call them on a schedule!), and you can build a UI just like you can with Retool (they have feature parity in most areas with Retool on the UI side).

The best part has been that they support Javascript and Python at the same time, which has let our data and engineering teams live in the same eco system and work together to build internal data tools for our team members.

Huge fan!

[alphalima]

Thanks!

I'll take a look, I'm much happier in Python than JS so a big plus for me.

[gusbremm]

I worked for a while on a Mendix app and it felt interesting in the beginning but quickly I started to hate it..

Low code can deliver some features 4x faster but sometimes a stupid feature can take 20x the time just because the low code platform wont support that. Or sometimes the solution is so ugly that the whole project becomes a mess.

If you want to deliver top quality stuff you are constantly fighting the low code limitations.

However, if you are OK with low code limitations it can be benefical.

[hiram112]

> Low code can deliver some features 4x faster but sometimes a stupid feature can take 20x the time just because the low code platform wont support that. Or sometimes the solution is so ugly that the whole project becomes a mess.

This is why I'm not too excited about some of these solutions. Seems like I've been here, done that several times in my career: CMS software like Wordpress and Joomla, "Portals", repository and workflow solutions like Alfresco and Appian, etc.

They all save tons of time for a small prototype or very basic use cases, but the minute users want some special feature, you'll spend hours, days or longer fighting against the tool, driving yourself nuts because you know you could implement it in 30 minutes in a custom app. Or you're forced to become an "expert" in these tools, which turns out to be a really bad career move as years of experience with a specific framework will instantly become worthless as industry moves on to the next Big Thing.

[superdisk]

Perhaps one that's a bit off the beaten path, but I've developed a number of games using Multimedia Fusion (now known as Clickteam Fusion). It's a "no-code" system in the sense that you do all programming using a unique checkbox system which has interesting semantics regarding selectors/which objects that certain events interact with. [0]

It's super useful for developing for things like game jams, where you have a super tight time limit, but you definitely have to work within the constraints of the system. If you try to push the boundary too much on what's "expected" it becomes painful very quickly. Additionally, porting the code to other platforms is difficult since you're at the whim of Clickteam to implement it, and historically their "exporters" have been buggy, leading to a cottage industry springing up around the tool to create alternative runtimes for better performance/portability. [1]

From what I'm reading from the other comments, this experience isn't just unique to games, and seems like it applies to other low-code business application tools as well.

[0] https://media.indiedb.com/images/engines/1/1/19/mmf_eventedi...

[1] https://mp2.dk/chowdren/

[alphalima]

> but you definitely have to work within the constraints of the system. If you try to push the boundary too much on what's "expected" it becomes painful very quickly

Hah, that's the problem with every framework!

[rawgabbit]

In my part of the world, IT has settled on Salesforce. We use flows (visual tool) for basic automation. For more complex scenarios, we have to resort to using Apex which is similar to Java programming and Mulesoft which has a GUI front end but you end using a lot of Java. Salesforce also released Mulesoft Composer which is a separate product; Mulesoft Composer is targeted at Admins and lets you connect external systems again using a visual tool.

The business, however, loves loves loves Smartsheet. Smartsheet looks like excel; but we had configured it to power all kinds of business processes/forms/automation/websites. It is pricey though.

Regarding your questions: SLDC is hit or miss. My attitude is to get the business involved early in these low code tools as they are ultimate judge of "correctness".

I don't think we save time. If you have a 100x developer, they can create all of these things much faster than these low code tools. The problem is we don't have 100x developers. If we did, they will probably leave for better jobs. What we do gain is the ability to create things by our junior developers and admins.

The tools are only good as the vendor support. We want the junior developers and admins to reach out to vendor support for issues and training. We don't want the junior developers and admins to become "project managers" and nag the senior developers.

[z9znz]

I suspect there are certain use cases for which low-code systems are well suited, and others where it will either not be expressive enough or will end up being so complex that it would be better/more easily expressed in code.

I spent a few years building data analytic systems for big telcos to reconcile switch and billing data. For this I used the tool my company was selling which was a visual (ugly but very practical) graphical node-based system. You pick the right type of node for a given (stream processing) need, make some configurations (including possibly adjusting the number of inputs and outputs), and then connect things together.

Many of the end results would have been reasonably simple to build in code by an experienced developer, but one of the key benefits of this toolkit was the ability to walk a client through the system, explaining what was going on. The visual nodes and connections were reasonably accessible to non programmers.

An added benefit of this kind of toolkit was the ease of discovering what the data actually looked like and seeing the effects at the output of each node. The outputs also had little number tags which provided surprisingly useful high level information: "How many records did we just cull from the source data with this filter?"

The challenge we encountered was in productionizing these systems. Sometimes they were just tools used to solve a one-time problem, but other times they were intended to become parts of a greater process. (In the latter case, I always felt we should just take the lessons learned and write the final product in code...)

[bmhin]

It's hard to think about because I feel like when they work I don't think about them at all. And when they don't work I think about and stew about them excessively. So the good cases I forget about completely and the bad ones are stuck in my memory.

SDLC is a frequent pain point. Often non-existent or hacky, e.g. export this giant XML doc and you can re-import it if needed. If any step requires clicking on buttons it generally leads to that kinda pain. Almost fundamentally, if I need to go copy paste or click on something for the product to work, I won't be able to automate it. Hence, it needs to be completely automatable. Similarly, if the config / set up / customization one does is obfuscated after it is specified it can be a headache to try to work around. Also maybe not the end of the world but many also decide to "handle" version control on your behalf, which can maybe be fine, but will also then almost by definition be divorced for your usual approach and processes.

On the last question, I think this boils down to how well can one operate at the surface level. It is not uncommon in these low code apps to have to understand in detail what is happening below the hood. So yeah, the top layer abstraction might be very simple in practice, but if working with it frequently necessitates me knowing how that abstraction will be executing it leads to an extra layer of complexity that has not abstracted anything. In a way they often function like a second language going through a translator: if I have to be considering the Spanish version the no-code cares about and also how and what it will be translated to in English under the hood, it's just extra confusing for perhaps little gain. What makes it extra pernicious is you can be operating entirely off intuition for what that under the hood English really is, rather than some open spec you can at least drill into.

Worst part here is I feel like this is really often something that will come with using the product. Often the use cases documented and sold really seem like all you'll need.

[alphalima]

Thanks for the great comment!

> SDLC is a frequent pain point.

I've dealt with that pain before with other tools (promoting DataDog montiors + dashboards comes to mind). This area seems like it'll be even more painful so I'll definitely be filtering by that critereon.

> On the last question...

My particular use case would be for some human checkpoint in an otherwise-automated system. I'd hope to pull in all the contextual information, provide the decision-maker with a text box and an approve/reject decison.

> Worst part here is I feel like this is really often something that will come with using the product. Often the use cases documented and sold really seem like all you'll need.

Yeah, that's what worries me about low-code. I know it'll be a bit of a slog to do all these full-code, but it's a known quantity.

[muzani]

Been using some on and off since my school days. Also if you include tools like Cordova which help you create a bunch of apps instantly, or something like WordPress or Vtiger.

It seems to be that low code is ideal for prototyping. You have more building blocks. The actual cost is that some of those building blocks may go obsolete and need maintenance. And some will not be suited for your use case, so you have to customize it.

It flips around the dynamic of 90% development/10% maintenance to 10% development/90% maintenance.

Excel is probably the holy grail of low code. There's a whole lot of power in it, so much that it gets dismissed as a layman's tool. Even some of the stuff people are excited about GPT-3 doing, Excel already does.

[aeberhart]

Disclaimer: I'm the creator of Dashjoin (https://github.com/dashjoin/platform)

Implementing the features you mentioned:

Once you connect your SQL / NoSQL database, you're immediately able to view, query, search, and edit the data. Every record implicitly has a "homepage". On this page, you can add active elements to automate tasks via REST services. We do this using JSONata (jsonata.org) which is a super expressive and concise transformation and query language. You can find some samples in our demo application (https://github.com/dashjoin/dashjoin-demo).

The core philosophy is to get immediate results and refine from there, depending on your cost / benefit calculation.

SDLC:

I think this is a very important point! Even though you're working with low code, it is still a development project with testing, staging, and production, issues, tickets, etc. We allow you to manage the software development lifecycle using GIT. You can view a sample project here: https://github.com/dashjoin/dashjoin-demo. It contains of the DB connectivity information, custom page layouts, queries, and REST function adapters. A developer commits changes to the repository. The production can be configured to pull a certain QAed version.

[yawnxyz]

I really love Retool, but if you're dealing with a ton of data, it'll bog down their UI really quickly. It's quick to get started to build small apps for special circumstances (like moving files around, approving posts, etc.)

[eeke]

I head up product at Retool. I’m sorry to hear about the issues here. We’ve been heads down on improving the performance of apps like yours by moving work into the server-side, re-architecting parts of our codebase, geolocating our servers closer to users, and a number of other initiatives. We’re releasing these improvements as we prove their efficacy, while other improvements are under more experimental feature flags. If you’re interested, our engineering team would love to get these safely turned on for you—Just reach out to me at [e-mail].

[mousetree]

We're starting to get to that stage now. We have a UI for Customer Service to manage everything related to a customer at a digital bank. It's becoming quite slow.

[seyz]

Just in case, we work a lot with banks (with >1k users onboarded on one single admin panel) at Forest Admin.

[HatchedLake721]

I recognized the name, thank you for jsonapi-serializer!

Any reason you’re not adding maintainers?

Feels sad that one of the most useful JavaScript JSON API spec libraries is dead for 2-3 years :( There are people lined up to support, fix and keep improving it.

https://github.com/SeyZ/jsonapi-serializer/issues/200

[efortis]

For the prototyping phase, I made UI Drafter, which is free and the prototypes can be functional (up to a point) and can integrate with your backend via HTTP

https://uidrafter.com

[algoware]

I have been using DronaHQ (https://www.dronahq.com) to build apps for my clients. I really like the ability of designing frontends quickly using some greate UI components (my most commonly used one is their table grid) that work both as web apps and mobile apps. We can publish apps simultaneously on multpleplatforms. Also it supports version control, version rollback and intigration with git.

I have used DronaHQ to integrate and create apps on top of databases like MongoDB, MySQL, Postgres and a handful more and the power really shows in the platform's performance when it comes to looking up over 10000 rows of data (through smart optimization techniques ofcourse supported by the tool) which I am yet to find elsewhere.

I am definitely saving a lot of time and able to create some fairly complex tools such as a custom CRM, dynamic inspection forms, approval management apps.

[algoware]

I have been using DronaHQ (https://www.dronahq.com) to build apps for my clients. I really like the ability of designing frontends quickly using some greate UI components (my most commonly used one is their table grid) that work both as web apps and mobile apps. Simultaneously we can publish for all the platforms. It supports version control, version rollback as well as intigration with Git.

I have used DronaHQ to integrate and create apps on top of databases like MongoDB, MySQL, Postgres and a handful more and the power really shows in the platform's performance when it comes to looking up over 10000 rows of data (through smart optimization techniques ofcourse supported by the tool) which I am yet to find elsewhere.

I am definitely saving a lot of time and able to create some fairly complex tools such as a custom CRM, dynamic inspection forms, approval management apps.

[datavirtue]

Trying to use Microsoft Power Apps to build a "canvas" app. I was attracted by the Azure AD integration but quickly discovered that it does not support developer collaboration. I thought that I might be able to use thier component library to enable collaboration but was rebuffed instantly by the fact that you can't place a data table control/component on a custom component. Now I'm cursing myself for getting sucked into yet another shitty Microsoft platform.

[ethbr0]

That feels like most of the Power/SharePoint ecosystem to me: we make the easy things easier.

Hard things = intrinsic hardness * the difficulty of working with some bizarre and incomplete Microsoft framework

[oneplane]

Generally, no effective SDLC except for when the vendor builds a half-assed version of SCM into their product. Generally no such thing as Low-code + Git.

Most of the systems either don't have the big benefits they claim to have (time spent just flows elsewhere), or they are of limited use (think basic form workflows into a database or spreadsheet).

It's somewhat similar to a 'website builder' where yes, you can build a website, but instead of learning general tools, you're learning builder-specific tools. And instead of solving logic in logic solving tools, you're solving logic in (mostly) sub-optimal tools.

This is essentially the same problem with say Excel and Access; to use those at scale you'll still need to learn a 'variant' of programming and data modelling and it doesn't help much that it's inside of an application instead of inside of an IDE.

In this specific case, I would ask the software engineering team to find out ways to do rapid prototyping with a trade-off in UI quality; you can generally get away with the same principles as OpenAPIV3 spec based data structure and interface generators. You focus on specifying how the application should process and model data, and auto-generate all the required persistence and interface stuff from that.

[alphalima]

You've hit the nail on the head about my reservations.

Regarding your recommendation, were there any libraries that exist already?

Otherwise, I assume that you mean:

1) write some code to derive a CRUD/RPC OpenApiV3 Spec from some data-at-rest spec/JSON Schema other (e.g. RDBMS Table)

2) generate endpoints conforming to that spec and wire it to persistence

3) generate UI components that allow you to drive requests to those endpoints.

4) build something to serve backend + front-end

Those steps look like a low-code system to me?

[rubyist5eva]

We evaluated trying to use appsmith for replacing our handmade admin panel but doing things like setting up pagination for databases was not particularly pleasant, basically writing raw sql with template strings. Yuck.

Our app would’ve needed a bunch of new apis added to it to make it workable that we just weren’t willing to invest in at the time so we’re sticking with our plain html pages and smatteringgs of js for now.

[yen789]

Have you tried Forest Admin? It generates an admin panel based on your data, and features like pagination, search, dashboards, etc. are available out-of-the-box. It's way faster than building from scratch and even with low-code. It's also secure, FA can't access user data.

[rubyist5eva]

Never heard of it but will check it out

[mohanarpit]

Disclaimer: I'm the creator of Appsmith.

Thanks for evaluating the product. I appreciate it.

The reason we allow users to write raw SQL within Appsmith is because it is geared to build dashboards and admin panels in scenarios where you don't have or don't want to write API layers on your database yet. Hence, this gives our users a balance of easy to start with & configurable to extend.

You can always start with raw SQL queries and upgrade to APIs whenever you have them ready. Since access control is in-built within the product, your queries are never exposed to users and are safe against any SQL injections as well.

Having said that, I totally understand if a low code product like Appsmith doesn't fit your needs today. I hope some day you'll have a use case that we can help with. :)

[rubyist5eva]

Thanks for the response.

We considered starting with the raw queries and adding apis later, but unfortunately it just didn't make sense for us as it was ultimately less effort to just use our existing SSR rails views and we wouldn't have to dedicated more resources to augmenting internal tools even more, or managing the extra infrastructure needed for appsmith (hosted solution on other infrastructure was not an option unfortunately) - we don't use mongodb so adding it (for the appsmith datastore) to our infra was not something we really wanted to do either.

We did decide to revisit in the future as we are building some distributed services and appsmith might be a better fit then when we need to build a unified UI for all of our services.

[anilgulecha]

Directus has served me well for a couple usecases, sepcially for back office apps. Plus the fact that you can extend it with express/nodejs is another good deal.

In terms of productionizing it, you can pick any postgres migration system and use that to maintain the schema,and use directus only for the crud/adminui layer.

Can recommend a try.. the hosted free version even before you decide to self host.

[ahinojosagz]

I've been using Bubble for about 5 years now, and even though no-code gets a lot of hate in HN, I've personally been able to help clients get their projects pushed to market, each in about a month on average.

You can get a responsive interface ready to go pretty fast and it does scale if you know how to design DB schemas, you can also go pretty wild with the custom APIs to integrate more traditional functions.

By default you've always got a staging and prod environment.

Higher tier plan do enable rollback to previous deployments [Up to a year I believe].

If you're looking to test out an idea or MVP then it's a great tool to get it in users hands, and it does scale.

Avoiding unworkable complexity really comes down to the developer / team you choose and their ability to develop the project with a structured approach.

[darthrupert]

Low-code/no-code is essentially a fine idea. It's the same idea as DSLs and libraries, with an attempt to bring it these ideas (usually by UX techniques and severly limiting the power of the system) to the technically simpler people.

The problem is that afaik nobody has yet implemented the grand idea well. They build the facade and the insides are rotten, haphazardly put together without a clear vision. It needs a deeply technical vision and, I imagine, a bit of computer science to get right.

It's a bit like what the cloud space was before AWS and Google came along.

[gkapur]

Retool works well -- they have their own version of SDLC in the $10 plan (staging versions of resources.) If you hook that up to something like Neon (https://neon.tech/), you can have staging branches of a database, as well.

The issue I have with many of these products is that a lot of the logic should actually sit closer to the backend (ie. better REST APIs, etc.) If your engineering team is managing the backend anyways, it shouldn't be a huge issue maybe?

I made an investment here (moving the non-UI logic closer to the database) but it's too early to really see if it will work.

[giantg2]

We had a large application that handled work items and routed them through business process maps. The backend was FileNet (and Oracle), which provided a GUI to define the workflows. Then we wrote a UI app that dynamically built parts of the page based on the xml fields present on the FileNet workitem.

It worked well and saved a ton of time by almost eliminating UI elevations. Most workflow changes were very fast too due to the simplicity of the FileNet GUI. Initial setup takes time, and there aren't a lot of FileNet resources out there. For those reasons I'd hesitate to recommend it.

[seyz]

Disclaimer: I'm the founder of Forest Admin (https://www.forestadmin.com).

Wow, I'm impressed by the number of solutions out there. Back at the beginning of Forest Admin, we were alone on the market, which is generally not a good sign. But our perseverance paid off, and it was definitely worth it in the end!

Alright, so why Forest Admin? :)

Because we only focus on the admin panel use case. Not the entire internal tools world. In this way, we are able to provide a fully-featured SaaS Admin panel out of the box. No need to build it, nor with code, nor with low/no code tools.

Even if you "are too specific", we have designed our solution accordingly with 2 things that are part of our DNA from the beginning:

1/ We generate all the backend code required to an admin panel. All CRUD routes, filtering & search, dashboarding, permissions, etc. Everything is automatically generated in a few seconds based on datasource introspection. In the end, the generated code is just a standard REST API, so you can extend/override it without any limitations.

2/ We pre-built the admin UI with every admin standard features available out of the box, with a big focus on providing a great UI/UX possible for operational people. We obviously also provide all the low/no code features to customize pretty much anything. We also provide a feature called "Workspace" (which is generally the core of what our competitors do) that allow users build custom views using drag'n'drop of UI components from scratch.

About SDLC - it's provided out of the box at Forest Admin:

- For backend code - you can rely on Git.

- For UI code - we provide a feature called "Development workflow" (https://docs.forestadmin.com/documentation/getting-started/d...) that allows you to have different environments (e.g. dev, staging, prod, fork branches, merge them, etc.

In this way, even companies with hundreds of onboarded users (including douzen of devs) can use us in a scalable way.

[garyclarke27]

I wrote a blog post that answers this question.

https://www.onedb.online/blog/why_no_code_is_better_than_ful...

Obviously I'm biased, since I'm founder of onedb a No-Code/ERP/CRM Platform. I've tried to be objective with the article. I am sure though that a Domain expert using Onedb can deliver what you need 100* faster than with traditional software tools.

[mkaymalright]

We use Appsmith for a couple of use cases but essentially all it does/we use it for is

- to be a database admin interface for non-engineering users to display and edit a bunch of tables in postgres.

- having an interface around calling internal API's, with a page for input parameters

it's pretty good for these use cases, it allows non-engineering people to do some things that would otherwise require a custom built UI.

[mohanarpit]

Thanks for using Appsmith! Appreciate the kind words. :)

If you ever need help in building more complex use cases, please reach out to me at arpit [at] appsmith.com. Will be glad to help in any way that I can.

[algo_trader]

Were u able to get some dynamic behaviours ?

e.g.

a count down field which count down seconds to zero

OR

a list display with automatic updates from source

[foxbee]

Cofounder of Budibase here. Thanks for mentioning Budibase. Interested to learn about use cases and happy to answer any questions.

For reference:

https://github.com/Budibase/budibase

https://budibase.com/

[wombat-man]

I played around with bubble. My thinking was to create like a fun questionairre/filter/contact app for my personal website. It's fun to noodle around with even though I didn't end up publishing. I'd be hesitant to use it in prod on something important.

[ethbr0]

Disclaimer: I'm approaching this from the automation side, and currently work at UiPath.

What do you want to use your low-code system to build?

If you're targeting arbitrary app creation, then you probably want your aforementioned tools or the myriad of other options (e.g. Appian, etc).

But if you're targeting automation of existing processes / apps, on Windows, and would like some-but-not-unlimited UI flexibility... use an RPA tool. E.g. UiPath

You get out of the box GUI integration for driving other apps + all the other app designer bits.

Which turns any automation problem into (1) "Is there a prebuilt component for it?", (2) "If not, can I interact directly with the necessary GUI controls?", (3) "If not, can I use CV to drive the problem GUI sections?"

In ~10 years of doing this, over a few products, I'd say (1) handles 60% of use cases, (2) handles 35%, (3) handles 4.99%, and I can only think of a couple times I've fallen completely through and been unable to automate.

And which, critically, means you can push the tool to non-traditional programmers and get decent results.

---

> Can you do an effective SDLC with them? E.g. code on a staging environment, push to version control, promote to prod, rollback to old version

Go ahead and ignore any tool that doesn't store apps/automations in readable files (typically XML).

From that subset, they have varying CVS support, but most modern ones support a sane SDLC.

I'd also weed out anything that doesn't support command line / Jenkins builds.

> Have you actually saved time with them?

Hell yeah. I've automated health care EMR and claims systems in a few weeks... that I'd still be trying to get legal access to an SDK if I'd gone that route.

The key feature of RPA is WYSIWYG automation: since you're automating your GUI, there's no impedance between {process as performed by user} and {process as performed by code}. You just ask them what they do, then 1:1 map actions to automation.

> Did you avoid introducing unworkable complexity?

The key here is process documentation. Specifically, writing down the why of a process and its steps. What is more typically noted, but is far less informative.

With the why documented, you can port to an alternate system or adjust the process down the road without issue.

Setting up hard, machine-checked "must X to Y" gates helps a lot with ensuring consistency here. E.g. carrot and stick "you must create a doc in this format, have it reviewed, and have your code in version control and reviewed" before "you get the ability to schedule it in production"

If you want lessons-learned from my adventures (and misadventures) of creating a low-code offering at a large enterprise company, feel free to reach out. Email in profile.

[motleydev]

One of the primary advantages of Low-Code is that it makes non-developers operational in creating interfaces or solving feature requests. Those developers can focus on creating better data sources, focusing on public facing products, etc. But low-code is great for letting otherwise smart people build internal tooling. I haven't seen many public facing low-code tools that don't go off the rails pretty quick with any kind of complexity.

FWIW, I've done some explorations with low-code.

Written format:

Using Hasura with Low-code: https://hasura.io/blog/hasura-for-the-low-code-ecosystem/

Retool: https://retool.com/blog/event-driven-architecture-and-reacti...

Microsoft Power-automate: https://hasura.io/blog/integrating-hasura-with-microsoft-pow...

Retool (again): https://hasura.io/blog/integrating-hasura-with-retool-for-bu...

Bubble: https://hasura.io/blog/tutorial-using-hasura-api-with-bubble...

Draftbit (Again): https://hasura.io/blog/a-tutorial-using-hasura-with-draftbit...

Rapid prototyping listicle: https://hasura.io/blog/rapid-prototyping-with-hasura/

Videos:

Draftbit: https://www.youtube.com/watch?v=WrhQKt5-QY8&list=PLTRTpHrUcS...

Appsmith: https://www.youtube.com/watch?v=e4swzfSAevo&list=PLTRTpHrUcS...

Retool: https://www.youtube.com/watch?v=qhFs431UwIw&list=PLTRTpHrUcS...

I do think there's lots of power to low-code and I think for internal tooling specifically or for testing theories or even short-lived public-facing tools, they fit a solid use-case of turning smart people int actionable devs. They still need to "think like a programmer", which essentially makes UI a language, albeit one that's more verbose.

But with a generation of kids learning Scratch and other tools like that soon to hit the job market, maybe these tools are primed for major adoption?

Today I still ask businesses that ask me to help with tools why this CAN'T be a low-code solution, similar to the old adage, "why shouldn't this be a spreadsheet."

Full disclosure, I work for Hasura so there's some heavy handed surfacing of Hasura in those links, but it just goes to show what's possible when you decouple front-end from the API layer, letting different tools solve their scoped problem space.

Edit for formatting.

[foxbee]

Budibase meets Hasura content would be awesome!!!

[motleydev]

Always looking for good content options! I'll have a look. If anyone from Budibase wants to DM me, my Twitter is the same as the username.

[unixhero]

Salesforce or ServiceNow comes to mind.

[didip]

Airflow is a successful open source low code system in my opinion. And it is a pleasure to use.

[amitizle]

Retool works great for us

[mousetree]

Big fan too (digital bank)

[marcpp]

Hey, are you guys users or admins? Just curious!

[mousetree]

Both