I am re-evaluating the storage and upload options for my App - Its a graphic design client portal, so we use a TON of files (over 2 TB so far - about 70k files)
The most success I’ve had has been using uploadcare - but that’s about to get expensive for me.
I would like to build a front end UI for Wasabi since the storage is much cheaper.
When I tried to do this before, the ZeroQode uploader seemed to struggle with larger files, and the content delivery was very slow.
Just wondering if anyone has done something like this - Delivering, uploading, downloading - LOTS of files quickly?
Wasabi’s good, I use @redvivi ’s plugin - the only difference is that I host my own serverless function for generating presigned upload/download URLs, as Bubble’s native server side actions take a few seconds to get started, which really slows down the user experience.
+1 for @redvivi 's plugin, and +1 on @georgecollier 's method to generate your own URLs for faster initial upload
When you say delivering, uploading, downloading, that’s all relative to the user’s internet upload speed.
What’s your max file size you would be dealing with? Wasabi and many other S3 services only let you do a 5GB file max in a single request, before you would need to step into a different plugin that sends chunked uploads to Wasabi
You can definitely make the whole interface that shows files, copy, rename, delete, etc.
Also keep in mind Wasabi’s no-egress policy where t hey don’t charge for API requests but you can only download as much as your total storage used for each month. Sometimes totally fine for archival or occasional storage but like mass distributing of all the files to many users might be an issue
An app of mine is a marketplace where video is one of the main features. It uses Wasabi as the main storage, so I figured I might chime in with some useful info.
To make file retrievals faster and stay on Wasabi’s nice list with the download-to-upload ratio, we use BunnyCDN. It’s pretty cheap and, very important to our use case, has a nifty little feature that chops large files into 5 MB chunks which in turn allows our users to easily jump around 3 GB videos without having to wait for the whole thing to load/buffer.
In addition to those, the app also uses CloudConvert’s Thumbnail API to generate video thumbnails.
+1 for CloudConvert, very easy to setup for them to pull the file directly from S3 and even put the thumbnail right back to S3. I think the Thumbnail API also auto-pics an “exciting” part of the video where the frames aren’t all similar. And can make PDF/Excel/Word thumbnails
Since I posted this, a fellow forum member has alerted me to a security issue with Zeroqode’s Wasabi plugin, saying it leaked the secret key. I was a little skeptical at first, but after checking, I indeed found the key exposed in plaintext within the API call, visible to anybody. (cc @ZeroqodeSupport)
Mind I have a plugin supporting up to 5TB chunked upload, but workflow complexity is on another magnitude and would only recommend for specific use-cases, hence the plugin not being published.
This is correct, for both the Wasabi + AWS plugins. With 3,000 installs between them, you’d think @ZeroqodeSupport would be making an effort to fix them (when I know for a fact multiple forum members here have reported the issue only to be ignored). Everything ZQ touches goes to , so avoid where possible. And @redvivi’s Wasabi plugin is just generally good and makes sense.
We always strive to deliver quality products and implement features that cater to many users. However, there are limitations, some of which stem from Bubble itself, like cold-starts. Thanks to @chaostorm for sharing a workaround to tackle this issue.
S3 Services & File Size Limitations:
As @tylerboodman mentioned, many S3 services have file size limits for bigger files. We’ve received similar concerns from several users and have added this feature to our improvement list. Due to our current workload, we can’t provide a specific timeframe, but it’s on our radar for future implementation!
Key Leakage Issue:
We sincerely apologize to users who were affected by the key leakage issue. We found that the keys are visible in Bubble’s dynamic.js file via the website’s source console. As this file is generated by Bubble, we can’t modify it directly. Our workaround involves creating temporary keys that can expire within 15 minutes, preventing unauthorized access to real keys.
@chaostorm, could you please let us know where you found the keys to see if it aligns with our findings? If you have further suggestions to enhance key security, we’re always open to feedback!
Customer Requests & Bug Reports:
@georgecollier, we appreciate your support and thank you for using our plugins. We always strive to accommodate as many requests as possible. If there are specific instances where it seemed like we were ignoring requests, please share them with us so we can double-check on our end and resolve any missunderstandings.
If anyone encounters bugs or unusual behavior with our plugins, don’t hesitate to contact us via the forum or at support@zeroqode.com. Please continue using the plugins that best suit your needs and make you feel comfortable.
This is great info - Thanks! I checked out BunnyCDN and it looks like that is going to be the ticket.
The issues I experienced in the past is that when uploading multiple PSD or AI files the ZQ Wasabi app would hang up. Unsure if it’s the ZQ plugin, or bubble, or Wasabi doing it…
Thanks for the advice everyone - as a no-coder some of the traditional knowledge of the infrastructure of these things is not something I have
Just a little more detail of the issues I encountered in the past:
File loading on the page was very slow (thumbnails) - I believe this is because I was trying to pull down the full 3kx3k image - instead I can use BunnyCDN to pull down a thumbnail or perhaps the CloudConvert Plugin
File uploads would hang, freeze etc. This is almost exclusively when we are uploading multiple PSD or AI files - Unsure why.
Based on what you’ve all said I should be able to build what I need using Wasabi + BunnyCDN + CloudConvert
I greatly appreciate you all. Thank you - You’ve probably just saved me about $12,000
This is correct. Both the secret key and access key are public, in plain text, which you can find my searching for the relevant random element ID in dynamic.js. With that info, you can do anything that the secret key permits (as defined by IAM).
The 15 minute limit thing is rubbish.The 15 minutes you refer to is probably for the signed URL that permits uploading/downloading a single file. Guess what? With the access and secret keys, you can generate one of those for any amount of time (and that’s probably the least worst thing you could do).
Every other plug-in with API keys puts those securely in the plug-in settings so they never touch the client. The acknowledgment of it and then not doing anything about it makes it even worse
If it looks like I’m tearing into you, it’s because I am, because at best it’s poor development practice to allow plugins in this state, and at worst it’s gross negligence knowingly allowing users to pay for your app whilst being aware of a critical issue. You’re a large agency, you know you’re a plug-in factory - with great power comes great responsibility, I suppose.
I’m sure these devs will weigh in by DMs, I’ve spoken to at least two about this…
@ian11, we’re glad the suggestions have been helpful to you! Wishing you the best of luck with your project
@georgecollier, we’re sorry if we’ve given the impression that we don’t care about our users’ privacy or concerns. Rest assured, in the plugin settings, the keys are set to private, as shown in the screenshot below.
Since the keys are private, the elements can’t read them to perform server-side actions. This is the reason we had to place the keys directly in the element. Currently, this is the best solution we could think of at our abilities.
We genuinely wish we could secure the plugins even more effectively, so if you have suggestions on how to achieve this, please feel free to share them. All input is greatly appreciated!
Regarding your last remark, could you please send us a quick DM message about the people you spoke to who felt they received the cold shoulder from us? We just want to double-check our records and address this properly .
Those private key fields are only for the server side actions on the plugin. The client side uploader still has it’s own fields to put the secret key which immediately leaks it client side
I actually brought this up a long time ago and ZQ said it was “fixed” but what happened is the public key field in the plugin tab changed to private but then the new key fields were added on the plugin element, so exact same issue.
We aren’t blaming you but the programmer giving you the wrong information
Line 235 of dynamic.js in your own plugin demo leaks your own AWS API keys, too, just Ctrl+F ‘eu-central-1’ and it’ll take you to every instance of the uploader element that contains an API key.
Don’t need to, @redvivi’s is worth paying a little for
, so avoid where possible. And 
