No code hits a barrier when UI and DB requirements diverge. Usually for internal apps two separate teams/devs are involved, so it happens pretty soon. For instance, a simple print human readable status for the enum field in the DB needs code. Throw in REST API calls to internal/external services in this mix and the need for code is almost immediate.
Last year I built multiple Retool apps, all simple ones, but they needed code for data transformation and joins. What got in the way were operational items:
- Punch a hole in our firewall to access internal APIs.
- An internal Retool deployment was out of question since their install isn't light (requires a Postgres). Btw, Superblocks solve this problem quite elegantly by separating the control and data plane.
- Code reviews and testing were a constant challenge.
> No code hits a barrier when UI and DB requirements diverge.
Yup.
Yes and: You'll eventually have to drop down to code. For all dangly bits, that last 5% of fit and finish.
Then you're fighting the framework (tool). Completely negating the benefits of the "no code", visual design tools, patch cord programming, etc.
--
I did A LOT of data munging for healthcare. Starting in the mid aughts, that generally meant "HL7 interface" and "orchestration" engines. Whatever that's supposed to mean.
SeeBeyond (JCAPS), BizTalk, InterfaceWare, Talend, etc. A handful of others. Each was worse than the last. Though none was worse than InterSystems Caché. (And all that "Web services" nonsense like SOAP and WSDL; so awful.)
It'd take us 3 months to onboard experienced devs. Totally impractical.
--
My solution was to create simple, typesafe, bulletproof APIs and tooling.
For data munging, by analogy, it was like working with DOMs instead of wrestling with strings and innerHTML.
All the networking, queues, retry, errors, logging, tracing, etc. was done by the tool. For the developer, everything just looked like a loose file. So the same code that worked on a directory of local test files would work as-is as the service. Made coding and debugging super easy.
A bit like what AWS Lambda would look like, if it was both useful and usable.
End result was 1 or 2 weeks onboarding, depending on prior experience. New hires were writing and deploying real code to production by the end of our training. And left with all the tools and skills to be self-sufficient.
Actual "interface" code was easy enough to understand that we could do live review with BAs and customer liaisons. Make fixes together. Deploy code updates to prod in seconds.
Our improved tooling greatly improved the team "culture" of working together. Changes requests just became conference calls. Which, of course, beget a lot more additional contract work. (No good deed goes unpunished.)
Congratulations on the funding! I built multiple unusual internal apps for our product last year. Retool is now in my list of "must have" for any thing I build.
The build process took a bit of time and I had to hire an expert on Upwork. Not everyone might persevere. A gallery with examples of varying complexity would make the sell easier.
Don't quite agree with your statement "As the mobile app market continues to mature it will strain against its walled garden confines more and more". On the contrary, I feel that consumers will continue to appreciate walled gardens for their convenience, quality and trust worthiness.
I guess this argument will be tested by the Mac app store.
Last year I built multiple Retool apps, all simple ones, but they needed code for data transformation and joins. What got in the way were operational items:
- Punch a hole in our firewall to access internal APIs.
- An internal Retool deployment was out of question since their install isn't light (requires a Postgres). Btw, Superblocks solve this problem quite elegantly by separating the control and data plane.
- Code reviews and testing were a constant challenge.