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.)
Ask HN: Experiences with low-code systems?
31–40 of 76 posts
Re: Ask HN: Experiences with low-code systems?
#32Retool works great for us
Re: Ask HN: Experiences with low-code systems?
#33It 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.
Re: Ask HN: Experiences with low-code systems?
#34Wow, 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.
Re: Ask HN: Experiences with low-code systems?
#35What 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.
Re: Ask HN: Experiences with low-code systems?
#36I 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 co…
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.
Re: Ask HN: Experiences with low-code systems?
#37I 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.)
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.
Re: Ask HN: Experiences with low-code systems?
#38We 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…
Re: Ask HN: Experiences with low-code systems?
#39Re: Ask HN: Experiences with low-code systems?
#40We 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…
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. :)