Final Project: Blabber backend
Contents
Due dates
- an initial database model diagram is due Wednesday, April 6, 2016 at 11:59pm (submitted on Canvas)
- relational tables set up Wednesday, April 13, 2016 at 11:59pm (submitted on Canvas)
- at least three API action functions are due Wednesday, April 20, 2016 at 11:59pm (submitted on the sever—see Submissions)
- 50% of API action functions are due Wednesday, April 27, 2016 at 11:59pm (submitted on the sever—see Submissions)
- The final report (submitted on Canvas), database design diagram (submitted on Canvas) and code (submitted on the sever—see Submissions) Wednesday, May 4, 2016 at 8:59am
Introduction
The goal of this project is to give you experience with modeling information for a web application. You will use several industry standard technologies, namely:
- PHP (or equivalent) for the API layer
- Relational DBMS (MySQL/PostgreSQL/etc.) for persistent storage
- NoSQL (MongoDB or equivalent) for persistent storage
- JSON for returning information from the API
- Information retrieval system for quickly querying over free text (Lucene)
Below are the requirements for an application programming interface (API), which you will have to implement using the components described above. Your PHP (or equivalent) files will act as the interface between the front end and the databases. You will not be designing the front end for your project, unless you want to for extra credit.
There are many tools that you will need to learn along the way, and we will use class time to go over those tools.
You may work with up to one other students from the class on this project. All members of your group are expected to perform an equal share of the work.
(Back to top)Blabber
The project will consist of implementing an API (see the next section) for a micro blogging web site (think along the lines of Twitter). We'll refer to the system as Blabber. Blabber has three parts:
- a web interface front end
- an API layer on the back end
- a set of databases and services on the back end
The web interface, which you will not have to program, will allow a user to:
- sign up
- sign in
- sign out
- change user info
- post a blab
- re-blab an existing blab
- like a blab
- search blabs
- follow other users
- list everyone they are following
- unfollow someone they are following
- list everyone following them
- view other users along with:
- their followers
- who they are following
- how many users they are following
- how many of their blabs have been re-blabbed
- how many of their blabs have been liked
- their blabs
API
The API will be exposed via a single PHP (or equivalent) file and parameters passed to it via POST (more on that later). That file will be called blabber.php and should be located in the public_html/csc340-final-project directory of one of your group member's home directory on the server (e.g., John Smith's would be /home/jsmith/public_html/blabber.php). This will be accessible via the web at: http://pacman.feild.org/~YOUR_USER_NAME/csc340-final-project/blabber.php, where YOUR_USER_NAME is your group member's username (e.g., for John Smith, it would be jsmith).
You should download the simple front end to that public_html/csc340-final-project directory. You can do this by running the following command from said directory:
wget http://hank.feild.org/courses/2016-sp/csc340/blabber/blabber-frontend.html
In PHP, POST parameters can be accessed via an associative array like this:
All API functions will have, at a bare minimum, one parameter:
- action (string)
If there is an error processing any actions, including unrecognized actions, the API should return an error message formatted in JSON as follows:
(Note: the angled brackets represent place holders!)
Here's a listing of all the valid values for the action parameter (you can click on one to bring you to the corresponding section).
(Back to top)action:signup
Assumes the following additional parameters:
- username (string)
- password (string)
- displayName (string)
- handle (string)—must be unique!
Also, note that the username parameter must be unique during signup; that is, no existing user may already have that username. If either the username or the handle already exists, you must return an error message. The output should be returned in JSON format; if the sign up was successful, return:
(Back to actions)action:signin
Assumes the following additional parameters:
- username (string)
- password (string)
This is used to notify the server that the user has signed in. One of three things should happen after the user has been authenticated:
- if no session cookie exists, create one and add the username to the cookie
- if a session cookie already exists and the username is different, sign that user out first, then follow the steps in option 1
- if a session cookie already exists and the username is the same, return an error message saying "User already signed in"
The cookie should be used for all other actions (other than signup) in place of authenticating the user. If, for another action other than signup, a session cookie with a username does not exist, an error should be returned with the content: "User not signed in.".
The response for this action should be in JSON format; if the sign in was successful, return:
(Back to actions)action:signout
Assumes no additional parameters. This is used to notify the server that the user has signed out. The response should be JSON format; if the sign out was successful, return:
(Back to actions)action:changeInfo
Assumes the following additional parameters:
- displayName (string) OPTIONAL
- handle (string)—must be unique! OPTIONAL
- currentPassword (string) OPTIONAL (but required if newPassword is included)
- newPassword (string) OPTIONAL
Information can only be changed for the user specified by username (i.e., one user cannot change the information of another user). The user may update one or all of these parameters. Un-specified parameters should maintain their current values in the database(s).
The output should be returned in JSON format; if the info change was successful, return:
(Back to actions)action:getUserInfo
Assumes the following additional parameters:
- handle (string)
This should retrieve all of the publicly available information about the user associated with handle. This can be the same as the current user's handle, or some other user.
The output should be returned in JSON format; if the info change was successful, return:
(Back to actions)action:blab
Assumes the following additional parameters:
- contents (string)
This function should save the first 300 characters of the given contents string to the database. If successful, the returned output should be formatted as:
(Back to actions)action:getBlabs
Assumes the following additional parameters:
- since (timestamp)
- handle (string)
This will retrieve all saved blabs blabbed by the user with the given handle since the given timestamp. If the given handle was valid, the return value should be formatted as:
Where blabs can consist of a mix of blabs and reblabs. A blab is formatted as:
And a reblab is formatted as:
The list of blabs should be sorted chronologically, newest to oldest. Each blab must have a unique id (across all users and blabs). In a reblab, the balbbedOn field corresponds to the time it was reblabbed. Note that the reblab must contain the original blab as a field.
(Back to actions)action:reblab
Assumes the following additional parameters:
- blabID (id)
This will reblab the blab with the given id. If the given handle was valid, the return value should be formatted as:
(Back to actions)action:like
Assumes the following additional parameters:
- blabID (id)
This will add a 'like' to the blab with the given id. If the given handle was valid, the return value should be formatted as:
(Back to actions)action:search
Assumes the following additional parameters:
- query (string)
- handles (list of strings, comma separated) (OPTIONAL)
Searches blabs for the given query text. If the handles parameter is provided, then only blabs blabbed or re-blabbed by users whose handles are listed are searched. The results should be returned to the user in the format:
(Back to actions)action:follow
Assumes the following additional parameters:
- handle (string)
Adds the given handle to the user's list of followers. The results should be returned to the user in the format:
(Back to actions)action:getFollowing
Assumes the following additional parameters:
- handle (string)
Produces a list of the handles the given handle is following. The results should be returned to the user in the format:
The output should be read as: this user (handle) is following this list of users (following).
(Back to actions)action:unfollow
Assumes the following additional parameters:
- handle (string)
Removes the user from the followers list of the user with the given handle, and removes the user with the given handle from the user's following list. The results should be returned to the user in the format:
(Back to actions)action:getFollowers
Assumes the following additional parameters:
- handle (string)
Produces a list of users following the given handle. The results should be returned to the user in the format:
The output should be read as: this list of users (followers) are following the user with this handle (handle).
(Back to actions)Requirements
You must keep track of the data being created (e.g., users, blabs, etc.) as well as all of the actions taking place. By storing all of the interactions (e.g., API requests), the Blabber overlords can decide to engage in some juicy analytics down the road and find interesting trends, etc. Every logged event should include a timestamp. It is up to you to decide whether to use a RDBMS or NoSQL database to keep a record of all transactions.
For the relational database, you must have the following:
- SQL transactions where appropriate (*cough,cough,everywhere,cough*)
- at least two SQL views
- at least one SQL index (not including the default primary key indexes)
- at least one trigger
- at least two constraints
You must make use of Lucene to satisfy at least one of the actions.
For each API request (other than signin and signup), you must verify that the user is logged in. For the signin action, you must authenticate the user by ensuring username is a valid user and that password is the correct password. You should combine the password with a user-specific, randomly generated salt value and store the hash of the combination (e.g., MD5 or SHA-256). If the credentials are invalid, you should return a reasonable error message. API access calls that result in errors should still be logged.
(Back to top)Skills
There are several skills you need to have in order for your project to be successful. Between now and the project due date, we will spend class time learning many of these skills and applying them to your project. Here are some of the tools:
- Unix tools
- ssh
- scp
- vim
- wget
- cd
- mkdir
- PHP (or equivalent)
- MySQL/PostgreSQL (or equivalent)
- MongoDB (or equivalent)
- Lucene
- Database design and diagramming
Submissions
Some of the milestones and parts of the final submission require that you upload a document to Canvas. You will never need to submit code via Canvas. Rather, you will use a command on the server to snapshot your work, and the time at which you run the command will be considered your submission time. Before you snapshot, make sure you have all the materials you intend to submit in the directory /home/YOUR_USERNAME/public_html/blabber. That directory only needs to exist for one of the members of your group. The snapshot command works as follows:
snapshot-blabber USERNAME
Where USERNAME is the username associated with the project directory.
The final submission includes:
- a project write up, which consists of a description of who in the group did what tasks and a detailed discussion of your design decisions for the project; this can be a Word/Google Doc or a PDF and should be uploaded to Canvas
- a database diagram for all databases you used; this should include all tables, fields, types, and the relationships between tables; this should be in PowerPoint or PDF format and uploaded to Canvas
- well-styled and documented code for the API; this should be submitted on the server using the snapshot command described above
Extra Credit (10 points)
The purpose of this project is to demonstrate your ability to model information, store and access data from different types of databases, and use PHP to perform the interactions. The front end is out of the scope of this class. However, if you would like to, you can get up to 10 extra credit points if you beautify the front end so that the site resembles a modern web site. You can use HTML, CSS, JavaScript, and whatever else you would like. If you do the extra credit, be sure to inform me so that I know to look for it. Include the web address of your front end.
(Back to top)Rubric
| Database Design | The diagrams are clear and all of the information is well modeled. There is a reasonable organization and the relational databases are in BCNF and unnecessary redundancy is absent. The implementation of polyglot persistence is logical. (30pts) | The diagrams are somewhat unclear. Not all of the information is modeled, or is modeled incorrectly. The organization is not logical and redundancy of data exists. (15pts) | The diagrams were not submitted or are extremely messy. Little or no information is modeled logically. Redundancy is rampant. (0pts) |
|---|---|---|---|
| Database Implementation | The RDBMS tables are set up correctly. Data is stored and accessed in the RDBMS, NoSQL, and Lucene in an efficient fashion. Data is stored using best practices. (30pts) | There are some issues with the way tables are set up in the RDBMS. Data is not stored/accessed in the most efficient manner from one or more of the storage systems. Data is not consistently stored using best practices. (15pts) | The RDBMS tables are not properly set up. One or more of the persistent storage systems were not used. There is no attempt as efficiency. (0pts) |
| API code | The PHP (or equivalent) code is clear and efficient. It is well documented and formatted correctly. (10pts) | The PHP (or equivalent) code is somewhat unclear and difficult to read. Some parts are not efficient. Documentation is lacking and there are formatting issues. (5pts) | The PHP (or equivalent) code is a mess. There is not attempt at efficiency. Documentation is sparse or not present at all. Formatting was thrown to the wayside. (0pts) |
| API Implementation | The API works as described in the project description. All the data is returned in correct JSON format. (30pts) | Some of the API works as required. The returned data is not quite in the correct format. (15pts) | The API does not comply with the requirements. The data is not returned in the correct JSON format. (0pts) |
| Extra credit | The front end works smoothly, looks modern, and provides access to all of the API features. (10pts) | Aspects of the front end are not smooth or seem too simple. Not all API features are accessed. (5pts) | No front end was provided, or the front end is not smooth, modern, and does not access most API features. (0pts) |
| Total: | 100pts + 10pts EC |