Suppose I have a firebase realtime database with the nodes
myRealtimeDatabase/members
In members I have about 1,000 records
If I would like to filter this data say I do a cloud function that queries the node /members I do my filtering and then return the data I'd like.
Does firebase still considering this cost the same as if I was to query /members from a client? Or is there a reduced cost because it was done "on the server"?
There is no discount for in-network read operations on the Firebase Realtime Database. If there was (or if that ever changes), it'd be listed explicitly on the Firebase pricing page.
Related
As of right now I am using Firebase Realtime Database to include chat functionality as part of an app I'm working on. The only issue I've seemingly run into is figuring out how to include a user's data (profile, username, birthday, etc.) so that if a user clicks on a chat, they can then seamlessly go to a user's profile page without needing to fetch more data from the backend. Here's the current structure I'm using in Firebase Realtime Database for this:
$chats
$chatId
id
users
0: some user id
1: some user id
lastMessage
$userChats
$userId
$chatId: true
$users
$userId
user info here
In my case what I would like to know is if it makes more sense to duplicate all the user data for each user into each chat within the users array or if I should just use the referencing userId and pull that data after in a separate request?
Considering I store my users primarily in a separate PostgreSQL database I wonder if I could do a separate query to that database and not even worry about storing the users in the realtime database as well (considering I have to include aggregate info for each user like counters).
If you are always going to be fetching user data alongside a chat, then you should store them together. No need to make more than one call unnecessarily.
However, if you will ever fetch user data and/or conversations separately, I would recommend storing the user data separately and not within the conversation.
Also, if you really want an "immediate" feel (beyond the already "realtime" database performance), you could also fetch the user data in the background as soon as a particular chat is opened. That way, if the user taps to view a profile, it'll have already been fetched and will give that "instantaneous" experience you are looking for.
Plus, you have to remember that Realtime Database charges on the amount of data being transferred, no matter how many calls it takes (as opposed to Firestore which charges on the number of queries), so storing it separately does not increase billing at all compared to one query, and actually saves money in the cases where you don't need both data sets.
Using the Realtime Database it says here that if you want to scale beyond 200,000 simultaneous connections that you can create/shard another database. It also says:
Each query only runs against a single database instance. Realtime
Database doesn't support queries across database instances.
No sharing or duplication of data across database instances (or
minimal sharing or duplication).
Each app instance only connects to one database at any given moment.
Let's say in first database I have a Posts ref, a Users ref, and a Search Posts ref with 100K user objects, 200K post objects, and 200K search objects. I now decide to create/shard another database with the same exact refs.
When the next x amount of users signs up, if their User, Post, and Search Posts refs are in the new shard database, does that mean that they won't be able to access users or search those user's posts from the first database? Also vice versa the users from the first database won't be able to have access to users or their posts in the second database?
The point of sharding is to load balance your connections and is not related to quantity of data.
The RTDB makes no decisions about where data is stored, you do. One server would contain users, another would contain posts.
You would run user queries against the server with users and posts queries against the serve with posts.
All you're doing is pointing your app toward the server you want to query before running the query.
In other words, there would be no reason to add users to server 1 and then add more users to server 2 as the quantity of data doesn't matter.
I am writing an application that will help users connect to each other based on a number of attributes (i.e. location, interests, etc). I am using firebase firestore to store all of my user data, which has fields like name, hometown, interests, classes, and connections, which is a list of UUID of the users they are connected to.
When I suggest other users for a user to connect with, I want to do so by the number of their mutual connections, however this is not explicitly a field in the database, since I would have to calculate and maintain that for every user in relation to every other user. Is there a way I can use firestore to query or order by a calculated property rather than a field in the database, or another way to store the mutual connections?
I know in theory I could pull all the users from the database and then locally calculate the number of mutual connections and sort the array, but that sounds horribly inefficient.
I have searched for existing solutions such as how facebook or linkedin would suggest friends or people you might know, but I can't find any concrete answers on how they did this, but those companies are not using firestore either. I am hoping someone has had this problem in the past and can help me out.
There is no way to perform a calculation on the data in a Firestore query. If you want to order or filter in a calculated value, you'll have to store that value in the database.
Typically you can either do this:
As you write the data from the client, you also update the calculated values.
In a Cloud Function that triggers when you write the data, and that then updates the calculated values.
In a Cloud Function that runs periodically, and that then updates the calculated values for all modified data.
A Sql Server DB in Azure seems inefficient and expensive if the chat messages blow up my db with lots of data when users chat with each other.
Is there a better Azure solution where I can still save data associated with the message (ex. from id, to id, timestamp, etc).
Being unfamiliar with Document DB and Azure Tables, what's the difference and would one of these be a good solution? Or is there a better solution? Maybe Sql Azure Federations?
Currently I use a blob for storing images, but that doesn't seem like a good solution for chat messages.
Azure Tables are nice and cheap. It'll allow you to search by partition and ID within partition - everything else is not indexed and can't be searched through easily. If you only need to get your chats retrieved by user/date - that can work nicely.
Cosmos DB is a lot more flexible than Azure Tables but a lot more expensive with a lot more hidden costs - like performance as a cost. And having to pay per collection, even if you don't use it.
I'm using Firebase in my iOS app but I want to ensure a value is never sent from the server to the client.
Users in the app are shown to each other based on a score they have. So a user with a score of 5 will see other users who have a score of 5. I don't want to include this value in the request/response to Firebase.
Where I can manage the server I can have server side logic handle this by looking up the user on the server then calling a function that determines who has the same score and returning the relevant users without the client ever receiving the user score.
With Firebase my understanding is I'd have to send the value to Firebase in a query i.e. get all users with this user's score.
How can I do this without exposing the user's score? I want something along the lines of a node user_scores where I can query the current users score and then using this query another node users to return me the relevant users without having to nest the query on the client and thus expose the score in the request/response?
Many thanks!
Your understanding is pretty much on point, there is no way to make a "dynamic" query like this without actually exposing the varying parameter to the client.
Here are two ideas you could try to use as a workaround:
A variation of "security by obscurity": instead of exposing a single number, obfuscate that value in a way that makes guessing its purpose and other values an unpleasant experience; and share that with the client.
If you keep your users grouped by this key, not just as a flat list where this is a child node, you can use security rules to enforce that the user cannot read any other group than theirs.
(Note that this is also true for numerical values. Security rules are not filters.)
In a much more involved strategy, you could make the query static. Store and maintain a list of matching users per user, so the clients can load their own personal list without any varying parameters sans the UID.
(This is probably not really feasible if there is a lot of movement involved. But it might work in some edge cases.)