I am building out an iOS app that requires getting lists of users at different parts of the app(finding users nearby, find users that have similar interest etc) I'm displaying the list of users in collection views/table views.
I have a user structure that contains all of the user data(name, photo, list of interest, location, preferences..etc)
My question is, when I'm getting the list of users from the database, is it more cost effective to use the query function or to use the observe functions? In the list I only need to display the users photo and username. If the user wants to find out more then clicking on the cell will get more data from the larger user data table.
My options
using a query to get the users that meet the criteria for that list(say all users nearby). Then when the user clicks on the cell that interests them, get a snapshot from the database for that specific users.
My thought process is its less costly than pulling back the whole snapshot using the observe functions.
using the observe functions, getting all users snapshot data and only displaying the photo and username. If the user selects a cell send the data to the detail view.
creating a special display structure that contains only items necessary for the collection view/ table view and if the user clicks on a cell call the database again getting all of that users data.
If anyone has a point of view they could share that would be great!
Thanks
Observing in Firebase needed for making instant update, like in chats, when new message appear you need to update message list. So here, for getting list of users that fit your request, better to use queries
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.
I'm new to Firestore and trying to develop a data model for my app.
Background: I have a dating type of app with 3 primary ways that users will communicate with one another. Liking, dismissing, and commenting user profiles. Users likes & comments are private. In other words, only I can see who's liked or commented my profile (it's not like Social media where everyone can see who's liked a post). I'll need to be able to query users to know who's dismissed their profile so I won't show it to those users again. I'll also need to know who's liked/commented a users profile so I can query which users have liked/commented each other (they've matched)
Users can like many profiles and vice versa
Users can dismiss/skip many profiles and vice versa
Users can comment on many profiles and vice versa
I believe this means I'll need a root collection for likedUsers, dismissedUsers, and commentedUsers
Problem:
For dismissed users, I thought I'd store every single user as a Document of the dismissedUsers root collection and store every user they've skipped as a field/value pair like so...
dismissedUsers/User/user1, user2, user3, etc
The above would create the many-many relationship I want where dismissedUsers can have many users and users can have many dismissedUsers. However, I don't believe it would be scalable as the User Document would grow too large.
Question: How do I create this many-many relationship where dismissedUsers can have many users and users can have many dismissedUsers so that it's scalable and least expensive? And query it?
First of all I would ask myself why I am using Firestore, being a document database, instead of choosing a relational database. I personally love Firestore and highly recommend it. We pick a document database because it is faster and easier to use in many ways. In other ways it is a drawback because you have very limited query power. It sounds to me like your brain is working towards a relational database implementation.
Here is one solution
First of all I would try to avoid storing user data in more than one location to avoid anomalies (of course right). I would have one collection of users where I stored all user data with a unique id (best to use the one that Firestore assigns so I don't have collisions). Within each users document I would link a subcollection for dismissed, liked, been dismissed by someone else, liked by someone else etc.. I would keep a record of all users (just the user id) that they have dismissed, liked, been dismissed by, been liked by etc.. This way I can look up all data for who that user has liked or disliked and display whatever I want to that user accordingly.
Drawbacks
You will have to write twice per like, dismiss etc. Use a batch write to update both the liked and likee data at the same time.
You don't need a collection of users who liked, dismissed, or commented on another users profile. You can have one user collection which stores all users. Inside each user document you can have three array of the user ids of the users that liked, commented, and/or dismissed a user profile. Just make sure that the document ID of the documents inside the users collection matches the user id of the corresponding user.
I am working with Firebase database for my application. I have one scenario where I need to display list of Call detail screen where each user's call history should be display. In firebase database I have two main node
Here is the image of the both node.
1) Users - user node have user related data with basic details of name,email and other stuff
2) Calls - user's call history each call have user_id which is related to in Users node for his/her basic details.
Now I want to details (first_name,last_name,email) of user_id from Calls node each entry or each object. So is there any solution for getting details via passing a comma seprated user_id list and getting its details from Firebase. Or is there a any other solution to fetching basic details.
Thank you in advanced if any one have faced this and provide a solution on this.
I'm working on an iOS app which at one point displays a feed of information items to the user, that contain information about other users. These feed items are stored on a server that I run as well. I want to add a functionality that allows this user to filter the information and display only items of his facebook friends. It seems to me that there are three ways to achieve this
1
Client fetches all items.For each item run that FB SDK query /user-id/friends to determine friendship
2
Save all of the facebook ID's of the users friends on the client (each set time),and after fetching all items, determine if item is posted by friend with comparison to local database of friends.
3
The server with the feed items would run the query in the backend, and filter the content it provides to the client
Each of these has it's weakness and advantages, but I'd like to hear which is the preferred and "best" overall. I'm trying to achieve something like VENMO's home feed functionality if that makes sense.
Thanks for the help!
So, I am using Google Contacts API to let users import their contacts from GMail.
I want the users to be able to select the contacts they want to import in my app, So currently I -
GET a XML feed of all the contacts a user has.
Parse it, and for each contact create a record in the imported_contacts table.
Display the list to the user, with checkboxes, so the user can select which contacts it wants to import.
When the user submits the form, I copy the selected contacts from imported_contacts to the main contacts table.
This works fine, but doesn't feel right. Can someone suggest a way to do so, without using a separate table(imported_contacts).
Map the contacts from XML to objects in memory. Only save them to the main contacts table after the user has selected the ones she wants.
Model View Controller.
Import the contacts into Contact objects, and store in a ContactRepository. All of this is completely in-memory, and is your Model.
When rendering this list in your View, each checkbox will have an ID which will relate to the ID of the Contact object in the Model.
When the user submits, your Controller will be able to interrogate the View for a list of the selected checkboxes (and their IDs), and then it's a case of going through the Model and creating the necessary rows in the database.