We’re working on performance enhancements for our Bubble.io-based application and are seeking your support in implementing a solution that leverages AWS S3 and Lambda functions to optimize how we store and manage our users’ projects’ cover images.
Please find below a detailed breakdown of the scope and expectations for this task:
ObjectiveTo offload project cover images currently stored in Bubble’s database to AWS S3, optimize them using AWS Lambda, and ensure seamless updates back to our Bubble app for performance improvement and storage efficiency.
Current Structure- Data Source:
Images are stored in a Bubble data type called ‘V2.0-Project Display’, within a field named’V2.0-Cover Photo
Proposed Workflow (if you have better solution that you alreasy implemeted before, please propose it)
Image Upload to AWS S3: Via a Bubble backend workflow/API call, retrieve the V2.0-Cover Photo URL and upload the image file to our designated AWS S3 bucket named ‘Bucket-Original’.
Note: The new image name should follow this convention: [Bubble unique ID]-[upload timestamp in UNIX].png Example: 1747221161250x302004215203996800-1747817847.png
Image Optimization Using Lambda:
A Lambda function should be triggered post-upload to ‘Bucket-Original’, responsible for resizing the image while preserving visual quality.
The resized image should then be saved to another S3bucket named ‘Bucket-Enhanced’.
Webhook Trigger & Bubble Update: Once an image is saved to ‘Bucket-Enhanced’, a webhook should notify Bubble’s backend. And the Bubble workflow should:
Retrieve the optimized image’s public S3 URL,
Update the V2.0-Cover Photo field of the corresponding V2.0-Project Display record (identifiedvia unique ID).
This all needs to be done taking into account need authorization with any used apis
Please DM me the following:
Time & Cost Estimate and/or any suggestions of better approach that you already have implemeted for previous clients.
Developers who already implemented such a solution will be prefered.
Hey Ahmed, are you aware that Bubble already uses AWS S3 for file / image storage and that images are automatically optimized, cached, and served by Imgix (not AWS) via Bubble’s tight integration with that service? By default, the image that’s rendered on a Bubble page is not the full resolution image that was uploaded by the user and is not being served from Bubble’s AWS S3-backed storage. Instead, it’s being served from Imgix’s highly optimized CDN.
If you’re already aware of this, I’d be curious to better understand your rationale for wanting to migrate away from Bubble’s image handling.
EDIT
Just wanted to add that if the main concern is efficient storage of the originally uploaded images, you could run an optimization on the existing images (as you describe) but upload the compressed versions back to Bubble storage under a different name. Of course, you’d need to update any references to those images in the Bubble DB as well. Once the process is completed for all images, delete the originals.
Then moving forward, you could use a plugin to compress images client-side (before uploading) in order to get the most out of your Bubble storage. That way, you could just continue to use Bubble and leverage its built-in image optimization and rendering capabilities. It would cost a few WUs one-time, but it would make things simpler and easier to maintain in the long run.
@sudsy Thanks for the recommendation I really appreciate it
bubble optimize at the same size that the users are uploading their Projects’ cover photo (i.e. User could upload jpeg, gif, png files that are 1.5 MB) and what we need is to reduce the cover photo’s size to kilo bytes instead without impacting the quality of the image they are displaying to showcase their work.
We want to do all the heavy work for them without bothering them nor making them even notice that we are improving our app’s performance.
Just to clarify, Bubble does not alter the original image - the one that’s uploaded to Bubble storage - at all. However, that image is not served directly to visitors. That’s just the “master image” from which web-optimized versions are generated. It’s only web-optimized versions (not the original) that appear in the context of a rendered Bubble page.
To illustrate… Let’s say a user uploads a 12 MB profile photo directly from their phone. Bubble will save that 12 MB image to storage. Now let’s say a small Image element is placed inside a RG to display a list of users. It’s only a scaled-down compressed version that appears on the page in the list of users - not the 12 MB master image.
So while the 12MB image does take up Bubble storage, it does not adversely impact page load. It does, however, consume more storage than it needs to and also adversely impacts the user experience since they have to wait for the 12 MB image to upload.
That’s why I suggested compressing the images client-side via plugin prior to upload. That would improve the UX as well as conserve Bubble storage.
I can help you with implementing lambda function as you wanted.
Regarding the image optimizations, we need to figure out how to optimize newly uploaded images.
