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.
Thanks in advance,
Hi there,
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).
Hope this helps.
Luke.
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.
Thanks again,
Hi Leon,
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.
Cheers,
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).
Hey Keith,
I agree with what you’ve said, all makes sense.
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
