I would assume exposing their spaghetti that comes with such a platform is a big concern.
Let alone managing bringing things back in after someone gets creative.
I would assume exposing their spaghetti that comes with such a platform is a big concern.
Let alone managing bringing things back in after someone gets creative.
Does that count?
If so, I think the lesson is you need to keep the no-code side way, way less ambitious than is theoretically possible in order to keep everyone sane and you might actually have a useful tool that doesn't dig you into a big hole.
I thought it was pretty productive and honestly sort of miss that kind of development
The result was I wasted 6 weeks of time when I should've just spent 2-3 days prototyping and then throw out the tool once I had a good idea of what we actually wanted. In the end if didn't matter since the project died anyways :/
On the client side you can do something similar with javascript.
- Amplication: Last I checked, they allow defining data structure & endpoints etc. before exporting to Nest.js Boilerplate with niceties. They sync to a separate branch on GitHub, so you can use it alongside writing actual logic into the boilerplate, and merge new changes from Amplication to the main branch. - Draftbit (React Native based Mobile App builder). The builder is not very great, they lack a bunch of features. They make up for this by allowing the developer to add custom JS code very easily. You can write your own Custom React element inside the editor, and with a little massaging things can fall into place. I'm not saying this approach should be abused, though. The team told us once that some of their big clients are mobile dev agencies that mostly just use the platform to Storyboard & bootstrap some UI before doing the actual logic in their own code. - FlutterFlow (Mobile App builder). I'm biased because I'm still in the progress of helping a client fixing their mess on FlutterFlow. FlutterFlow's code output is really spaghetti. The developer UX on the builder is horrible, so in the end I still opt to eject and deal with the spaghetti code.
Whether it’s worth it vs rebuilding them bespoke is a different question. Or you have to have an ETL layer between your SaaS vendor and whatever open source workflow runner you’d eject to.