[New Feature] [Beta] Large file uploads

Announcements
1

Hello everyone,

We just launched the public beta of a new feature: Large file uploads. This means that File Upload elements will now accept files of up to 5 GB for upload, rather than the old limit of 50 MB. This is a pretty large behind-the-scenes change, so thanks to all of our closed alpha users for helping us test the feature.

You’ll have noticed that this is a new version of Bubble that you will have to upgrade to in the “Settings” tab of the editor, under “Versions”. The reason this is a potentially breaking change is that we changed how file requests are served: rather than proxying them through our server, we issue a 302 redirect to a pre-signed URL on AWS. For 99% of users, this should not be a problem; however, if you were not properly handling redirects in some code accessing your uploaded files, you should consider checking that before upgrading.

Other Features:

  • There is a “Max file size” property on the File Uploader element. This will be verified server-side on upload to make sure users are only uploading what you allow them to. One use case is to calculate it based on the current user’s plan for instance.
  • File Uploader elements can be disabled using conditional formatting, and this will also be verified server-side, so you can control who can upload that way.
  • There is a new state on File Uploader elements, “upload percentage”, which will be a number from 0-100 representing the percentage of the file that has been uploaded. Since large files can take a while to upload, this number can be used to create custom progress indicators.
49 Likes
3

For files (including PDFs / Images) that were uploaded in the past (i.e. as group backgrounds or using the document plugin), will I need to take any action before transitioning?

4

Nope! You should only need to take action if you had some special code which was accessing your files, but not handling redirects correctly (which most libraries do automatically).

5

Can we receive a more specific information on this?
What would a special code actually be?

I’ve dealt with presigned URLs when building into a plugin an AWS client to grab files behind authentication, so I know that simply accessing the URL will give me the image and the auth work happens in the server to generate that URL, but I’m not understanding how could that output an error to us now.

In time: Great update! Now I can use all of my app’s storage with two files :joy:

Edit: Would a simple img.src: url be affected? I don’t think so, but I rather ask, trying to dimension the changes here.

1 Like
6

Most ways of requesting files (such as <image src=""> or the requests library for nodejs) will automatically handle a 302 redirect to the presigned URL, so 99% of code will be unaffected. It’s only if you wrote / were using specialized code which relied on the file being proxied through our server and was not setup to handle redirects that you would have to change. One example would be if you used this library: https://github.com/request/request and explicitly set followRedirects to false.

In general, it’s abnormal to ignore redirects when issuing GET requests, but some apps may do that, so we err’d on the side of caution and made this a breaking change to give them a chance to update their code.

1 Like
7

Ah, so you meant code that ignores redirects. Got it.
indeed most libraries do follow redirects.

Thank you for the clarification!

3 Likes
8

Great news . Will plugins gain access to the larger limit? I’m guessing that encoding to base64 and calling context.uploadContent() isn’t in the cards for this based on what I’m reading. If so is there any documentation for it?

9

thanks for the update @cal
and so the limit of file storage is same as indicated on the pricing page? It’s 10 GB? and then it’s $10/month for every additional 10 GB ?

10

We’re planning to expand this upload path to more things in the future (like plugins or the multi file uploader), but for now we wanted to just roll it out with the basic File Uploader element because of how large of an infrastructure change it is behind the scenes.

11

Should be the same. We haven’t updated the pricing.

12

This doesn’t change anything about CSV upload limits, correct? @cal

3 Likes
13

Finally

14

When you do, please expose a progress (% complete) hook for plug-ins as well. :slightly_smiling_face: (I’m eager to take advantage of that for a custom uploader that I wrote, which uses the existing context.uploadContent() function.)

15

@cal
I have a strange issue. Tested with 3 files, one uploaded under v5 and two uploaded under v6.

With axios (nodejs) set to maxRedirects: 0 (unlimited) i get a 302 for the v5, a 200 for one v6 and 302 for the other v6.

The code is pretty basic and have worked perfectly under v5.

const axios = require('axios'); 

let token = 'mytoken'
let fileUrl = 'https://my-app.domaon.com/version-test/fileupload/f12345x54321/file.docx'

async function getFile(){

    const options = {
        responseType: "stream",
        headers: { Authorization: `Bearer ${token}` },
        maxRedirects: 0
    }

    const res = await axios.get(fileUrl, options)
    return res.status
}

getFile().then(console.log)
16

@simon7
We issue redirects based on what version your app is at time of request, not what version it is when you uploaded them. So, if you tested the one uploaded under v5 after upgrading to v6, we will redirect that request.

Also, I think the axios maxRedirects of 0 is actually no redirects, not unlimited (but may sometimes follow redirects anyways: see here https://github.com/axios/axios/issues/1227).

If the issue persists / prevents you from being able to upgrade, please submit a bug report or DM me some more information so I can fix the issue! Also, if the v5 behavior is different from what it was before, that is also bad, so please let me know.

17

Great! All we need now is the option to specify our own s3 buckets in our own AWS regions so we can upload more than 2 x 5gb files before blowing our monthly plans and manage our own app storage and files.

12 Likes
18

Hi @cal ,
Did some more tests. I probably mixed up the not-working v5 and the working v6 file, so the v5 works as expected but the v6 dont. I did of course try other values than 0 in maxredirects :wink: Those gave a 400. Also tried with node-fetch (incl. redirect: follow, follow: 20 as options).

I will send a bugreport in a bit. I see that I can downgrade for a week, should a revert now or is it better to wait so you can do some testing?

19

Hello @cal.

Before upgrading to v6, when I assigned the current anonymous user to a field, the field was empty (user_field is empty was “yes”).

Now the field actually has the temporary user (so now, user_field is empty is “no”).

Is this new behaviour related to v6?

Thanks.

20

Thanks for the bug report. If it’s breaking functionality for your app (and your app is live), definitely downgrade for now and wait (you can upgrade/downgrade as much as you want without breaking your application). I will be able to do testing no matter what version your app is on.

1 Like