31–40 of 40 posts
It's a crowded space out there, I think Retool is a beautiful crowned beast - leader of this space - but personally I tried and failed at using it many times. It was just too much UI/complexity to even get through a simple hello world! Nonetheless good luck folks, there's definitely a market there and a lot of hungrier builders who wanna build stuff
I see someone has asked one of my classics for low code (how to test it thoroughly) - I'll ask the other: how is change control managed? Can another person review a change, be it in behaviour or visual, in a diff, as well as running automated tests, before a change goes live?
For us, we're trying to strike the balance of nocode and lowcode so a lot of the advanced features of version control and approval flows are not a priority for a lot of our users. I imagine this will change as we grow though
Earlier quoted context omitted.
I see what you mean, I guess the best and only way to do that would be to write integration like tests with something like Cypress, as you could with any web-app. If you want to verify that it works how you want vs how it's setup to work, then you would be better leaning on existing tools that can do that. My point about not needing to test it was about the implicit trust you would put in a platform like this, just l…
I wouldn't write unit tests for an external library but any integration test will implicitly test any external libraries that are in the code path. That's one of the points of integration tests - catching cases where the underlying code still works as it's supposed to but the way it's supposed to work has changed. Whether it's an external library or code you wrote, your goal is to test that all the pieces still fit t…
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. 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 ne…
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.)
How does this compare with some of the more 'enterprise' style tools like Alteryx? What would you say are the main differentiators?
Alteryx in particular seems to focus more on analytics. You can build dashboards and charts with Noloco but our focus is more on CRUD operations - enabling you to give other team members access to data and control the permissions they have (read-only, update, create records) via permission rules at database level. In general, we tend to see that existing enterprise-focused tools tend to be more low-code rather than n…
We're launching a product early next year that can do all the things you listed + more. It's built on top of users Workflows and the rest of the Cloud platform, but it's an exciting AppBuilding experience once you've done the Analytics part. https://www.alteryx.com/products/alteryx-appbuilder