Having recently experienced working with this software development tool, I wanted to offer my review on its use in practice.
Retool is exceptionally good at making the easy things easier. It has many many pre-made UI components that "just work" out of the box. Its styles are way better and coherent than any novice engineer would come up with on their own. It makes it very easy for developers who don't have full stack experience to tie things together quickly and easily.
Retool offers client-direct-to-database-integrations so that you can author SQL queries in the Retool GUI to have it fetch data directly from the database. It has quite a few AWS integrations so that you can call Lambdas and S3 buckets with ease. It also has some custom database and workflow options that allow you to write Python and JavaScript to manage simple data flows.
When you want to put a button in the browser to just get data from a database and load it into a table, it is very good at making that path easy.
On the flip side, I found a bunch of "easy decisions" difficult to manage. When anyone on the team can complete most frontend tasks in a relatively "easy manner", the necessity of architecting a solution to the ever present time problem of, "We need this done now!" is quickly lost.
There will always be the tradeoff of taking time to architect a solution or duck taping something because nobody will care in the long run. Plenty of times, duck tape is the better answer from a true practical perspective on the needs of the moment. There are valid reasons why people acquire technical debt. However, I found the balance in Retool far too weighted towards the duck taping side.
This is technically supported by permitting events to be placed on almost anything in the UI and then being able to call these events from anywhere. "This just sounds like JavaScript in the modern browser." You'd be correct, except for the fact that modern software engineering ecosystems have given us many tools for battling complexity. The component model is very prevalent for a reason in frontend architectures. People scope the complexity of mere buttons down to a single file, and then hide the complexity of the button by providing a single exported API from that file. "You render the button component, click it, and I'll provide the desired side effect." The problem with Retool is that it becomes very very easy to trigger these side effects, like database or api calls, from the global scope, because, practically speaking, all work is done in the global scope.
In my experience, it has been very hard to work and debug in such an environment.
Inertia is truly a law. Bodies in motion tend to stay in motion, and bodies at rest tend to stay at rest. It was not easy to migrate off of Retool and into a proper frontend framework (we chose React but that's beside the point of this article), but if you, curious reader, ever find yourself in a similar situation, the following may provide you with some ideas.
People can talk all the crap they want, iframes are still around for a reason. The initial plan was to iframe a frontend app and use the aptly named, pre-made, Retool provided iframe component to port it in. Drag it onto the UI, give it a link, and viola, you have an iframed app. This was all definitely going to work except we couldn't figure out how to pass information to the frame and back. We really needed to be able to get information from the Retool parent frame and pass it into the child iframe, and vice versa. The primary roadblock was that Retool ran all of the GUI entered JavaScript in a sandbox.
I don't actually know the technicalities (nor do I plan to find those out) but suffice to say that JavaScript the user provides to Retool through the Retool interface cannot actually access all the browser APIs due to the sandboxing Retool does. So you can't actually host an iframe and pass messages back and forth as the parent, because Retool does not allow you to access that execution space (at least easily anyways).
So one of the APIs that Retool did provide, interestingly enough, was the custom React component. You could download the Retool bundling library (which looked essentially like esbuild with an api key) and build your own user provided React components. So eventually what we did was build a SPA into a single component, bundle it, and ship it to Retool, and then, huzzah, we had our React SPA running in Retool. Additionally, the Retool provided tooling also allowed us to call Retool APIs from the component, meaning we now had a way of passing information back and forth from the component to the Retool parent page, so incremental adoption was now possible.
The problem started becoming deployment. Every time we wanted to ship a new version of the custom component, we would have to delete every instance of the old component, refresh the browser a couple of times, and then tenderly and gently drag the new custom component onto the Retool canvas UI builder and say a prayer that Retool would have the new version. I'm certain this process is a whole lot easier when you're not trying to ship an entire SPA in a single component, but sometimes you've just gotta do what you've gotta do.
However, we had one more ace up our sleeve to try and make our lives beter.
If you don't know what module federation is already, essentially it's a framework for dynamically bundling and loading remote code into the JavaScript execution context (typically a browser) and calling eval on it with a lot of DX baked in.
This worked really well for our Retool use case because all we had to do was create a "wrapper" component once. This component would be provided the url of a SPA plus some other metadata, and it would just call and render the SPA into the spot we pointed it at. We only had to "drag it onto" the Retool canvas once, and then just configure it. Now, we were able to do full SDLC from the comfort of common tooling. We never had to touch the Retool UI unless we were debugging, or wanted to figure out exactly how it would look in the Retool canvas. I was even able to get hot reloading working from a local vite dev server into the Retool canvas, which up until this point was a philosopher's stone, mysterious and unattainable.
Retool seems like a great tool for internal teams building simple portals who have no significant frontend experience, but, for any seriously complex project, I'll plan on leaning on modern software tooling. Not to mention the Retool pricing seems pretty steep compared to hosting an app on AWS or plenty of other places.
Eventually, we were able to incrementally migrate the particular app we were building completely off of Retool.
This review is solely based on my experience, and should my review be capable of technical refutation, I will gladly acknowledge that I was wrong and proclaim that I do in fact have Retool skill issues.