Ask HN: Experiences with low-code systems?

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.

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.

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.

- 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.

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.

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.

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.

For reference:

https://github.com/Budibase/budibase

https://budibase.com/

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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/