[ruby-on-rails] Quelle est la meilleure façon de mettre en œuvre un flux d'activités sociales?



Answers

C'est une très bonne présentation décrivant comment Etsy.com a architecturé ses flux d'activité. C'est le meilleur exemple que j'ai trouvé sur le sujet, bien que ce ne soit pas spécifique aux rails.

http://www.slideshare.net/danmckinley/etsy-activity-feeds-architecture

Question

Je suis intéressé à connaître vos opinions sur la meilleure façon de mettre en œuvre un flux d'activités sociales (Facebook est l'exemple le plus connu). Les problèmes / défis impliqués sont:

  • Différents types d'activités (publication, commentaire ...)
  • Différents types d'objets (post, commentaire, photo ..)
  • Utilisateurs 1-n impliqués dans différents rôles ("L'utilisateur x a répondu au commentaire de l'utilisateur y sur le post Z de l'utilisateur")
  • Différentes vues du même élément d'activité ("vous avez commenté .." vs "votre ami x commenté" vs "utilisateur x commenté .." => 3 représentations d'une activité "commentaire")

.. et un peu plus, surtout si vous le portez à un niveau élevé de sophistication, comme Facebook, par exemple, combinant plusieurs éléments d'activité en un seul ("les utilisateurs x, y et z ont commenté cette photo"

Toutes les réflexions ou indications sur les schémas, documents, etc. sur les approches les plus souples, efficaces et puissantes pour mettre en œuvre un tel système, un modèle de données, etc. seraient appréciées.

Bien que la plupart des problèmes soient indépendants de la plate-forme, il est fort probable que je finisse par implémenter un tel système sur Ruby on Rails




J'ai résolu cela il y a quelques mois, mais je pense que ma mise en œuvre est trop basique.
J'ai créé les modèles suivants:

HISTORY_TYPE

ID           - The id of the history type
NAME         - The name (type of the history)
DESCRIPTION  - A description

HISTORY_MESSAGES

ID
HISTORY_TYPE - A message of history belongs to a history type
MESSAGE      - The message to print, I put variables to be replaced by the actual values

HISTORY_ACTIVITY

ID
MESSAGE_ID    - The message ID to use
VALUES        - The data to use

Exemple

MESSAGE_ID_1 => "User %{user} created a new entry"
ACTIVITY_ID_1 => MESSAGE_ID = 1, VALUES = {user: "Rodrigo"}



Si vous décidez que vous allez implémenter dans Rails, vous trouverez peut-être le plugin suivant utile:

ActivityStreams: http://github.com/face/activity_streams/tree/master

Si rien d'autre, vous aurez à regarder une mise en œuvre, à la fois en termes de modèle de données, ainsi que l'API fournie pour pousser et tirer des activités.




Les plus gros problèmes avec les flux d'événements sont la visibilité et la performance; vous devez limiter les événements affichés pour qu'ils soient uniquement intéressants pour cet utilisateur particulier, et vous devez garder le temps nécessaire pour trier et identifier ces événements gérables. J'ai construit un petit réseau social; J'ai trouvé qu'à de petites échelles, le fait de conserver une table «événements» dans une base de données fonctionne, mais que cela devient un problème de performance sous une charge modérée.

Avec un plus grand flux de messages et d'utilisateurs, il est probablement préférable d'utiliser un système de messagerie, dans lequel les événements sont envoyés sous forme de messages à des profils individuels. Cela signifie que vous ne pouvez pas facilement vous abonner aux flux d'événements des personnes et voir les événements précédents très facilement, mais vous affichez simplement un petit groupe de messages lorsque vous devez rendre le flux pour un utilisateur particulier.

Je crois que c'était la faille de conception originale de Twitter - je me souviens d'avoir lu qu'ils utilisaient la base de données pour filtrer leurs événements. Cela avait tout à voir avec l'architecture et rien à voir avec Rails, qui (malheureusement) a donné naissance au mème "ruby does not scale". J'ai récemment vu une présentation où le développeur utilisait Simple Queue Service d' Amazon comme backend de messagerie pour une application similaire à Twitter qui aurait des capacités de mise à l'échelle beaucoup plus élevées. Il peut être intéressant de regarder SQS dans votre système si vos charges sont assez élevées. .







J'ai commencé à mettre en place un système comme celui-ci hier, voici où je dois ...

J'ai créé une classe StreamEvent avec les propriétés Id , ActorId , TypeId , Date , ObjectId et une hachage de paires clé / valeur Détails supplémentaires. Ceci est représenté dans la base de données par une table StreamEvent ( Id , ActorId , TypeId , Date , ObjectId ) et une table StreamEventDetails ( StreamEventId , DetailKey , DetailValue ).

ActorId , TypeId et ObjectId permettent de capturer un événement Subject-Verb-Object (et de le demander ultérieurement). Chaque action peut entraîner la création de plusieurs instances StreamEvent.

J'ai ensuite créé une sous-classe pour StreamEvent pour chaque type d'événement, par exemple, LoginEvent , PictureCommentEvent . Chacune de ces sous-classes possède plus de propriétés spécifiques au contexte telles que PictureId , ThumbNail , CommenText , etc. (tout ce qui est requis pour l'événement) qui sont réellement stockées en tant que paires clé / valeur dans la table hashtable / StreamEventDetail.

Lorsque vous récupérez ces événements à partir de la base de données, j'utilise une méthode usine (basée sur TypeId ) pour créer la classe StreamEvent correcte.

Chaque sous-classe de StreamEvent possède une méthode Render ( context As StreamContext ) qui génère l'événement à l'écran en fonction de la classe StreamContext transmise. La classe StreamContext permet de définir des options en fonction du contexte de la vue. Si vous regardez Facebook par exemple votre fil de nouvelles sur la page d'accueil liste les noms complets (et les liens vers leur profil) de toutes les personnes impliquées dans chaque action, alors qu'en regardant le fil d'un ami, vous ne voyez que leur prénom. .

Je n'ai pas encore implémenté un flux agrégé (Facebook home) mais j'imagine que je vais créer une table AggregateFeed qui a les champs UserId , StreamEventId qui est peuplé basé sur un type d'algorithme 'Hmmm, vous pourriez trouver cela intéressant'.

Tous les commentaires seraient massivement appréciés.




Related