First post here, forgive me if this questions has been answered, I’ve had a good rummage through the forum’s posts and could not find a solution. Anyhow, my knowledge on API’s is new, but wondering the best route for compressing a set of users photo uploads (and possibly re-sizing) via API route and then save back on Bubble’s storage servers?
In reference, this is for a rentals site where a user can upload up to 12 photos for a listing and therefore the initial photos will be quite large (6-12mb range per photo), hence would like to compress this before saving.
@romanmg I dont suppose you are able to shed some light with your expertise on API’s? I’ve read through the guides you personally offer, but I’m still slightly puzzled on what solution would work. Thanks.
Hi @luke2. I have run into the same problem and would love to have this functionality in my app. Did you and @romanmg perhaps find a solution to this? Thanks.
Yes Gaby was very helpful with providing some insight into the possibilities with using an API for the job. Unfortunately I haven’t gone ahead with implementing just yet, but plan to later this year.
Essentially TinyPNG (https://tinypng.com/) looked good for the job, as the pricing was fair & flexible plus the API was solid and does a decent job of compressing.
I am sure if you want implementing you can book Gaby in to sort if you are not to familiar with API’s via the Bubble platform.
Here is a quote from Gaby’s testing and suggestion for implementing to shed some light.
My suggestion is to have your users upload to Bubble first to generate an initial URL to send that URL TinyPNG. The service will compress the image at that location and send back a compressed image on TinyPNG’s servers, which, you could copy back into Bubble if you’d like. You’d also delete the original (larger) image you used to kick this all off.
I suggest this method because uploading files via API is still a bit shaky and limited. If you can just send a URL to the API, it’s so much easier.
Looks like TinyPNG has compression & resizing options AND saving to Amazon S3 option if you’d prefer to keep it all completely off Bubble and use your own S3 bucket (even better if you want to scale super big).
Hi Luke, thank you for the prompt and thorough reply. This definitely seems like the best solution and Gaby’s suggestion of using the URL is nice and clean. I will try it out and share it with you if I get it right.
Great, glad you found the note useful. I think the speed of using the API to compress and send back data was reasonable. But as Gaby suggested, it may well be worth using a animated loading bar or gif while it does the processes. Also something worth mentioning is the 50mb transfer limit per item
That would be great. Happy to do any testing or feedback in return.
Realize this thread is old, but I had some short time ago thought about the same issue and, upon investigation, decided it was “not a thing.”
Even if your source files are huge-ish, at the presentation layer, Bubble seems to serve up a version of the file appropriate for the page depending upon screen size, size of element on the page, etc. This happens automagically and seems very performant, as they say.
So AFAICT there is no benefit to forcing some type of pre-compression step when saving images. In fact, it’s nice NOT to do this as now you have provided your user with a backup of the original file which they could download, etc.
If anyone knows differently, let me know. But basically, this seems to be one of those “don’t do this” types of things (but it’s an issue that will come to mind for many folks and seems to get discussed here on a regular basis).
The thing I was most worried about was not so much the aspect of previewing the image/s, as like you’ve said, it seems to fair pretty well on page load with imgix and Amazon S3 - but the storage on Bubble set to 10GBs. I may have a owner upload 12 photos, possibly 5-10mb photos, and I was slightly concerned in the long run it would eat my data.
I know Bubble offers additional storage, but its an extra $10 per month for an extra 10GBs.
With this said though, I am using Croppie and with the latest release 1.2.0
It seems to let you save and specify the quality for some slight compression. I’ve yet to test, but hopefully this can bring the file size down a bit, if so I’m very happy
Sometime this week I will test and post my findings if anyone is interested…
Ah, I see where you’re going with that. Yeah, minimizing storage usage MIGHT be something to be concerned with… If so (and you’re probably already aware of this), there IS a processing option built into Bubble. See: Introduction - Bubble Docs
(There’s an option there to select quality, which I believe forces file to be saved as jpeg with the selected quality level.)
Edit: I had asked the following, but [derp] I found it (logs > usage tab > scroll down to storage).
BTW, is there actually a place in the Bubble interface to check one’s current storage consumption? If so, I’ve not actually found it. (Kinda makes me wonder if this is something that is actually enforced/monitored… hmm.)
@mishav: Ah, like report admin type data in your own custom Bubble app’s admin pages? I don’t think that capability exists. (But would be cool [perhaps essential in certain applications] if you could show a user things like ‘here’s how much storage your uploaded files are using’…)
Has there been any update on this type of information? I’m working on an app that needs to rely on displaying the amount of data and disc space being used by any particular user.
