Pagination Algorithm Implementation Assitance

Question

I am writing an paging algorithm but I am a bit confused on the best way to implement. I have read articles on using Offset and the issue if new content is published. Alternative is using the seek method.

So what am I really trying to accomplish? I am sure some of you may have heard of Tinder. When you load the app up, a set of cards appear. The cards are filled with information about other users you can like or dislike. I assume a simple query with a limit to retrieve the users is done for the first call. However, after the user swipes a couple times, the app makes more and more calls. I would like to do something similar. This is my current setup.

Psuedo Code for the APP:

1) Lets say I have choose to load 10 cards initially.
2) User keeps swiping 
3) When a user has 3 more cards left my app makes another call to the API and gets 10 more cards.
4) Repeat from step 2.

There are some issues that I am facing with the logic of the API side (not the app side).

1) User started the app and the API fetched initial 10 cards. When it comes
time for step 3, just making another call based on whom the user has
liked/disliked can load duplicates of the remaining 3 cards
2) If I choose to use offset, new users will mess up the pagination as a 
duplicate will be loaded.

I thought my solution to number one is to have a temporary table that stores what users have been loaded. Once a user likes/dislikes a person, that entry gets removed from that table. The issue with this logic is that lets say a user loads 10 cards initially, then swipes on only 5 and leaves the app. Now I have 5 users stored in the temporary table that will not load for the user because it has already been loaded and there has been no action. Plus there is extra overhead.

So my question really is what is the best way to create an API that allows me to load the cards without duplication. I don't think it is very efficient to load one at a time (too many calls to the server). A final note: I am not fetching directly from users table. I am taking the users then putting them in an algorithm. The algorithm spits out a set of 10 users.

If you have made it through this long post, I apologize. I just wanted to let you know that I have sincerely tried to come up with a solution and just needed a little push.

Answer 1

I thought my solution to number one is to have a temporary table that stores what users have been loaded. Once a user likes/dislikes a person, that entry gets removed from that table. The issue with this logic is that lets say a user loads 10 cards initially, then swipes on only 5 and leaves the app. Now I have 5 users stored in the temporary table that will not load for the user because it has already been loaded and there has been no action. Plus there is extra overhead

I'd like to emphasize "leaves the app" and "and there has been no action" in your current approach problem.

What if you actually do something when the user leaves the app?

I mean, coud you delete (from the temporary table) those 5 remaining temporary records that he didn't see in order to avoid this problem?

By reading all your description it seems you could solve it by doing that.

I hope this helps.

Answer 2

I think this can be solved more easily at SQL sevel e.g. (pseudo SQL)

create table user (PK ID id, VARCHAR(20) name, etc)

create table like (ID source FK user$id, ID target FK user$id, bool liked)

-- my current app user is id=5453
select top 10 
from user 
where id not in (select id 
                 from like 
                 where source=5453) 

You pick the top 10 users that have not been seen by source. Whenever he sees a target liked/not liked, a new row is added in like. It is probably best to send the 10 like results and batch insert those ten rows in the same API call as you request the next 10. If you want more aggressive caching then you need to filter on the App side.