Firebase storage url, new file keep same access token

Question

Duplicate of: Firebase storage URL keeps changing with new token

When a user uploads a profile pic I store this in firebase storage with the file name as the uid. Lets say the user then goes and makes say 100 posts + 500 comments and then updates their profile image.

Currently I have a trigger which goes and updates the profile image url in all of the post and comment documents. The reason I have to do this is that when the image is changed in storage the access token is changed and this is part of the url so the old url no longer works.

What I want to do is not have the access token change. If I can do this I can avoid the mass updates that will massively increase my firestore writes.

Is there any way to do this? or an alternative?

Edit: Another solution if you don't mind making the file public. Add this storage rule and you won't have to use a token to access the file. This will allow read access to "mydir" globally in any subfolder.

match /{path=**}/mydir/{doc} {
    allow read: if true;
}

Answer 1

There are only two options here:

1. You store the profile image URL only once, probably in the user's profile document, and look it up every time it is needed. In return you only have to write it once.
2. You store the profile image URL for every post, in which case you only have to load the post documents and not the profile URL for each. In return you'll have to write the profile URL in each post document, and update it though.

For smaller networks the former is more common, since you're more likely to see multiple posts from the same user, so you amortizing the cost of the extra lookup over multiple posts.

The bigger the network of users, the more interesting the second approach becomes, as you'll care about read performance and simplicity more than the writes you're focusing on right now.

In the end, there's no singular right answer here though. You'll have to decide for yourself what performance and cost profile you want your app to have.