For this chapter, we will be building a no-frills photo-sharing application called Photoclone, hosted at the domain http://photoclone.saush.com.
Authentication and user management follow the similar route we went through in the Tweetclone. As before we will use RPX to proxy the third party authentication providers we want to use. However, unlike in Tweetclone we're not going to provide any APIs and therefore we're not going to use any client authentication. In this case we're not going to restrict ourselves to using Google's authentication mechanism as before.
This means that for user management, the functions are split between Google and Photoclone again. The functions to change their profile, manage their passwords, and generally secure their account lies with the authentication provider. However, Photoclone requires a user entity to manage the user-to-user relationships as well as photo ownership and therefore we store some user information in Photoclone. We also use the user information particularly the e-mail to get the avatar from Gravatar.
In Photoclone, access control is used to secure the user's right to view the photos. Photos can be public or private. Public photos are viewable by everyone while private photos can only be viewed by the owner/uploader. While Flickr has a concept of private for friends and family, Photoclone opts for a simpler design. If you follow a user, you will add his public photos in your shared photos list, basically a list of photos belonging to people you follow. This list is in the landing page (the page you 'land' on once you log in to the site). This allows you to have a clear view of the photos of people you follow.
Photoclone uses a simple design to store and manage photos. An album is a container of photos. Each album belongs to a single user and can be shared through that user. Each album has a cover photo, which is the representative photo that is when displaying albums.
Uploading and storing photos properly is a critical part of any photo-sharing application. A good photo-sharing application should have a user-friendly photo uploading interface and speedy file transfer rates. This is especially true as digital cameras become more powerful and take pictures of larger sizes than ever.
Uploading for Photoclone is simple and follows a conventional HTML file upload format, which is a very familiar interface to most users. The upload page will allow six photos to be uploaded at the same time.
There can be multiple ways of storing photos for Photoclone. The easiest and most direct way is to store the photos locally in the same server that runs the application. As you can imagine while this is relatively easy to implement it has many flaws. The most obvious flaw is that the server will run out of disk space quickly if the application data grows. Scaling becomes an issue at a later stage because it will be difficult to run multiple servers easily to load balance. For smaller setups this is usually not a problem though.
Local storage of data can be implemented in one of two popular ways—either in the filesystem (in a directory structure or not) or as binary data in a database. There are many debates on the feasibility of storing large amounts of binary data in a database as compared to the filesystem. Here are some of the considerations of the pros and cons of storing photos as files in the filesystem or as binary data in a database.
- Speed of retrieving and displaying the photo is faster than if it's stored in the database
- Photos can be cached easily
- No large database files to contend with
- Lower memory consumption
- Can be used over the network (though it will be slower)
- More security (not anyone can view the photos)
- Backup of files are all in a single place
Very often though, the solution ends up with the photos being stored in the filesystem but the database contains the metadata and pointers to the location where the files are stored.
Another way of storing photos is up in the cloud where services such as the Amazon Web Services (AWS) offer pay-per-use data storage facilities. The advantages of using cloud storage are:
- Very scalable, there is no limit to the amount of data you can store in the cloud
- Very little to no consideration for maintenance of servers or facilities
- Considerably cheaper than storing the data yourselves
- Can be used by multiple servers at the same time
As you can see the advantages of using cloud storage seems to be very similar to that of using the database. However, one major disadvantage is that depending on the location of the servers used in the cloud storage, the speed of uploading and storing photos can be quite slow.
In Photoclone we use a hybrid of cloud storage, filesystem, and database to enable optimal photo upload and display services keeping in mind the need for scaling as well budget. The design uses the Amazon Simple Storage Service (S3), which stores objects up to 8 GB in size in the cloud.
Objects stored in Amazon S3 are placed in containers aptly called buckets. In Photoclone, for easy management, we create a bucket for every user, when they first log in they store all their photos in this bucket. The files are uploaded into S3 and three different versions are created:
- Original —this is the original photo that is uploaded. The extension of the file is changed to
.orig. - Display —this is a photo that is resized to 500 pixels wide (with the necessary height in proportion), used for display in the main photo page. The extension of the file is changed to
.disp. - Thumbnail—this is a thumbnail of the photo for quick display. The extension of the file is changed to
.thmb.
A record is created for each photo that is uploaded and the database row ID becomes the name of the file. For example, when a photo is uploaded, a database record number 123 is created with the necessary metadata. The original file will be renamed 123.orig, the display photo will be named 123.disp, and the thumbnail photo will be named 123.thmb. All three photos are then stored in S3.
However, to improve the performance of displaying the photos, we cache the photo locally in the same server. The caches are just that, under normal circumstances, photos that have been around for a period of time can be removed through a regularly running script. This will reduce the disk space needed on the server while keeping the bulk of the photos in S3.
You might realize that this design also facilitates easy scaling of Photoclone. Although the photos are served through cached files on the server, we can just as easily deploy new servers and serve out the same photos, as long as we have access to the same database.
An important part of any Web 2.0 site is the community element of the site. Central to building communities is providing a means for users to contribute back to the site, in this case commenting on photos that are shared by users. The commenting mechanism itself is quite simple. Each photo can have one or more comments and any user can create a comment. However, only the commentator can remove his own comments.
Annotating photos is a common feature among the popular photo-sharing applications. Annotations allows the user to draw a rectangle around parts of the photo and attach notes to it. A photo can have one or more annotations on it, and are only applicable to the displayed photos. The annotations are not added in the photo image itself but added and displayed as a layer over the photo.
The ability to edit and modify photos online is not a common feature provided by most photo-sharing applications. However, we include this feature in because it is relatively easy to integrate a good online photo editor to provide this service. Amongst the better online photo editors that allow external integration include Picnik, FotoFlexer, and Pixlr. However, Picnik and FotoFlexer include mandatory advertisements in their integration. To provide a smoother user experience we integrate with Pixlr, which has a straightforward integration mechanism.
The integration involves sending the display photo to the Pixlr online photo editor. Once the user is satisfied with the changes, the photo is sent back to Photoclone to be saved.
Edited photos are linked back to their originals—each edited photo belongs to an original, so any photos that do not belong to an original is an original itself.
To share with non-users of Photoclone it's important that the URLs are friendly and easy to send out to anyone. Photoclone allows for sharing of user albums through the username like this:
http://photoclone.saush.com/user/sausheong
This will display all albums belonging to that user.
Sharing photos is a main purpose of any photo-sharing application (hence the name). When it comes to basic features, storing and sharing photos with friends are the key purposes of any photo-sharing application and these two features are the highlight of Photoclone.
Sharing photos to non-users can be done through the user by passing the friendly URLs above to any one. That will share albums and photos that belong to a particular user to anyone. Only public photos will be shown in those albums. Sharing photos to users of the Photoclone can be done through photostreams. If you follow another user, you will see his/her photostream (the latest photos he/she uploaded).
One of the main features in any social network involves modeling the interaction between its users. The two more commonly adopted models are the friend model and the fan model as described in the previous chapter. Photoclone, like Tweetclone previously, uses the fan model of social interaction. We use the fan model because we want to share photos easily and quickly. While the friend model has more privacy control there is a delay between the time a user requests for a connection and his friend actually approving that connection. As a result the number of connections in a friend model network is much smaller than in the fan model.
A quick recap—the fan model, unlike the friend model, is a one-way user connection. A typical example—you might know Barack Obama but it is most unlikely that he knows you in return. The differences are subtle but important. While the friend model is reciprocal, that is the user needs to approve and agree that you are his/her friend before a connection is made, the fan model is not. You can follow anyone that catches your fancy and the number of followers any one person can have can be very large.
Photoclone uses a very simple mechanism for sharing photos. Instead of deliberately sharing with friends (which you can still do via friendly URLs), the sharing mechanism is inversed. Your fans are able to view your photos through their photostream whenever you upload new photos, without any directed effort on your part (sharing becomes very easy). Conversely, the more people you follow, the more pictures you can view in your photostream. This encourages users to follow more users.