When we posted Retool last time, we thought it was a cool idea (visual programming + functional reactive programming). But we didn't really know whether it was useful, and whether people would pay for it.
Since last year, we've been hard at work talking to customers and writing code. We discovered that internal tools (eg. to manage deliveries) is a good use case for a visual programming language like Retool.
Basically, Retool gives you components (textinputs, dropdowns, tables, etc.), and queries (connect easily to APIs, SQL databases, etc.). In a FRP way, they can interact with each other. So your tables can pull in data from queries, and buttons can pull in data from a table's selected row.
When we show Retool to people, they often think "oh! it's visual basic for the web!". And in many ways - it is! Maybe that's something you think is great - maybe not. In any case, I'd love to hear HN's thoughts. :)
Here's a 3 minute video demo I just made this morning: https://cdn.tryretool.com/approval_video.mp4 of me making an approval workflow in 3 minutes
If you're curious how it works - here are the docs: http://docs.tryretool.com/.
Your premise that most internal tools use the same building blocks seems accurate based on my experience, a lot of it is collecting and analyzing data.
I'd also add that the most underrated cost is maintaining a tool, developers are usually excited to build something new and when they're working in a fresh codebase they can build and iterate quickly. The real pain is when no one has used a tool in a couple months but needs it now, and the original dev has moved on to some other project so there's no one available to update or fix it. That's one of the biggest reasons we started using more third-party SaaS options instead of building our own, even if they were expensive and only an approximation of what we actually wanted.
> I'd also add that the most underrated cost is maintaining a tool, developers are usually excited to build something new and when they're working in a fresh codebase they can build and iterate quickly. The real pain is when no one has used a tool in a couple months but needs it now, and the original dev has moved on to some other project so there's no one available to update or fix it. That's one of the biggest reasons we started using more third-party SaaS options instead of building our own, even if they were expensive and only an approximation of what we actually wanted.
That is a good point - and we've used that a few times in sales pitches. The benefit of Retool is that it's pretty clear what's going on (oh, new column added to table, so let's add it to our KeyValueMap too). And so keeping things up to date requires a lot less context.
Thanks for the thought - we will bring this up more in our sales calls :)
Some questions I would have as an engineer...
1. Where's the documentation - it's not linked to on the site.
2. What's your GDPR policy, we have customer data in our database.
3. Can this do Slack bots? We use them quite a bit for reporting, would be handy!
4. What sort of auth schemes do you offer? We provide limited access to some of our tools to third parties who aren't on our Google Apps domain.
5. What sort of APIs do you support. We have some basic JSON+HTTP things that require a session cookie to use because they are only used in web pages we run, and we have an authenticated GraphQL API. Would these work? How do you handle authentication on APIs?
2. You can install Retool in your EC2 instance, and block all inbound / outbound network traffic. I'll send you an email about it!
3. Yes - we can! Curious to hear about your use case though - is it for BI?
4. We integrate with Google, Okta or any SAML 2.0 provider. Would that work for you guys?
5. Any! Yep - we handle authentication in the API query itself, or you can create an API with authentication stored server-side. Here are docs on generic APIs: https://docs.tryretool.com/docs/apis, and here are docs on GraphQL: https://docs.tryretool.com/docs/graphql
WRT cookies specifically - even though requests from the browser get proxied through our backend we support forwarding authentication cookies to the browser that is tied to the user's specific session in Retool. (I thought we had written docs for this but can't find them now. Ping me @ email@example.com and I can tell you how we do it!)
Just on the GDPR front, our DB also has customer data. We currently host on heroku. Does the data we pull in / process using retool go anywhere else except for where we point it?
I will reach out over email - thanks for the question!
For the Slack bots, a fairly common thing we want to do is regular business updates from either Google spreadsheets (that are very dynamic/scripted) or from ChartIO. Some basic interactivity with those bots would be handy.
A few questions.
1.) How does authentication to retool apps work? Can I use 3rd party such as Google or GitHub? Is enforced 2fa supported?
2.) Do you support visualizations from data such as graphs and charts?
3.) You mention to allow access to my database we just whitelist the Retool IP. Are there a group of IP's to whitelist? If somebody compromised your service, then they have access to my database. A bit scary.
Yep - we integrate with Google, Okta, as well as any other SAML 2.0 provider (e.g. ADFS).
> 2.) Do you support visualizations from data such as graphs and charts?
We have a few charts, but that's not our focus. If you're looking to graph a lot of things, you're probably looking for a BI tool like Looker.
> 3.) You mention to allow access to my database we just whitelist the Retool IP. Are there a group of IP's to whitelist? If somebody compromised your service, then they have access to my database. A bit scary.
Yep - there is a group of IPs for you to whitelist. But yes - if you care about security, you should probably be using the on-premise version of Retool. That's hosted by you, and you can control all inbound + outbound traffic. (70% of our customers are on on-premise.)
Thanks for the questions!
2. We do! Check out the charts components under "display".
3. We take security very seriously. If you want to keep security 100% in your infra, we support on-prem deployments.
Slick, and great landing page, I’d like to try it.
A small note: shared that in our internal slack and it just displays as a "preview" the domain, title and meta description of your page. I think Slack uses the `og` meta tags too, so adding a more elaborate description and an image would help :)
1. Show some data on a grid based on user input.
2. Let user select a row.
3. Provide different buttons to take actions on the selected row by doing an API call.
Then your tool solves the above problem extremely well (based on the tutorial I saw). And I guarantee you that any organization with tech teams have need to create plenty of such 'mini apps'.
I recently started a new job as a technical lead and I am going evaluate this tool seriously. Due to the nature of the business, we will be prefer an an on-premise solution. Do you have existing clients who use your on-premise solution? How are the updates to the tool distributed? And most importantly, what's the pricing like? Feel free to reach out to me via email.
BTW, you guys have done FANTASTIC job on the main page design/copy. It's been a long time since I saw a product website which instantly sold me on the idea. Well done!
I will send you an email! Thanks again for the kind words!
Cold Fusion shipped with a wizard to build web CRUD apps against SQL databases, which worked, and you could then continue coding from. It wasn’t bad, and came long before Rails or Django admin.
This feels like democratizing that.
EDIT: signed up, ran through the tutorial, and I'm suitably impressed. This is a very polished product.
Will you support command-line tools? There's a few places where I can see my admin tools using command-lines to make things happen. Might be nice to be able to spin up a docker instance and run a set of command-line tools in response to an action, or to provide the contents of a table.
A few questions:
- Why is there only support for Google Sheets query on-premise?
- How many users can access an account in your free tier? This might be a way to better segment between free/first tier - add a limit of ~3-5 users before you need to start paying for the service.
- https://github.com/tryretool/retool_onpremise.git 404s for me - are you adding customers to that repo manually before they can clone it?
- Whoops - we forgot to update that - we added it to cloud a few weeks ago. Updated our docs - thanks!
- Hm - good question! I think there's currently no limit, but yes, that's a good idea as we scale. We want to have a "generous" free tier because most engineers we meet find Retool fairly interesting. And so we want to allow people to play around with, without having to pay us.
- Yes - that's correct for now. Once we have a better on-premise process, we'll open it up! :)
Thank you for the questions and feedback!
Also just the general styling/design of the entire site + retool itself is so well done.
We created the animations ourselves with https://github.com/drcmda/react-spring.
Projects like these blur the lines between "coding" and "configuring" software, and I think the success of Retool long term will be understanding how to walk that line. The benefit of code is that it allows for greater complexity to be understood meaningfully, and configuration's benefit is that it is easier to learn. I think if someone is expecting to code and gets a configuration interface, that's OK until it limits them, and if they want to configure and end up having to code, then that's a fail for them as well.
Perhaps https://github.com/formtools/core ? Or https://form.io/ is open-core but more polished (from the screenshots).
For example, in Retool, you can make a `PUT` request in a Postman-like GUI. And when you press run, we handle the data flow for you. In Google App Maker, you still have to write custom JS to call APIs or execute SQL queries: https://developers.google.com/appmaker/models/external-data-.... nd when you do call them, you have to worry about error handling, setting `isFetching` states, etc.
Not to mention that even trying to create a demo for internal teams that would build tools using this with our data would mean miles of red tape that makes it a heavy sunk cost before we even get to the starting line.
If this had some form of containerized app (like Influx Chronograf as an example), then I could create demos that would likely lead to license purchases. But without that, we'll just keep building internal tools with internal frameworks.
Great idea, heavily limited by not having something I can deploy internally without an enterprise license.
(There was surprisingly - no good open source library for drawing bounding boxes / landmarking on images. So we built our own - and now every Retool user gets to use it!)
I would definitely urge people in my company to give this a try for future internal tools.
I hope it works out as well as you've sold it [=
The support has been amazing as well. Very quick response times and fixes when we report any bugs.
Btw, I think I remember you back from a Startup School some years back! You dropped me home. Hi!
On prem docs: https://docs.tryretool.com/docs/setup-instructions
If you ever need to build an internal tool, do give them a look before you decide to build it in-house. Wishing Retool all the best!
We’ve considered “business apps” (vague), “operations tools” (unclear), or “CRUD tools” (sounds unimpressive). What do you think?
For every frontend team out there, this should be the goal of your development efforts--to build a component library like this that can be used to rapidly compose any kind of application.
Question: Do you use (P)react or some other framework for your components, or have you done all of this component synchronization from scratch?
Bug/Typo (Chrome): I can't click on the "Local Storage" section in the Component reference, and the description for `localStorage.values` is incomplete: "A key-value store with the data with all the".
Thanks for finding both bugs! I’m on my phone (in bed) now, but I’ll fix it tomorrow morning. Appreciate it! :)
"Gneiss is a spreadsheet tool for using and analysing online data. It contributes many extensions to the conventional spreadsheet model to support using and analysing web service and other hierarchical data, and creating interactive, data-driven web applications."
(I should reply to your email from last week - sorry I've been really busy with launch!)
EDIT: Ah I see. I should contact you. I'll do that.
We build a bunch of tools on top of React-Virtualized which is a brilliant framework (by one of the core devs of react). But obviously what you have is a brilliant end-product.
This is incredibly polished and amazing and great. Well done!
Only thing I wanted was a dragger on the right hand side of the table so I could pull the table to be wider.
Also, I'm wondering, it looks and works so great, and the UI has so many parts, what did you build it in?
Yep - as tennien mentioned - React.
thank you! the frontend is react + a ton of customization