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).
Related
I am using Firestore NoSQL for iOS application. While debugging, I occasionally executed setData instead of updateData, what led to lost of all the user data (one user).
Is there a way to reverse back the changes?
How to do Versioning for Firestore, for similar cases, so there's a way to cancel/ backup. I don't quite know, but I've read that it supposed to be Versioning.
There is no option to undo changes in Firestore. I'd recommend creating a new database (project) for testing purposes so you don't accidentally write on the main database. For now if it's just a single user then I'd recommend manually add that back.
Unlike realtime database, you can only have one Firestore instance per project at the moment so you may have to create a new project but I think that'll be safe to prevent such accidental writes :)
"You can use the Cloud Firestore managed export and import service to recover from accidental deletion of data and to export data for offline processing."
That's what I've found for now: https://firebase.google.com/docs/firestore/manage-data/export-import
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.
If I have a Firestore database that I want to constantly be updating (and listeners in my code to constantly be responding to backend updates), should the code that's responsible for updating the database belong in the android app that will be available for download to other people? Or is it supposed to be somewhere else?
For example, the code for creating a document with user info within the collection "Users" belongs in every instance of the app that I publish, because I want every user using my app to be able to write their login info to the Firestore database after they register through Firebase Auth.
But if I have a different collection of data that I want to be available to all users using my app, and I want to be updating that data constantly, should I be updating it with code that goes in with my production level app, or should that be happening somewhere else? And if it should be happening somewhere else, where should that be/how should that be done?
I'd appreciate any help with this!
Never mind, I found the answer to my own question. Firebase provides users with Cloud Functions, which can run on the server-side to respond to new data events.
You might also be interested in Realtime Database, it will mean you don't have to write any of these listeners to the data and it does it all automatically. Check it out here;
https://firebase.google.com/docs/database/rtdb-vs-firestore
I have an app that displays a list of items. Here is what I am doing.
When the app first loads I am making an HTTP request to get the list from the firebase database.
once the list is received the list is stored locally on localStorage for future use.
On future app loads, the list is loaded from localStorage to prevent unnecessary http calls
I am doing the above programmatically, i.e, saving data to localStorage and check for new data and getting it etc.
Does firebase provide any other way to the same?
There is no built-in support for cross page-reload persistence in the JavaScript SDK for the Firebase Realtime Database. Somebody is working on such functionality in the open-source repository, but no release was made with it yet.
If you need this functionality, I highly recommend looking into using Cloud Firestore. In addition to many other benefits, it supports cross page-reload persistence.
Currently the open sourced cloud function provided by Firebase/Stripe uses onwrite to Firebase database to trigger the charge to Stripe:
https://github.com/firebase/functions-samples/tree/master/stripe
It seems that it would be more direct and faster to just call Stripe using https trigger instead of writing to Firebase local database which syncs/writes to Firebase server database, which then triggers the cloud function call to Stripe.
Will there be any problems using Https call to trigger Stripe call? What advantages are there for using onwrite trigger instead of https?
Beginner to beginner, this is my understanding:
Let's say you have an app where a you need to
(1) sign users up for a subscription using Stripe, and then
(2) when users use the app, check to make sure their subscription is still valid.
For (1),
you'd only do this once(ish) per user, and you need to tell Stripe "make a new subscription for this user," so it makes sense to use an https.onRequest or https.onCall function.
For (2),
you'd be checking to see whether the user is subscribed many times, and you're not telling Stripe something, you're asking it about stored information: "is this user's subscription still valid?"
If you're asking about stored information, it's a lot faster to check your own database rather than to wait for a response from Stripe. You just need to make sure the information in your database (e.g. Firestore) is up to date with Stripe.
So what you can do is create a Stripe webhook that will trigger an https.onRequest function whenever there is a change to a user's subscription status. Then, your function writes the change to your database.
So, rather than ask Stripe over and over, "is this user subscribed," and wait for a slow response, you just check your own database, knowing that it's kept up to date by the Stripe webhook.