Store item against user, or user against item?

Hi all, my site, let’s say is a website where you go on and look at kittens, and right now, when you go on and look at a kitten, you can mark that kitten as complete, so you dont click on that kitten again to look at it, currently this is stored in the local browser session, so that when you return on this browser, the site can mark off your previously viewed kittens as complete.

Now im moving forward with it, I have accounts/registration in place, and its time for me to think about adding your kitten history to your user profile, so naturally wherever you log in, your kittens are in sync!

Heres the question though, im not doing anything fancy like related content (might be the wrong name, ive forgotten), I am just storing the ID’s of the kittens in the browser, that you have viewed, super simple, I thought, lets just take that JSON string I was storing in the browser, and if your logged in, copy that string into your user profile on Strapi, do some conflict checking etc, and there, done.

However, the developer I sometimes work with on this project thinks this is wrong, and that we should store the users who have viewed each kitten, against the kitten in question, so ‘Small Brown Kitten’ would have a field that stores some sort of array of user ID’s etc, and then when the front end loads ‘Small Brown Kitten’, if someone is logged in, we check if their username comes up in the array for this kitten.

I personally dont know which is ‘correct’ here, my gut was option 1, but I thought I would put it out to the community, is option 1 even possible OOTB? I assumed I could update a verified user via a similar routing system as the kittens themselves, ie PUT into UserX {newKitten:1012} for example.

Thanks all!

1 Like

Hmm, I had something similar a few years ago, but not with “kittens”. The developer is right; it’s not a got approach to store it in a local storage, as it is local. If you switch from desktop to mobile or vice versa, you will not have your kitten history. This is why you should store it in DB.

So the best approach is to have a relationship called Viewed kittens where User has many kittens. So when you are authenticated and make a GET request to /kittens, you get their IDs and verify if the user has a relationship with them under Viewed kittens. In that case, you mark that kitten with a new field called: viewed: true. Otherwise, add a field viewed: false. You will receive all kittens in the frontend, but now you have that additional variable viewed and you can do your magic with it.

1 Like

Also, an approach from a big company like youtube, have you noticed that their viewed history disappears after a while? For example, you watched a video one year ago, and now it doesn’t have that “Watched” mark. That’s because they are keeping a limited number of Watched videos. When you watch a new video and exceed the limit of 200 Watched videos, they are deleting one Watched video (the oldest one). You can do the same trick not to make an oversized DB.

1 Like

Hey Sunnyson, thanks for your reply!

To clarify, the local storage was just the version 1 idea, it will 100% be going to the database, but because my site can be used both anonymously AND when you are logged in, I need to store in the browser as well :slight_smile:

It seems like you still agree though, store the kittens against the user, and not store the users against the kittens, would you say that is correct?

Then for unauthorized users, store kittens in local sessions, and when it creates an account, transfer all that staff to DB and delete it from the browser.

Yes, you better store kittens inside the User.

If you store users inside the kittens - imagine that you deleted the user. What happens next? Your kittens will remain with a relationship to an inexistent user, and you should search in ALL kittens to find if it has that user and delete its relation

If you store kittens inside the users - then you just delete the user and the story finished here.

1 Like