[Firebase Hosting] Is there a size limit on the firebase.json file?

[Masatake Wasa]

Hello!

Currently I'm using Firebase Hosting for a large (image-heavy) static site. Since deploying to Firebase Hosting is all or nothing, and it's a little cumbersome to deploy everything when I make a small amendment to a single file, I have been uploading large images to Google Cloud Storage, generating public links, and using the firebase.json file to 302 redirect from the custom domain to storage.googleapis.com/[bucket]/ on an image file by image file basis. This is probably not the best solution, but this method preserves the existing URI structure, and also allows consistent URI structure in the future based on the custom domain. As you can imagine, this is making the firebase.json file bigger and bigger, and I'm wondering if there is any limit on the file size.

As mentioned by another poster a while back (https://groups.google.com/forum/#!topic/firebase-talk/Yt9k3cEQZ38/discussion), it would be great to have the option to deploy files selectively (e.g. only new / modified files)!

[Kato Richardson]

Hello Masatake,

A quick search for `google cloud storage file size limit` revealed this doc, which lists the limit as 5TB.

Obviously, what you're doing now isn't going to be scalable. Deploying the site every time an image is added or changed is cumbersome. It seems like the Realtime Database might be a better option; but, I don't really understand why you're using redirects here so I could be missing something obvious.

It may help to talk about the goal here instead of the intended solution (see XY problem).

☼, Kato

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-talk+unsubscribe@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/c11b7a23-1dcd-44fc-aa59-ec011b25e6e9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Kato Richardson |

Developer Programs Eng |

kato...@google.com |

775-235-8398

[Masatake Wasa]

It's good to know that there isn't a specific limit, but the standard limit (as it were) applies.

If it wasn't clear, the main goal is to preserve existing links to image URIs on external sites that are beyond my control by showing the images at their new locations. If I were only concerned with how the site is structured internally, I wouldn't necessarily bother with redirects, and I'd probably use Google Cloud Storage rewriting the image source URIs on the HTML files. There are certain instances where images would 'break' were it not for a 30x redirect. As it's a static site, publicly accessible, my instinct was to use Google Cloud Storage.

A subsidiary goal is to use the same canonical URI structure as part of future-proofing, allowing any future migration easier, instead of being beholden to a URI structure I do not control. If I were to use another hosting service, so long as I am in control of the domain name, I would be able to move the site easily.

Does that make more sense to you?

On Tuesday, 3 January 2017 14:59:16 UTC, Kato Richardson wrote:

Hello Masatake,

A quick search for `google cloud storage file size limit` revealed this doc, which lists the limit as 5TB.

Obviously, what you're doing now isn't going to be scalable. Deploying the site every time an image is added or changed is cumbersome. It seems like the Realtime Database might be a better option; but, I don't really understand why you're using redirects here so I could be missing something obvious.

It may help to talk about the goal here instead of the intended solution (see XY problem).

☼, Kato

On Sat, Dec 31, 2016 at 5:10 AM, Masatake Wasa <masata...@gmail.com> wrote:

Hello!

Currently I'm using Firebase Hosting for a large (image-heavy) static site. Since deploying to Firebase Hosting is all or nothing, and it's a little cumbersome to deploy everything when I make a small amendment to a single file, I have been uploading large images to Google Cloud Storage, generating public links, and using the firebase.json file to 302 redirect from the custom domain to storage.googleapis.com/[bucket]/ on an image file by image file basis. This is probably not the best solution, but this method preserves the existing URI structure, and also allows consistent URI structure in the future based on the custom domain. As you can imagine, this is making the firebase.json file bigger and bigger, and I'm wondering if there is any limit on the file size.

As mentioned by another poster a while back (https://groups.google.com/forum/#!topic/firebase-talk/Yt9k3cEQZ38/discussion), it would be great to have the option to deploy files selectively (e.g. only new / modified files)!

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.

To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/c11b7a23-1dcd-44fc-aa59-ec011b25e6e9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kato Richardson]

Hi Masatake,

If the goal is to be able to move the site later without breaking the URLs, I'm pretty sure you could conjure a URL rewrite scheme using that which would redirect image requests directly to Storage URLs. You can read about redirects in Firebase Hosting here.

☼, Kato