Limit of Retool?

Discussion
1

Hi Retool gurus & team members

Coming from engineering background, low-code platform is a great solution for me, and Retool stands out among the rest. When I saw this post and @srikrishnas answer, coupled with my experience so far. I couldn't help but wonder:

Retool is certainly a lot more than a dashboard builder now, and feels like it can build a lot things. But where is the boundary when it's not the right solution any more?

As an analogy, regardless how well a hand screwdriver is engineered, if you need to fasten 1000 screws, it's the wrong tool. If you only need to undo a couple screws, an electric screwdriver is likely the wrong tool as well.

Retool is certainly "a very well engineered tool", but like every tool in the box, it has its job types.

This is a very high level question, and its answer will depend a lot on use cases. But there might be some sort of general description, or common denominators.

In my specific use case. I'm hoping to build a somewhat hybrid of CRM & task management, because our current SaaS are scattered and doesn't integrate very well, plus some procedural we have are simply not supported in any SaaS we know of.

It's going to take time to build, and it'd possible turn out to be a mega-app, at least for us internally. End goal is like below

  • operate on 20-40 tables in postgres
  • these tables can group into about 10 modules, each module will need it's own CRUD
  • each modules CRUD has to to split into: list page, detail page, upsert page
  • navigation between all these pages, not sure if this quantify as complex nav
  • on top of all these, several dash board (report) pages
  • in the back end, integration with maps, email, PDF, other SaaS
  • and ultimately, client portal page if possible.

So, if my goal is 1,000,000 screws. Is retool a hand screwdriver? Or an electric one? Or I need AI powered Humanoid Robots...

6 Likes
2

Building a crm myself, 70 tables on my end. My crm is split into many apps, using multi-app linkage. Also following the best practice to separate out complexity using modules, to make it easier to maintain.

Even after following the best practices, I'm noticing performance degradation when combining apps with many components / modules within tabbed containers. Slower clicks, slower navigations. The performance debug tab shows that even with few query runs, more components and modules balloons the HTML Elements & Dependency Graph Nodes.

It's like after a certain threshold, an app with too many components, modules or queries will become clunky.

Areas I think are impacting performance:

  1. Modules can't be lazy loaded, even with module queries set to manual run, the dependency graphs sky rocket. It gets even worst when modules are within a modal or drawer frame.
  2. Containers with multi views that house many components and modules
  3. Queries in the query library seem to run slower than the same queries in apps
  4. Modals or drawer frames when opening many components or modules take a moment to resize
  5. Components inside modals / drawer frames in modules have delay when interacting with them

I've limited all query runs to the minimum / manual and I'm still finding these issues. I tried to spin up a self-hosted instance near the server and the issues still persist but only slightly better.

1 Like
3

Been using retool for a few months for our team, I built all of our apps, running self hosted

It's taken sometime to learn and build out as I do not have any engineering background but have quickly picked up POSTGRES, HTML, CSS, JS and we've just moved our entire team of 21 over to using it and processes are way more efficient now

A few things I've learnt along the way

  • Don't be lazy, name components appropriately
  • Building it all on one app is unnecessary and restrictive
  • Separate your teams into folders, and each team folder should have it's own apps that work together
  • If you're app is getting slow, make sure you're not overusing it outside of it's main purpose and make sure your DB is appropriately indexed
  • Don't let any queries autorun (run on change) unless absolutely necessary, use the "on Success" event to trigger queries in series starting from one query that runs on page load
  • REMEMBER error handlers, makes life in the future much easier when you've already prepared for complex logic and connecting components.

So far loving retool as a product and the thriving community here building everything out!

What are Retools limits?
So far, I've not found many. I've seen people trying to recreate Slack for example and then complaining but obviously that's not the intended use of Retool. Connecting API's of all our service providers has been wonderful from a Retool perspective.

We still use our old self-built back office for a few tasks where speed is critical, as our back office is Prisma on POSTGRES and it runs like lightning - I think there's lots for me to optimise with Retool and the queries I've built to improve the speed but I don't think I'll be able to achieve what our customer BO achieves, but that's fine with us

We're currently looking to upgrade from Business to Enterprise to make good use of the wheelable and publishing abilities, the whole experience with Retool has been incredible and educational.

2 Likes
4

@metechnologies & @Ollie_Bednal thanks so much for sharing your experience, I'm on a similar journey.

@Ollie_Bednal how many tables you have in Postgres and how many apps you end up building? Are you getting the performance issue that @metechnologies mentioned?

