À mon avis, cette fonction devrait être gérée côté serveur, surtout si vous vous attendez à ce que les utilisateurs utilisent plusieurs types de clients (par exemple, navigateur, téléphone, etc.)
Chacun de vos événements doit avoir un horodatage afin de savoir quand chaque événement s'est produit et afin de pouvoir effectuer des recherches de plage en conséquence, au cas où vous auriez besoin d'obtenir, par exemple, les dernières 24 heures d'événements ou des événements après l'horodatage X.
Ensuite, lorsque l'utilisateur qui suit un autre utilisateur consulte ses notifications, vous pouvez définir un horodatage comme point de contrôle pour savoir jusqu'à quel événement cet utilisateur a déjà vu, puis afficher uniquement les événements qui se trouvent après ce point de contrôle.
La façon dont j'ai implémenté les séries chronologiques dans REDIS dans l'un de nos projets consiste à utiliser des ensembles triés (http://redis.io/topics/data-types#sorted-sets). Dans votre cas, vous pouvez stocker :
user1EventsKey -> [{ts1, eventKey1}, {ts2, eventKey2}, {ts3, eventKey3},... ]
# This is the sorted set
eventKey1 -> [photo1, photo2, photo3]
eventKey2 -> [photo4, photo5]
...
user2Checkpoint -> tsA #where ts2 < tsA < ts3
Maintenant, vous savez que la prochaine fois que l'utilisateur2 affichera les notifications, vous n'afficherez que les événements après tsA en utilisant ZRANGEBYSCORE user1EventsKey ts2 +inf pour obtenir toutes les clés d'événements, puis un par un, vous pouvez afficher les événements.
PS. L'horodatage peut être stocké au format UNIX.
J'espère que cela vous aidera.
