Understanding Bubble's "behind the scenes" image handling

My app will allow registered users to upload images that will be viewable publicly, and I’m finding my understanding of Bubble’s image handling a bit lacking. I’d like to better understand what’s going on so that I can make informed decisions about how best to implement aspects of my app. What I observe is the following:

  • Using the Picture Uploader element results in the image file being stored on AWS.
  • The imgix service is used to automatically scale/crop the image for display based on the size of the element in which it’s displayed.
  • Storing an image in the database or as part of a page’s design saves a reference to an imgix-hosted version.
  • Deleting the image via the Bubble File Manager deletes it from AWS, but the image remains hosted on imgix (and so will remain visible in the context of the app).

Some questions:

  • How long does the imgix version stay around?
  • Does the imgix version take up storage space on my Bubble account? (Seem not.)
  • Given the price of Bubble storage, might it be best to reserve it for design assets and not use it to store user-uploaded content?
  • Is anyone using Google Cloud Storage for user-uploaded content instead of AWS?

Any input would be appreciated!

3 Likes

Here’s my understanding (if anyone knows otherwise, please correct me).

  • If you save an image that you’ve scaled or sized with Imgix, then the new, smaller sized file is what is saved in AWS.
  • If you store a file in AWS and then display it and use Imgix to, say, shrink it then Bubble will run that image through Imgix and reference the smaller image on the UI (but it’s not saved anywhere, expect perhaps by Imgix)
  • As such, using Imgix doesn’t cost you storage space.
  • For many, the cost of image storage is likely really cheap (and most won’t exceed Bubble’s free storage tier) until they’re at a fairly large scale. As such, for most it probably isn’t worth the time/effort to minimize cost until they’re at scale.

Thanks, @sridharan.s! I’ve tinkered a bit more, so here are some additional thoughts and observations…

  • Simply using the Picture Uploader element causes the image to be saved on Amazon (which makes sense since it has to be uploaded TO somewhere).
  • Even if the image is modified via imgix for display (e.g. cropped), the “master” (original dimensions and quality) is preserved on imgix and does not seem to rely on the AWS copy.

What the latter point suggests is that the AWS copy could be deleted right after saving the uploaded image to the database, because thereafter, the “master” copy on imgix will be referenced. And that suggests I wouldn’t have to purchase additional storage after all. I would simply ensure that image files are removed from AWS after uploading / saving so that they wouldn’t eat into my Bubble storage. Is that right?

BTW, why can’t I save the contents of an Image element to the db??? The Image element doesn’t appear in the list of page elements when making changes to a thing. I’m forced to save from the Picture Uploader element. Why? :confused:

Ok, after thinking about it, I’m guessing it’s because the Picture Uploader is an input element, whereas an Image element is for display/output.

Ok, so after reading the imgix docs, the potential problem with this is that if Bubble issues a “purge” request to imgix, then imgix will delete all derivatives if the original source image is missing, thereby leading to 404’s. And since we have no control over whether Bubble issues a purge request, the safest bet is to ensure that the original source image remains in place. Thus, it seems purchasing storage to accommodate user-uploaded images would be best. (…which is a bummer given that most of the time the original source image would never be needed again)

EDIT: Additionally, imgix automatically invalidates their cache periodically, and we (Bubble users) don’t have control over the cache settings. Long story short, there’s no way around hosting the original source images which, for an image-centric platform, means paying for additional storage. Oh well, at least I now better understand what’s going on behind the scenes when it comes to Bubble’s image handling.

1 Like

About this topin: does bubble use imgix’s cdn and which data centers pictures are being distributed? Is there any difference between dev and live?

Hi @boostsalesgroup,

I can’t speak to which data centers, but simply looking at the image URLs on my app’s pages shows they’re being served from a cloudfront.net subdomain, which is apparently an imgix CDN.

There doesn’t appear to be.

FYI, Bubble automagically processes images through imgix even if “processed with Imgix” is not invoked on the image via the dynamic expression builder. Doing so, however, provides explicit control over certain aspects of the processing.

2 Likes

@neerja do you know which CDN zones/datacenters bubble is using to distribute images? Does it include all chached files?

Is there a difference between dev and live?
I’m just thinking that pictures do load pretty slow in Europe. 300kb image loads with 2-3 second delay.