Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
It seems like there are two choices with firebase for sending and receiving "moves" between players in a 'serverless' two player game. I could either use FCM and firebase cloud functions to send and send receive messages between the players,
i.e. player 1 calls a cloud function to communicate a "move" and the function calls FCM to send a message to the opponent a "move" was initiated by the other player.
or I could have both players observe the "game state" document in firestore, so that each player calls a cloud function to update the game state, and the other player is notified about the opponents move when the observer of the "game state" document registers a change in the document.
Neither of these approaches seems ideal fo the purpose, using the game state document seems a little easier perhaps could be because I understand firestore better than FCM.
just wondering what the "best practice" is for handling this kind of bilateral signalling between two users. (I guess the same basic question would arise in trying to build a "chat function" between two users on an web app. (the app itself is built in Angular) and just uses local code, a few cloud functions and a firestore, but no dedicated server.
If you want to use Firebase for this I would recommend to use the realtimedatabase. The FCM can have some lag when delivering and it depends on multiple stuff you can't control like battery status, etc. (the OS decidec more when to get new messages). By using the realtime database you are in control when it happens. I would not use Firestore because you are charged there for reads and writes and you will probably have a lot of them.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
In my application I do a ranking of the points of a user. However, I do the calculation of my ranking just every 24 hours. My problem is that I do not know where I should put the code of the calculation without disturbing the user.
Is it not possible to have a code in the "background" who will be called every 24h? Because at the moment, the code for the calculation is called when the first user uses my app after 24h, but then the user has to wait some minutes until the calculation is over. My data of every user is saved with Firebase.
Thanks in advance!
Edit April 22, 2019:
Recently, Google Cloud released Cloud Scheduler, which allows you to schedule HTTP requests or Cloud Pub/Sub messages to functions that you deploy.
This new service works also very well with Firebase and for that I recommend you read an excellent article writen by Doug Stevenson on the Firebase blog named Scheduling Cloud Functions for Firebase (cron).
Is it not possible to have a code in the "background" who will be called every 24h?
Yes, it is possible. In this case, you should write a function in Cloud Functions for Firebase and call it whenever you needed. If you want to be triggred every 24 hours, use the follwing service:
https://cron-job.org/en/
This means that you can do that particular calculation even if the user has the app closed. For a code example, please see Frank van Puffelen's answer from the following post:
Cloud Functions for Firebase trigger on time?
For your case I'd recommend using default Android tools for scheduling jobs. You can try using a new WorkManager or just a JobScheduler. Also you can try digging into this article to get more information.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
It's considered good practice to remove listeners from Firebase databases (whether that be Cloud Firestore or Realtime Database) when the listening components are unmounted.
In a lot of applications, mine included (React Native app), this might not happen very often.
For example, when my user is authenticated (signed in), they are subscribed to a number of listeners on both RTDB and CFS. Things like notifications and messages and other "realtime" updates i want them to see app-wide - think notification "badges" for example or "unread messages".
Developers of Native applications will know that apps can remain "backgrounded" for long periods of time. And with auth refreshing, users will rarely log out of my application. This means that those components are never (or rarely) unmounted and thus, remain subscribed to updates - i think.
Should i be adding logic that removes those subscribers to realtime data when a user backgrounds the application, only to re-instate them when they foreground again?
What you're asking is primarily a matter of opinion, which is off-topic for Stack Overflow. That said, you should probably take some time to understand the ramifications of leaving listeners added indefinitely.
A listener that's not removed when the user isn't looking at your app still incurs the cost of downloading updates to the documents it's listening to. Whether or not that's acceptable is entirely up to you.
The host OS will likely throttle the network access of app that can't be seen by the user after some time. This is for the benefit of the user, so poorly implemented apps don't consume excess network and battery. You can't depend on these listeners to work properly when this happens. If you want listeners to stay active while the app isn't visible, you will need to tell the host OS what you want using whatever APIs it provides. Even then, you don't have any guarantees, as the OS may simply kill an invisible app in order to reclaims resources.
You will have to decide for yourself when it makes sense add and remove listeners, after you understand the behavior apps on the given OS.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
So I'm building a web shop using Firestore and Firebase for the first time, I'm also new to NoSQL. I have the following architectural problem: When a customer places an order the client sends the products ordered to Firestore directly which stores the order in a collection raw_orders. My idea then was to have a Cloud Function trigger on the document create which processes it and builds an invoice and such. However I read that this function invocation may be delayed for 10 seconds, I would like to have a synchronous solution instead.
Instead I had the idea to create a HTTP Cloud Function where the customer can POST the order to, the HTTP function then processes the order and pushes it to Firestore, the function then returns the orderID or something to the customer. This approach feels much more safe since the user won't have to talk to the database directly. Also it solves the issues that the a function triggered by a Firestore create might be delayed.
However I'm new to Firebase and I'm not sure if this is architecturally the preferred way. The method I propose seems to be more in line with regular old REST APIs.
What do you think?
Thanks!
It sounds like you definitely have some server-side code and database operations that you can't trust the clients to do. (Keep in mind that firestore security rules are your only protection -- anyone can run whatever code they want within those rules, not just the code you provide).
Cloud functions give you exactly this -- and since you both want the operation to be synchronous (from the view of your client) and presumably have some way for the client to react to errors in the process, a cloud function would make a lot of sense for you to use.
Using cloud functions in this way is very common in Firebase apps, even if it isn't pure REST.
Moreover, if you are using Firebase more generally in your client, it might be more natural to use a callable cloud function rather than an http function, as this will handle the marshaling of the parameters in a much more native way than a raw HTTP request might. However, it isn't clear in your case since it sounds like you're using the REST API today.
Keep in mind that there are additional costs (or specific quotas, depending on your pricing plan) for running cloud functions. The pricing is based on invocations, as well as CPU and RAM usage of your functions.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
We are building a chat app, one-to-one chatting is the main purpose of the app so for now, messaging speed is our first priority. We need a backend solution and we were initially planning to use Firebase realtime database. But then Firestore came to existence, from there onwards we saw a lot of recommendations for Firestore over Realtime database from the Firebase team.
We have used both Realtime Database and Firestore so we are pretty aware of the capabilities and querying powers of both. For our use case in terms of features, any of them are fine. But as I told before our main concern is messaging speed. So which one is more realtime?
So which one is more real-time?
I don't think one is more real-time than another.
But then Firestore came to existence, from there onwards we saw a lot of recommendations for Firestore
That's right, Firestore has some new features over Firebase Realtime Database, that's why is named "the new flagship". The query performance depends on the number of items you request and not on the number of items you request them from. So every time you think to get data, get it in such proportion to maintain the speed that you were talking about. As the guys from the Firebase team say, Cloud Firestore has a performance guarantee, there are no slow queries, so the time it takes your app to retrieve data depends on only on the amount of data you retrieve and not on the amount of data you have on Firebase servers. In other words, it doesn't matter if you have one thousand, one million, or even one billion documents within a single collection, retrieving for instance 15 of them, will always take the same amount of time.
This performance comes with some constraints and for that, I recommend you take a look at all sections within the official document regarding getting data in Cloud Firestore. That's the reason why Firestore uses those constraints, is due to the fact that is mandatory to maintain this performance guarantee. But from my experience, there is no "SQL" query that cannot be translated in a way or another in Cloud Firestore.
So remember, it really does not matter if you request a single document out of a 10 or one item out of 100.000 or 100.000.000.000, the result will come in the exact amount of time. Here I took as an example one document. So regarding speed, requesting one document out of 100 million will be faster than requesting 10 items out of the same 100 million. So the number of documents in the collection has no effect on the query performance.
This is about Cloud Firestore but there two main resources that I recommend you read before using one or another:
https://firebase.google.com/docs/database/rtdb-vs-firestore
https://firebase.googleblog.com/2017/10/cloud-firestore-for-rtdb-developers.html
So check the price models for each one of them. But IMHO, both Cloud Firestore and Firebase Realtime database work extremely fine together.
In my opinion calculation is simple. Realtime database 10 000 M chat messages data transfer = $490. Firestore 5 000 M reads = $3000 and 5 000 M writes $9000 = $12000. So the cheapest way is to use realtime database and because of $5/GB stored you need each few weeks/months rewrite messages to firestore. For chat app like discord where you have conversation shared with many users the best way is to set a server witch different database like Cassandra.
I'm working on a personal project to get familiar with a number of Google/GCP projects and services (Flutter/Dart, Firestore, Cloud Functions, PubSub, Dataflow/BEAM).
For context on the "toy" problem I'm solving, imagine a mobile/cloud-based Ouija board:
a board printed with letters, numbers, and other signs, to which a planchette or movable indicator points, supposedly in answer to questions from people at a seance.
Mobile users can create a board, share the link with friends, and collectively ask the board simple questions (e.g., "Does Suzie have a crush on Johnny?"). Players on the same board gesture in the UI to coax the Oiuja "indicator" to the answer in a "crowd-sourced" way. apache-beam gives me the tools to group/window/process the streams of user data before writing to firestore.
The current technical question I'm wrestling with is: What is a "low code" + lowest latency pattern to use to send the messages from the mobile app, into a BEAM pipeline for processing (which ultimately changes Document properties on a Firestore database).
I have 3 Options in mind depicted in the following diagram:
OPTION 1: Mobile app uses Cloud Functions, which accept the payload and publish to a PubSub topic. This was my initial idea, but as I started to look at it closer, I questioned whether the Cloud Function is even necessary. Enter option 2
OPTION 2: Remove the Cloud Function and have the UI directly publish to the PubSub topic. As I looked into the docs, it seemed like PubSub was meant to be harnessed server-side, so maybe I still need the Cloud Function? Or maybe I lean into Firebase more... Enter option 3
OPTION 3: Have the client only post messages through Firebase, and use Cloud Functions to pick these messages up and push into PubSub and/or BEAM. Advantage is I can benefit from the "offline" handling Firestore client gives me, but this feels like the worst-case for latency.
Am I missing something? Is this question too much of an "opinion" question?
Thanks in advance.
Here's a link to the Google Diagram
EDITS
So after thinking things through more, Authentication/Authorization is another consideration:
OPTION 2 - I would have to ask Google Account users to give permission to use "Pub/Sub", which feels like a bad UX. Users don't know what "Pub/Sub" is!! Option 1 would allow me to put in a service account from Cloud Function to Pub/Sub... and also use other Authentication providers besides Google.
OPTION 1 - I still need some kind of security at the Cloud Function layer to prevent bad actors.