Images uploaded to retool storage and used in mobile and web apps are very slow. It takes multiple seconds. It can take over 13 seconds to load 10 images. Where the first arrives in 6 seconds. Even with small images the latency is very high using a fibre glass connection.
It would be great if retool storage had some sort of cdn functionality. Or something like shopify uses. Something that imgix also has. You can add a certain width and height and the image will be cached in that size.
The other solution would be to use APIs to outsource this to google/aws/imgix. But the whole reason we use retool storage is because it’s very easy to use and implement.
I find myself in this situation where I have to optimize and find a new solution even before my app is ready to be used. I rather have this “limitation” after the app is already adopted and heavily used.
Somehow it feels retool storage can only be used for prototyping.
For instance, I know the retool postgresql database is recommended for only lightweight apps and that it’s best to move to an external faster db when you need more speed. But at least it’s fine in the beginning. With retool storage it’s not the case.
Hey @Steven_W! Thanks for reaching out. We certainly appreciate your feedback.
I'm not currently able to replicate the delayed loading that you're seeing but will talk to our engineering team about use cases and get you an update as soon as possible. Your recommendation to cache a minified version of the file could be especially useful. In the meantime, I can recommend a possible solution - query caching! There is an option in the "Advanced" menu when setting up a query to cache the results for a specified duration.
Note that this refers to server-side caching - so you will still hit the Retool servers - and requires that you are actually fetching the image data - not just the url - in order to see a performance increase.
I hope that helps but will definitely follow up with our team and keep an eye on the performance of Retool Storage. If I have any updates for you I'll reach out here!
That would mean we have to store images as a blob in the database I guess?
Which seems not ideal in our case.
Just wondering.. when we cache query results, it’s not invalidated automatically I guess on new records. So if you always need the most recent results, caching isn’t an option. Am I right?
Yep, that's correct - cached query results are not invalidated upon changes to the data source. You can tweak the cache duration but that's probably not going to be the solution to your problems. How big are your files, out of curiosity?
For context, this is the kind of loading times I see on my end when fetching a single image. Are you fetching all the images at once or one per query?
Sorry for the late reply. I thought I answered already. The files are like 300kb. And it's on the native mobile. Not on the app. But also on desktop apps. It takes usually 3 to 4 seconds to load an image if I do not use a cdn. So now I use twic.pics. It helps. But first load is still horrible. Might this be due to the fact that I'm located in the Netherlands?
I return the file name / id from the database and just put the url als source/mapped value. Like this: https://bobbill.retool.com/api/file/46ee81ec-e4e1-4aa2-9dbf-54a044c38d78
This url takes 2 to 3 seconds to load. it's only 200kb.
I'm sure regional latency is a factor, but it doesn't seem to be the primary cause for these load times. The timing of the request is very similar when I use the same resource URL, with the bulk of the delay attributable to server response time.
It's definitely something that the owning team is aware of and they're getting close to shipping a fix that will change the way the /api/file endpoint handles requests. I'll let you know when that goes live so that we can measure the performance impact!
