I'm building a social network app with the usual user-follower-relationship. My DynamoDB table is structured like this:
Item
PK
SK
GSI1PK
GSI1SK
GSI2PK
GSI2SK
User:
USER#id
#META#id
Follow:
USER#id
FOLLOW#id
FOLLOW#id
USER#id
Post:
USER#id
POST#ulid
POST#ulid
#META#id
post[0-9]
POST#ulid
I now want to create a feed for the user's front page.
The feed should include the 10 latests posts of the users the user is following.
My approach currently is to first query for all FOLLOWs of the user and then loop through all the user items and get their posts. But this approach could lead to a lot of read actions when the follower lists grow larger. Imagine a user having thousands of followed users.
Is there maybe a more efficient approach?
Related
I'm using aws congito for user storage. Now I need to get user names and avatars for a list of user posts. But as far as a know, the listUsers api does not accept a list of subs as a filter condition. So how can I achieve this?
I have some other ideas, like syncing user information to a dynamodb by lambda trigger, or storing user name and avatar in posts database (but it's hard to update user info).
Is there a better way to get user information for a list of posts?
Until filtering by list of subs is possible, I would use multiple https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ListUsers.html calls with only one sub in parallel (fork join approach) and store the data in a cache (Redis would do nicely). This way, it will fetch data from Cognito only once for a user, making it very efficient after the first try.
I'm trying to track user history using a DRF backend. For that, I've created a history table that will get a new timestamped row with each update. This model is a many-to-one and has a reference to the user model by a foreign key.
Here comes the confusing part. Every time I pull up the user profile, I would like to also pull the last entry into the history table. Thus, I am considering adding a couple of columns in the table which get updated with every insert into the history table since this is probably less expensive than performing a secondary lookup each time. I'd like some feedback on this approach.
Additionally, I'm slightly confused by how to perform this update/insert combination via a single API endpoint as DRF seems to only support one-to-one CRUD.
For illustrative purposes, I'd like to achieve the following via a single API view:
User hits API endpoint with access token and update values --> Insert history table --> update user table for user's row with inserted details
Thanks!
A little background. I've been developing the core code of an application in python, and now I want to implement it as a website for the user, so I've been learning Django and have come across a problem and not sure where to go with it. I also have little experience dealing with databases
Each user would be able to populate their own list, each with the same attributes. What seems to be the solution is to create a single model defining the attributes etc..., and then the user save records to this, and at the same time very frequently changing the values of the attributes of the records they have added (maybe every 5~10 seconds or so), using filters to filter down to their user ID. Each user would add on average 4000 records to this model, so say just for 1000 users, this table would have 4 million rows, 10,000 users we get 40million rows. To me this seems it would impact the speed of content delivery a lot?
To me a faster solution would be to define the model, and then for each user to have their own instance of this table of 4000ish records. From what I'm learning this would use more memory and disk-space, but I'd rather get a faster user experience as my primary end point.
Is it just my thinking because I don't have experience with databases? Or are my concerns warranted and I should find a solution as to how to be able to do the latter?
This post asked the same question I believe, but no solution on how to achieve it. How to create one Model (table) for each user on django?
I want the user's of my site to be able to upload information into a database. I know that Django doesn't really allow me to let the user's have their own dynamically created tables. So I'm wondering what is the most efficient way of handling this.
For instance if all user's want to save mailing lists containing names, emails, numbers etc Would I just put all of these into one giant table with a column for the user ID or is there a smarter way to do this?
The basic functionality would allow users to upload data from a CSV in a restricted format. i.e. email, name which would be placed into a table like this:
user | email | name
However, I'd like to further improve on this so that a user can specify their own fields. i.e. Add phone numbers, address or whatever other info they want. Perhaps also having the ability to add their own field headings under a model similar to the following.
user | field1 | field2 | field3 | field4
You don't need to create a new table for each user. You would do exactly what you said, have a single mailing list table and store each record with an associated user ID. Then, when a user wants to view their lists, you filter that table by user ID. Similarly, if a user wanted to modify a mailing list, you'd make sure that user has the same ID as the record they're trying to modify.
Django already has a very powerful user authentication and permissions system. You should use it to ensure that only logged in users can access their records.
I suggest you take some time and carefully ready the Django documentation and follow the First Steps tutorials. They'll give you a better understanding about how to set up your models and implement authentication.
This looks like it should be easy but I just can't find it.
I'm creating an application where I want to give admin site access to people from different departments. Those people will read and write the same tables, BUT they must only access rows belonging to their department! I.e. they must not see any records produced by the other departments and should be able to modify only the records from their own department. If they create a record, it should automatically "belong" to the department of the user which created it (they will create records only from the admin site).
I've found django-guardian, but it looks like an overkill - I don't really want to have arbitrary per-record permissions.
Also, the number of records will potentially be large, so any kind of front-end permission checking on a per-record basis is not suitable - it must be done by DB-side filtering. Other than that, I'm not really particular how it will be done. E.g. I'm perfectly fine with mapping departments to auth groups.