I'm wondering if your self hosting would help make things a bit faster? Or the performance degradation mainly comes from front end?

I've only build a 1st step mobile app, 6 main functions involving a dozen pages over ~15 tables.

  • I've noticed the speed ok (but not great) even on samsung flagship
  • Definitely can feel slowness (still usable ) on mid range samsung.
  • Being mobile app, and due to our app logic, it can't be split up.
  • Retool do load EVERYTHING on start, only queries can by triggered manually

My next step would be having a crack at building web app, definitely splitting them up

1 Like
5

Our current DB's (we have two connected to Retool) have a total of 212 tables between them. I've built 37 apps so far (29 completed, 8 in progress) and we have plans for a further 7 for the remining insights we feel we need to be operating optimally. (However, our marketing team keep requesting new apps/insights so I imagine there's going to be quite a few more when we've finished haha!)

I never tried the Retool Cloud version so I can't really give a fair comparison between the two, however, the issues I experience are are a result of not having all our tables indexed right now in order not to slow down the indexing process (balancing act).

I have only has to reboot twice cause it hung/crashed our server container, and one of those occasions were human error when I caused a huge dependency by accident eating up all the Ram.

We've also stuck to WebApp Desktop views so far as it's the primary end-users method of access, haven't bothered with mobile WebApp or PWA's yet other than our main company dashboard so that everyone can get quick insights on the go about the key KPI's.

Maybe you could look into optimising queuing of queries and scripts based on visibility if it's mobile app based? I imagine you have data that is initially out of sight, or perhaps in a different tab in a containers, I'd make sure those only run following the succession of a query/script that impacts a component that is in view as soon as you open the app. Furthermore, if the slowness is derived from front end activity, maybe using a script to identify if the component is in the visible window to determine if it should be hidden or not? That could potentially help with page loading times, though might add clunky-ness when navigating the page.

Good luck with it! I know the community seem super supportive so maybe we/someone could help with something specifically slowing you down

1 Like
6

Thanks for the detailed explanation.

On retool mobile, it loads all pages and all their dependency graph (cloud be using wring lingo) on start. I had to use a lot optional chaining so console doesn't get flooded, and I don't think there's any method to change that currently.

Fortunately everything else we need to build are web. so will be taking you advice

1 Like
7

Hi @rxunique,

I think you will be very happy with using Retool for your particular use case. The boundaries of Retool are a bit of "anything that is not a database entry information management solution".

Be sure to take the advice of the others on the thread, I would also include the following:

  • If you have 40 tables with likely 10 CRUD sub operations, don't choose a heavyweight editing solution like a modal form for every one of those.
  • I suggest for most of the small CRUD operations you use editable tables. Dialogs/modals/drawers are good for more complex items.
  • Be aware that the component library is a bit simplistic and doesn't offer even simple things like Form.isDirty, which we have had for years in desktop frameworks.
  • Be prepared to pay for the Business plan. For an app of your size to will have enough users that you will need to allocate access rights and Team does not do this.
  • Watch out for poor documentation. It lacks detail and the weak typing of Javascript doesn't help. Some of the demo videos are still using the old Table component.
  • Use ChatGPT4 to get answers. It's far easier than trying to slug through the Retool documentation and the community forums.
  • You will be constantly hitting up against the wall if you try to make the UI do anything remotely interesting. It's going to look stock-standard in look and feel. A lot of UI components lack basic things like font size, event handlers and other expected properties.
  • As mentioned by others, name things properly eg frmClientsJobsDetailCustomerId
  • Copying code and reusing is essentially impossible. Get a good carpal tunnel support as you will be clicking on property boxes a thousand times a day. There's no real find/replace.
  • Don't have a firmly set idea of how your app will look and act. There is a good chance the framework won't let you implement it that way.
  • Like all Javascript front end development, these is no way to test anything other than running it and clicking on everything that is clickable. I can't imagine this will ever go away.

Development time is an interesting one, it's really slow at first as you learn the declarative method, then it gets really fast for a while and then it slows down as you try to work out how to make it do the more complex things you want.

Things have improved in the last year as Retool have fixed requests. The linting is reasonable, cyclic dependencies finally appear in the console (thanks to me I think =), the new Table is good, the postgreSQL backend is OK (although they haven't done anything to the UI in a year).

Overall I think you should definitely spend a few weeks implementing something as a test. Just use the cloud to begin with. Don't worry that all the documentation videos involve making an app in 6 minutes. Those cases are trivial and for marketing purposes. Don't get discouraged.

Hope this helps,

2 Likes