Going through this blog, I could see that my app would be better off using the Firebase cloud functions for Firebase Firestore rather than directly accessing Firestore using client-side SDK.
I can implement the Firestore READ operation using get(), WRITE operation using set() or update() &
DELETE using delete() methods. All these one-shot operations are fine.
Is possible to implement addSnapshotListener to fetch real-time updates? If yes, how?
While it technically is possible to use addSnapshotListener, there are not a lot of use-cases where this makes sense.
Cloud Functions are short-lived, a maximum of 9 minutes, so not well suited for scenarios where you need to listen to the database for longer times.
Typically, you'll want to instead define a separate Cloud Function that responds to the thing you'd otherwise want to listen to.
Realtime listeners are not compatible with the way Cloud Functions works. Functions can only run for a limited amount of time and are shut down after that timeout expires. Database listeners are indefinite, and will continue listening until they are removed. If you add a listener inside a function, the system will still shut it down after the function timeout expires.
It's unclear to me why you need a listener in a Cloud Functions, but it's almost certainly not the right thing to do, given the way functions work.
Related
I am using Firebase cloud functions for a project, and some of those functions fetch data from a firebase database.
I'd like to speed up some of these queries by leveraging a LRU cache, but it's not clear whether this is possible with Firebase cloud functions.
Does anyone know if the Firebase cloud functions have access to any kind of cache / semi-persistent memory access? Any help others can offer on this question would be hugely helpful!
If you want to share any sort of persistent data between function invocations, you will have to use another product, and code your function to use that. Cloud Functions themselves only have immedaite access to the memory on the server instance that's running a particular invocation, and there could be many server instances all running functions at the same time.
If you're OK with maintaining a small local cache in memory on each instance, that's fine. But you will have problem with this if you allow the cache to get so large that a function can't do its work with more limited memory. You should also expect the cache to get reset whenever a server instances get deallocated, which happens outside of your control.
Since you're working in Google Cloud, consider using a product such as Memorystore to implement your cache.
I am working on a project that, currently, is 100% Firebase. Ideally, given I'm fully Firebase, I'd like to stay with Firebase for a next task which is updating some of the records based on external API calls once per day.
I'm currently using Firebase Functions for triggered events, not using it for API calls, everything that happens in the functions is after a user does something, and doesn't respond back to any clients (only responds back to the database for updates).
Is Firestore Cloud Functions a good place to run something like this that could call an external API and then update as necessary? I saw the scheduled functions that require the Blaze plan, have considered it but not sure if there's another approach that's better built for this task.
Cloud Functions that trigger on Firestore events probably aren't what you're looking for. Firestore triggers only fire when something in your Cloud Firestore database has changed. That means you need something that's writing to some document in the database in order to get the code to run. Which means you need a way to schedule that operation.
No matter what kind of trigger you write, you will need to be on a billing plan in order to make external requests anyway. So even if you somehow managed to put together a solution that uses Firestore triggers, your project would still need to be on a billing plan.
This approach is perfectly okay - in fact, I am using the exact same approach in my project which has 100% Firebase back-end. The overall (Firebase) Cloud Functions gives flexibility in terms of invocation i.e. they can be invoked based on trigger (e.g. storage or database event) or can be called with the HTTP end-point. So, depending on your need you can either use Firestore trigger or database trigger or call an end-point.
Switching to Blaze plan is perfectly fine since otherwise we can't call an external end-point. I switched to Blaze plan just a few months back and didn't pay anything for that as my usage is within the free limit.
This question already has answers here:
Continue execution after sending response (Cloud Functions for Firebase)
(3 answers)
Closed 3 years ago.
I'm currently looking to take in a request (using Express/Firebase Cloud Functions)and do some calculations/make some requests, send a response, but then respond to a user before updating my database or doing some extra calculations.
Use case example: Occasionally, a user will follow another user. This means that I want to update all over my database so that my data is in the right place later on. I don't need my user to wait for me to do this, this is something I can do long after the server knows the user wishes to follow them.
Can I receive the user request, perform a server action, respond to the user, then continue on with my cloud function? I have read inn places that a function terminates on responses, but it's not clear how else you go about this or if it only terminates on specific responses.
The way to explain is not possible to achieve, I mean, after you return from a function the process is done.
However, there are several patterns you can implement, it just matters of playing with triggers, take a look.
You can save a state on a firestore collection and trigger a background function which fetches this state and do whatever you need.
If you don't feel like saving this on collection, you have PubSub available as well.
This should give you a good starting point to investigate what is the best solution for your use case.
Hope this helps!
There are two kinds of cloud Functions for Firebase: the ones that you can call directly (HTTPS Callable functions, HTTPS "simple" functions and scheduled functions) and the one that respond to events generated by some of the Firebase services or Google Cloud features like for example Firestore, Authentication events or Cloud Storage (see https://firebase.google.com/docs/functions for a full list)
Classically, when you want to send a response to a user after he/she initiated a Cloud Function, you would choose an HTTPS Callable functions or an HTTPS "simple" functions. But this is not the only way to do it: you can very well send a feedback to the user with a background triggered Cloud Function, mainly by writing something in Firestore (or the Realtime database) to a location the front-end is listening to.
With this second way, you can very well "respond to the user, then continue on with [the] cloud function". While with a callable Cloud Function when you send back the response to the user the Function is terminated.
So let's describe this method in a bit more details for Firestore:
You trigger the background function, for example by writing to a Firestore document/collection from your front-end
At the same time, from the front-end, you set a listener to a specific document (not necessarily the same document than above). See here for setting a listener.
The Cloud Function starts to do some work and at one moment writes to this specific document in Firestore
In the front-end, the user is informed of the write through the listener
In the background the Cloud Function can continue its other tasks.
The key point is that you have to correctly chain all the asynchronous tasks of the Cloud Function by chaining the promises.
tldr: I need to have Google Cloud Functions on my own backend.
I write application, which uses firebase (especially firestore) as a transport layer between my own backend written on nodejs and client applications.
Sometimes, I need to catch some events from client on backend, but i want to avoid perform http queries directly to my backend (because I need to catch offline status, and other problems). It is better to made some changes in firestore documents, catch that changes on my backend and perform some business logic.
As for now, It can be solved with Cloud Functions, but this solution is not acceptable, because of delay between event and function invocation, and lack of invocation order.
Yet another solution, which is currently used in my project, is to making some changes to firestore document, and adding extra document, called "event" to other collection. On a server side, using firebase-admin sdk, I subscribe to that "events" collection and get realtime updates of it.
This work great, but looks like overcomplicated. Is there any way to subscribe from my backend to get all updates of all documents of firestore? Ideal solution is to subscribe to updates, as it done in Cloud Functions: https://firebase.google.com/docs/functions/firestore-events?authuser=0
The client and server SDKs don't have this capability. Cloud Functions is really your only way to get notified of changes in Firestore that match a wildcard pattern.
When some a series of write operations happens into Firebase Realtime DB when client is off-line,it's stored in the client and added into the db once it get connected.
The behavior of Firebase Functions will depending on, how it is written to the database. Will it just sync two DB's as a single write operation?
Or will it trigger all these write operations?
I just tried this. You could try it yourself and verify the results on your own.
Each offline write to the exact same location in the database triggered a call to an onUpdate trigger at the same location.
However, you should not expect the triggers to be executed in any particular order. There is no guarantee to the order of events delivered to a Cloud Functions trigger, and they may all be executed in parallel to some degree.