Activity Feed Structure - php

Question

I am building a function that will add a log of what my user has done into my database so that I can then build a activity feed for other users' activity feed.
What I imagine it to resemble so far.
Activity table
id | user_id | source | source_id | timestamp
Example Input
1 | 1 | photo_upload | 54 | 1333906150 //54 being the ID of the photo in my DB
2 | 1 | follow | 2 | 1333906159 // 2 being the id of a user
This way I can easily pull information from the database for a users activity, "user_id = {$followers} then show them according to what their source is e.g show the image for a photo_upload.
EDIT
What would be the best way to display different types of the feed.
This is what I currently have but it seems a bit much.
<?php
$grab = mysql_query("SELECT * FROM `activity` WHERE `user_id` IN (".$following.") ORDER BY `id` DESC");
while($row = mysql_fetch_array($grab)){
switch ($row['source']) {
case "photoupload":
// Display photo upload layout
break;
case "follow":
// Display follow layout
break;
}
}
?>
Does anyone see any ways to improve upon this?

Answer 1

Create an abstract class describing a feeditem type:
abstract class Application_Feed_Item_Abstract {
protected $_item;
public function __construct($itemData) {
$this->_item = $itemData;
}
abstract public function render();
}
Implement this class for different kinds of content:
class Application_Feed_Item_Photo extends Application_Feed_Item_Abstract {
public function render() {
//Custom rendering logic for a Photo
return '<div>Watch my photo</div>';
}
}
class Application_Feed_Item_Follow extends Application_Feed_Item_Abstract {
public function render() {
//Custom rendering logic for a Follower
return '<div>I got a new follower</div>';
}
}
So when you pull a record, you are able to create a renderer object on the fly depending on the kind of feeditem:
//Pull items from database and store them as an Array or other iterable object.
//Here i assume we call this collection of rows from the database $feeditems
//Mapping of source to renderer classes
$types = array(
"photoupload" => "Application_Feed_Item_Photo",
"follow" => "Application_Feed_Item_Request",
"somethingelse" => "Application_Feed_Item_Somethingelse"
);
//Process every item
foreach($feeditems as $item) {
$type = $item['source'];
if(!array_key_exists($type, $types)) {
throw new Exception("Unsupported feeditem type.");
}
$type = $types[$type];
$renderer = new $type($item);
echo $renderer->render();
}
Just a loose idea for a way to implement it. But as stated by another user, there are many different ways to do it, depending on your requirements. The method you used in your question would work just fine

Answer 2

There are many ways to skin a cat. Similarly there are many ways to achieve the same results you require.
Some suggestions for "improving" IMO would be -
1. Fetching this data as pre-generated HTML with an AJAX call.
Using an AJAX call once the page is loaded, you could have your server build the HTML segments of your users activity feed. This will allow your page to load much faster and your content will be loaded shortly after.
You don't even have to build HTML on the server - you could also pass a JSON object back from the AJAX call and build your HTML with JavaScript.
2. Creating a cached static HTML file of the users feed that is simply included into the markup.
You could have your server generate all the HTML needed for a users feed at a certain interval - every 30 minutes for example - and then save that HTML into a file to be included in the existing HTML. You can do this using PHP's include() function.
Using this method the activity feed will have a delay when refreshing so it might not be the best option - but if you make the interval smaller - every 5 minutes for example, you'll be saving a lot of calls to the DB.
Check out cron jobs - you could possibly use them to schedule the updates.
3. Place an index on the user_id field in your DB since you are using it to search by user.
This is a very important one especially if you are expecting many entries to exist in your DB. Placing an index on the fields that you use to search a table will vastly increase the performance of your queries.
I'm sure there are many more things that can be suggested here.