I am building an application using AWS Mobile HUD and connected services, most prominently Cognito & DynamoDB. Currently I am facing a problem to setup a scheme that allows me to store user-related information on DynamoDB items (or vice versa).
Scenario
Run 1
User A pulls list of [RootItem] = {RootItem_1, RootItem_2, RootItem_3} from DynamoDB (check: works fine)
User A either dismisses RootItem_1 (mark as 'not interested' in app)
Run 2
User A logs into the application
User A pulls list of [RootItem] = {}
User A should only get RootItems which are not dismissed
List delivered to client should be {RootItem_2, RootItem_3}
Being new to non-relational data / NoSQL, I am not sure what is the best way to approach this. Possible Ideas:
Store userID on the RootItem_1 to exclude it in Scan [issue: there will potentially be thousands of users dismissing the same item]
Store uuid of RootItem_1 to userdata on cognito, cache locally before pull and exclude uuid's from pull
Create table with exclusions/dismissions [userid, rootItem_uuid], query this first to get list of user exclusions. > potential performance issue?
It would be great to get some advice what is the best approach to handle this in a NoSQL environment.
It depends of course on the number or RootItems, and how many active (not dismissed) RootItems are existing per user. But I would maintain a list of RootItems (or refereces to it) and store it in a table for each user, and maintain that list as the user dismisses the items. Or even is it possible that most items are dismissed, and then it would be a list of saved items for the users?
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.
From what i've been able to discern so far, Firebase/Firestore seem like the perfect platform to use for an app I am writing. However I can't quite connect all the dots when trying to design my backend. I am hoping that someone will be able to give answer a couple of basic questions about the use of FB/FS.
With my app, a user will be able to share a small piece of data with a select group of friends. ie if the data is to be a To-Do list, the user would create the list on his device (iphone only) and then invite a small group of friends (probably less than 10) to share that data. The friends would have read-only access by default, however, the user can assign any number of them to be "admins" which would allow them read/write permission. When any changes occur to the data, all "friends" who have access to the data will be notified (by some means - push notifications etc). They can manually sync or setup the app to automatically sync. It seems like FB/FS can be used for this right out of the box. However there are a couple of concepts that I can't get my head around.
The database I setup is accessible by ALL users of my app by default. It's not clear (at least to me) how I would set it up so when a user creates (in this case) a to-do list and invites 5 friends, only those 5 friends can access or even know about that data. This is main stumbling block in my development path.
Regarding invitations. I read in the FB/FS documentation that invitations and notifications are among the many features available. I'm not clear on how this will work if a) the recipient doesn't have my app installed and b) how the inviter would get feedback when the invitation was accepted or declined.
Any guidance that anyone is willing to share to help me get started will be a huge help and will be greatly appreciated. Thanks.
You can create new privates collections inside the main collection, and set different rules for access.
Check at: Firebase Firestore get private fields
I have a situation where a user has acess to multiple systems(10,000 for example). Each system is associated with a system_id.
We currently use a web service to determine what the list of systems the user has access to.
But, the issue I am facing is to retireve the list, I have to call this web service on each page of the app, which is likely to cause perfomance issue as more & more systems get added to the user.
One thought was, the first time when the user logs in, we get the list of system ids that user has access to and store in as an array of ids in a sessions or internal users table.
And going forward use that table on subsequent pages
Would that be a bad idea or can i get any other alternatives?
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!
We have a web-app that uses Mahout and CF filtering to generate product recommendations, based on users assigning ratings to items.
There is a iOS application that communicates with the webapp through a REST API, and let's users scroll through items, and assign them ratings.
The iOS application will pull a list of ranked products from the webapp - this is the list that is displayed to the user. As the user scrolls through to the end, we request further down the list.
There is also a requirement that the iOS application not show a user products that they've seen before on that specific device.
My question is - how should we be handling this last requirement?
Should each iOS client be maintaining a list of what they've seen before, and simply remove these from the list that it pulls from the server?
Or should the server maintain a state for each client, and remove them from the list before it sends it?
What pros and cons can you see for either approach?
Cheers,
Victor
First off, if the requirement is to not show a user products they've seen before on any device/platform (for example if they used the app on their iphone then ipad/ipod) then you'd definitely have to do it server side (as the app cannot know what the user has seen on other devices unless you are storing it on the server).
Assuming, it is a device specific requirement, I would think your goal would be to minimize (potentially unreliable or slow) network traffic to optimize the iphone experience. Syncing back and forth with the server will require extra network traffic, which may fail at times. Which would lead to a conclusion of client side storage. Unless your users are going to be seeing some huge number of products that would chew up disk space, but I assume the amount of data you store per user would be nominal.