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.
Related
does anyone know how to enable the Message Ordering property on a subscription when working with Firebase and NodeJs?
If I navigate to the GCP console and open the queue's subscription detail, I can change the parameter manually but I'd rather have it done when my functions deploy.
This link (https://cloud.google.com/pubsub/docs/ordering#enabling_message_ordering) also talks about a parameter that can be provided when creating a subscription but that doesn't seem to be available the way I usually create/deploy my functions.
GCP Documentation
Own Code
It sounds like you're asking if pubsub functions deployed with the Firebase CLI (and not gcloud) can request ordering. Currently, this is not possible. When you deploy a pubsub function with the Firebase CLI, it will automatically create the pubsub topic for you. However, there is no option to set the ordering setting.
If you would like see this implemented, you should file a feature request on the Firebase CLI GitHub and/or contact Firebase support directly.
Alternatively, you can switch to use gcloud to establish the trigger and create its pubsub topic with your customizations.
You should note that enabling ordering does not necessarily ensure that function invocations will be perfectly serialized with respect to incoming messages. Cloud Functions is designed for incoming events to be handled in parallel as fast as possible by using multiple server instances as needed. There is no guarantee that pubsub messages will be processed fully in order. The ordering only applies to pubsub topic consumer code that runs in a single process. You could try to set the max instances of a function to 1, but that is not a hard guarantee.
If you need fully ordered serialized execution of some code in response to pubsub events, maybe Cloud Functions isn't the product you want to use. Maybe a single App Engine or Compute Engine instance would work better.
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.
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.
I follow some guidelines to have my Vue.js state in sync with Firebase. I have set up references to Firebase and getters, mutations and actions in vue in a separate folder store. It seems to work when I update the states without Firebase connections (local) and it also works when I update Firebase from other components only using the Firebasereference and push - then the sync seems to work. My question is if I should update the state throw "action / mutation" and the mutation will do a push to the state array and in som magic way the Firebase will update which not happens in my case.
So - how to update? From the component using the reference, for example dbOrdersRef.push(order) or with a call to the store with for example this.$store.dispatch('setOrder', order) which don't updates Firebase (but other local variables updates).
I think scheme should be like this:
You should subscribe on firebase updates somehow (I'm not familiar with firebase but I'm sure that there should be some mechanism for that) and when updates come from firebase - you should mutate your store by dispatching some actions, to keep you store in sync with firebase.
Ideally, your app should work with your store only. Store should hide such implementation details as firebase usage. If tomorrow you will switch from firebase to something else, you shouldn't rewrite your components which work with the store. They still will work with the store and with the same actions.
When you update something in your store you need to update firebase as well. I think you can do it right in your actions, it should be fine. In that way, you can be sure that all changes which will appear in your store, will be in firebase. E.g. you call someAction which actually do some firebase manipulation. If you subscribed on firebase changes you won't even do something else in that action, except sending some command for firebase, because your subscription will update your store. Or you can mutate the store immediately (aka optimistic update), then wait for response from firebase, and then decide leave that update or call some mutation to rollback (however here you should be very careful because of subscription on firebase changes).
Or, alternatively, you can write some plugin for your store, which will send updates to firebase only when some change in your store has been done. In that case, updates from your app firstly will appear locally in your store, then your plugin will send them to firebase (maybe such plugin even already exist, idk).
I'm not an expert in firebase, but tried to share some thoughts about how it should work in general. Hope this helps.
Oh, back to your question:
dbOrdersRef.push(order) or with a call to the store with for example this.$store.dispatch('setOrder', order) which don't updates Firebase
I think you shouldn't use firebase in components at all and should use your store instead. So I'd rather advice to use the second option. But you should implement firebase updates by your own, there are no magic updates from store to firebase by default (at least if you aren't using some plugin with that magic).
To avoid rewriting Firebase DB logic in various apps (iOS, Android, Web) we earlier used a service/middle layer to hold this logic. In this way the app never interacts with the DB directly.
However, in the new architecture with Firebase and Google Cloud Functions, would it be wise to route all DB calls through Cloud Functions or should this be done only selectively based on use case?
In almost all the examples I’ve seen so far, the app directly interacts with Firebase DB and the Cloud Functions are meant to only listen to certain events and used selectively. They are not meant to be a middle layer.
This approach would however lead to the need to duplicate DB logic in all apps. Can this duplication of code be avoided?
Yes. By moving certain functionality from your application code into Cloud Functions, you will only have to implement that logic once: in JavaScript. This is great for certain logic that you either don't want on the client (too big, too secret, too slow, etc).
But:
Each client will still need code to access the functionality in Cloud Functions. This can be as simple as a write through the Database SDK, but can also get quite involved.
The functionality will only be available if the user has a network connection. Unlike client-side functionality, it won't work when the user is disconnected/offline.