flowripple.com
Skimming the video, and this site, I'm not noticing a ton of differences other than some minor styling changes. Maybe the author could mention any of the changes they've made? If they're significant, IMO, it's fine.
With the advances we are seeing in AI coding workspaces, "visual programming" seems like a dead end if the code isn't optimized for machine comprehension. I do think visual representation of code will become important to be able to more easily understand the AI generated systems, but it's just not an inefficient way to encode logic for AI (turns of code is a very effective at this).
IMO, for these low code runtimes to survive, they need to be "transpilable" to a simple DSL (or subset of a popular language) and have an LSP for agents to interact with.
What's the SDLC story? How do I move between environments, roll back, manage hotfixes alongside feature development, etc?
It's these "non-functional" feature that end up being the downfall of many of the integration projects I've been brought in to save.
John in accounting sets up a Salesforce to Netsuite integration that becomes mission critical and it works... Until it doesn't.
i learned recently that we pay $20/month for a hubspot app to intake our sendgrid webbook data and display it on a hubspot profile.
email engagement metrics are very useful so it makes sense.
one day we stopped seeing events in hubspot. sales had to give me their account password, i looked into it, no logs, no visibility, not even a status page. i sent a support ticket.
in the next few days i learned how to make a hubspot marketplace app and brought it all in house. it was non trivial and not ideal use of time, but now we have 100% visibility. everyone thought it was the right choice.
I want to start with the fact that building FlowRipples is a monumental feat of its own. Generic tools that are adaptable to lots of situations is a difficult task, and it's impressive what was built.
But the supporting functionality in any service like this is also so important. It's one thing to have a low friction setup and way to get started, with simple steps and a quick showcase video, so that someone can get to tinkering. It's another thing to fully adopt this as a tool within your team that would be integrated into a published product.
Suddenly, like you say, you have multiple environments (Dev, QA, Staging/Pre-prod, Prod) that you have to move changes into and out of. Replicating the same changes manually will inevitably lead to human error and what worked in QA will no longer work in Staging or Production. Even a simple export + import helps with this.
I think one thing that also needs attention is parallel changes. Two people are wokring on different changes in the dev environment. Promoting the current state of the Dev environment to QA requires that both tasks have to be dev-complete, or else unfinished changes could make its way to QA and cause confusion. This is difficult when the different tasks aren't synchronized in their testing (i.e. start testing one ticket but not necessarily the other). It's almost like you need branching and merging and diffing, a la git, to help resolve this. That's difficult to do in low-code visual programming apps.
It's a technical debt dead end.
I think these types of workflow tools will be ultimately replaced by AI agents.
The thing you miss with scripting is that a good workflow engine essentially provides a simple and well-defined layer allowing you to couple many concurrent processes and providing ressource management. Curiously out of the box all the opensource workflow tools do so too - like you said people (Airflow has pools, but thrn ...) essentially built very weird DSLs to do high-level composition and there you can indeed rather easily code it yourself. I assume the companies originating these have integrations for the other bits too while everyone else does fake elastic scaling with some halfbaked workarounds. And from time to time someone comes up with a new DSL and some GUI - ignoring all the hard parts.
Have you been inspired by Node-RED?
Tne thing people fail to see -and makers sell on- is that the value proposition of these platforms is NOT the "low code, no code" capabilities that "any business employee can use, no experience required" (a disingenuous sales tactic at best).
The value prop is their orchestration, observability, and administration offering that is their "control room". If you nail that capability, make it user friendly, and fully featured (queues, credential vaults, pools, etc) you'll kill it! Good luck :)
Also yes i'll try to accommodate all these things in future iterations of the website. thank you for the comment tho , really appreciate it
Sometimes, interested things are boosted by dang. This doesn't seem interesting enough, so I doubt it was.
Be useful.
But what I really want is a workflow tool that integrates with low-code in the following way: as records come in, they are stored somewhere. There is an interface where a user can "claim" a record and then do their work on it. The workflow tool handles concurrency so that a record can only be claimed by one user at a time. The user either finishes processing the record and it moves on in the workflow, they discard their work and it returns to the original state so that it can be claimed again in the future, or they save their work so that they can come back and finish processing it later. There would need to be some kind of time out mechanism or a way to return a record to the original state.
The actual processing of the record happens using a custom interface that is built with low-code. So for text annotation, they land on a custom text-annotation interface when they claim a record.
Does that make sense?