Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add refFromUrl equivalent from Firebase Web SDK #962

Closed
willbattel opened this issue Dec 23, 2019 · 5 comments
Closed

Add refFromUrl equivalent from Firebase Web SDK #962

willbattel opened this issue Dec 23, 2019 · 5 comments
Assignees
Labels
api: storage Issues related to the googleapis/nodejs-storage API. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.

Comments

@willbattel
Copy link

Is your feature request related to a problem? Please describe.
We're storing Cloud Storage URIs in Cloud Bigtable, and we want to be able to easily generate File references using those URIs in Cloud Functions. These URIs come from many different buckets, and we do not wish to keep these bucket objects in memory outside of the function scope.

Describe the solution you'd like
The Firebase Web SDK has exactly the method we wish for in the GCS Node SDK: refFromUrl. https://firebase.google.com/docs/reference/js/firebase.storage.Storage.html#reffromurl

Describe alternatives you've considered
It is possible to generate a File object reference by parsing the string, as suggested on SO. However, while this does work, I hardly consider this to be an elegant solution. I was sure there would be a way to generate a File reference from a GCS URI with one line of code. I understand that this library is entirely different than the Firebase Web SDK, serving different purposes, in different contexts, and that their only similarity is their relation to the underlying Google product. Despite this, I don't see why this library can't support features like refFromUrl that are useful in both contexts.

Additional context
This is what I would like to be able to do

const objectUrl = 'gs://some-bucket/path/to/object.ext'
const file = storage.refFromUrl(objectUrl)
const signedUrl = await file.getSignedUrl({action: 'read', expires: '03-17-2025'})
@yoshi-automation yoshi-automation added the triage me I really want to be triaged. label Dec 23, 2019
@bcoe bcoe added the type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design. label Dec 24, 2019
@yoshi-automation yoshi-automation removed the triage me I really want to be triaged. label Dec 24, 2019
@stephenplusplus
Copy link
Contributor

Thank you for the detailed request! Would you be interested in sending a PR to add the new method? I would lean towards a name like storage.fileFromUrl() so the return type is more clear.

@willbattel
Copy link
Author

@stephenplusplus sure. I'll see about putting a PR together.

@frankyn
Copy link
Member

frankyn commented Jan 15, 2020

Adding the following context from Python.
Python added helpers for referencing buckets and objects with gs://..., to help users get a reference easier.

PR: googleapis/google-cloud-python#9143

I'd agree with the general storage.fileFromURI().

Thanks @willbattel for your help!

@google-cloud-label-sync google-cloud-label-sync bot added the api: storage Issues related to the googleapis/nodejs-storage API. label Jan 29, 2020
@stephenplusplus
Copy link
Contributor

At this point, I don't believe this change is necessary, since users with only a gs:// URL still have ways of creating a File object. I believe since we haven't seen any other feedback wishing for this feature, we can close and revisit another time, if necessary.

@willbattel
Copy link
Author

No worries about closing it, though I may still submit a PR in the future if I get around to it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api: storage Issues related to the googleapis/nodejs-storage API. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.
Projects
None yet
Development

No branches or pull requests

5 participants