I am planning to use firebase storage as storage bucket for images for my app.
Shall I use client side firebase SDK to upload images directly to firebase or, shall I send image to my server first and use firebase Admin-sdk and let the server upload image to firebase? Also I have other data along with image which client will send, that server needs to handle.
EDIT: I was confused about one thing, if I use firebase admin-sdk, first my image need to upload to the server and then server will send it to firebase storage, won't it double the upload time?
Both are valid options, and neither is pertinently better than the other.
I typically prefer using the Firebase SDK to upload to Cloud Storage, since it saves me from having to come up with my own client-side code and handling things like network detection, retries, etc. I then often write metadata about the file to the Firebase database (either the Realtime Database, or Cloud Firestore) and use that to trigger Cloud Functions to do any backend processing that is needed on the image.
But it's equally valid to write your own server-side endpoint that does the processing of the image, and post to that from within your app.
Related
I'm trying to implement a system that allows react-native clients to upload files to a specific folder in Cloud Storage and allows clients to download from them. I can't do this directly from the client because I first need to query Firestore to validate that the user is 'friends' with the owner of the folder which will allow for read/write permissions.
I decided to use Cloud Functions as a middle layer to encapsulate this business logic and I expected to also be able to use it as a middle layer to upload the files. However, I feel like I may be misunderstanding how to best use these services together to solve this problem.
Current Plan:
Client uploads file to Cloud Function (assuming they are permitted after Cloud Function queries Firestore and validates)
Cloud Function uploads file to Cloud Storage
Client can then request file from Cloud Function, which validates permissions using Firestore and downloads file from CloudStorage
Cloud Function sends file to client
Questions:
Can/Should I use Cloud Functions in this way as a middle layer to upload files after validating permissions store in Firestore?
Is there an alternative solution using firebase that would mitigate the 10MB download limit with Cloud Functions but still allow me to authenticate uploads/downloads to and from Cloud Storage using my custom business logic on relationships in Firestore?
Any help or guidance here is appreciated! I'm very new to firebase, cloud architecture, and architecture in general.
This is definitely a valid and technically feasible approach. Whether you should do it, only you can determine of course.
An alternative is to use Firebase Storage's security rules to enforce the access control on the files. But you won't be able to read anything from Firestore in those rules, so you'll have to ensure everything needed to grant/deny access is in the path of the requested file, in the file's metadata, and/or in the user's token.
Even if you implement the download of files in Cloud Functions, you can still perform uploads through Firebase. You could in that case for example have the user write to a temporary location, which then triggers a Cloud Function that can do whatever additional checks you want on the file.
I am sending FCM notifications with image links from my backend written in Go. The images are stored in Firebase-storage. I need to resolve the bucket path into a Url that I can use to create the FCM notification.
There seems to be a Javascript function (getDownloadUrl) to do this. How do I get the download URL in Go?
getDownloadUrl is a feature of Firebase client SDKs that read and write Cloud Storage. There is no direct equivalent for backend and server SDKs.
Cloud Storage has a similar concept called signed URLs that you can use to create URLs that directly access content in Cloud Storage. You can use the REST APIs directly as shown in the documentation, or if you're using the Go SDK, you can simply call SignedURL directly to get a URL that meets your specifications.
let's say I have an image /path/image1.png in the firebase storage. I want to copy this image and create a new image with a different name but the same content as /path/image2.png. I'm using AngularFire. How will I achieve this? Please help
Firebase Storage (nowadays called Cloud Storage for Firebase) is a set of client-side SDKs that allow you to access Cloud Storage from within your application.
There is no Firebase API to create a copy of a file in Cloud Storage. It's a valid use-case though, so I'd recommend you file a feature request for it.
In the meantime, the two options I can think of are:
Read the data to the client, and write it to the new location. This is definitely wasting bandwidth for the client, so I'd only consider it if your files are quite small, and your clients have a decent connection.
Use one of the (non-Firebase) server-side SDKs for Cloud Storage to create a copy of the file. For example, you could wrap this Node.js code in a callable Cloud Function and then call that from your application code.
await storage
.bucket(srcBucketName)
.file(srcFilename)
.copy(storage.bucket(destBucketName).file(destFilename));
So I was watching multiple tutorials about how to present data on an actual webpage using Cloud Firestore. The thing is, everyone was using an actual index.html file sitting in Public folder(instead of serving html content within node.js code) and tags which would mean that their program would use client-side JavaScript instead of node.js. But why? for what reason? According to Firebase tutorials and documentation, having an ACTUAL index.html sitting in Public folder is only for making static webpages, thus, if I'm making a complicated and dynamic webpage(which will also present Firestore data within the webpage), I should be using node.js right?
The Firebase SDKs for Cloud Firestore perform local persistence (caching) of doucments fetched from the database. The persistence is enabled by default for Android and iOS, and you can programmatically enable it for web (currently experimental). This local caching allows the client to avoid requesting documents from the server, which is obviously faster and cheaper than going through some API endpoint to request the data each time it's needed.
There is also the fact that the SDKs will push you realtime updates of data as it changes on the server, as long as you have a listener attached to some document or query of interest. You won't be able to duplicate this if you write it all in Cloud Functions. You will spend a tremendous amount of time trying to duplicate and scale this behavior using socket.io or something similar on a backend you control.
You could write the entire app to be driven through API endpoints that you create. There's nothing wrong with that, if it meets your needs. But you'll write more code, you'll sacrifice realtime updates, and it will likely be slower and more expensive than allowing the client SDKs to optimize for you.
I was thinking of import my server Java code to firebase, basically replace my Dynamic web app with Jeresy and mongoDB to Firebase using hosting and functions .
I have implemented the sendWelcomeEmail and sendByeEmail with events user.created and user.deleted.
But now I want to do something more complicated.
Based on post request that comes from the mobile I want to extract the JSON data and then update the DataBase.
So I created js file with plenty of functions but now I am not sure it will actually work.
Is that the best way to implement this workflow.
The workflow goes like this.
Image is taken on the android device => extract information from image ==> upload the Json Data to the server (Firebase Hosting) => functions is been execute is response to POST request ==> extarct the data ==> save it to the Firebase Database.
Let me know if this sound ok, or I need to implent another workflow.
Thanks
Eran
The whole idea of Firebase is that your app talks directly to backend services (such as the database, or cloud storage), and you only write server-side code (with cloud functions) for functionality that Firebase doesn't provide a client-side API for.
Why don't you simply let the Android client write directly to the Firebase Database?