What Firebase Storage reference should be saved to RTDB/Firestore?

user_1130342 0
Viewed 207

I'm trying to determine the best way to reference a Firebase Storage (Google Cloud Storage) file in a direct-read database like Realtime Database or Cloud Firestore. Since a read operation to this database does not benefit from a backend that can issue tokens and cache image URLs, it is not clear to me what the most performant way is to store these references.

I have come up with a few options and none of them are a clear winner.

  1. Store a path like /images/foo.jpg to the database, and use Storage Client SDK to generate a tokenized path with storage.bucket().getDownloadURL("/images/foo.jpg").

    Pros: Secure & simple.

    Cons: Network call for every single image you want to display hurts performance considerably.

  2. Store a tokenized path like https://firebasestorage.googleapis.com/v0/b/storage-bucket-823743.appspot.com/o/images%2Ffoo.jpg?alt=media&token=c6da1e33-f3ff-41e2-a6f0-bdb475a2f6d9 with a super long TTL.

    Pros: No extra fetch on the client.

    Cons: long string stored in expensive RTDB. What if that token is revoked by mistake? The database is now broken.

  3. Store a path like /images/foo.jpg to the Database and use public storage rules. Reconstruct into a custom static URL like https://firebasestorage.googleapis.com/v0/b/storage-bucket-823743.appspot.com/o/images%2Ffoo.jpg?alt=media

    Pros: Tiny database use, no extra client fetch, explicit public access, no token to lose.

    Cons: URL encoding is super flaky, Storage could change their URL format and we'd be out of luck.

So, those are the options I've come up with, and there may be more. Any suggestions for how to solve this issue? The issue is unique because the Firebase databases don't have the benefit of a custom server to handle a token/caching layer to resolve this problem.

firebase-storage firebase
1 Answers

There is no single "best way" to store these paths. It all depends on your use-case, your preferences, and the context in which you're implementing it.

I typically use :

  1. If I need access to the files to be secured, I store the image path (like in your #1), and then use the Firebase SDK to access the file.
  2. If I don't need access to the files to be secured, I store the image path and the download URL. This way I can find the image easily based on the path, and use the download URL in non-secured clients.

The con's you mention for these are simply not affecting me. I'd recommend you take a similar approach, and report back when the problem actually occurs.

user_2091030
Related