It can be hard to track TV shows that you want to watch, especially when you want to share those preferences with a partner or friends. This application allows you to find TV shows by name and cast members, make lists of shows you want to watch, and compare those lists with other people to find shows that you can watch together. It uses the TVMaze API for data about TV shows.
There are no user stories for deployment: it is expected that you will deploy the application to production after you finish a user story.
There are no user stories for logging: it is expected that you will add logging to the application with enough detail to help you diagnose issues in production.
To get started on this project, fork and clone this repository. Keep in mind that you will not be making a pull request to this repository.
To install, run the following commands from your command line. Make sure you are in the root directory before running the commands.
npm run backend-install
npm run frontend-install
To start the project, you have a few different options. View the package.json in the root directory to see the scripts available to you.
For development purposes, you will likely want to open up a terminal tab, navigate to the backend/ directory, and run npm run dev. In a different terminal tab you will want to navigate to the frontend/ directory and run npm start.
Alternatively, you can run npm start in the root/ directory which will run the npm start commands of both the backend/ and frontend/ directory. npm run start:dev will do the same, but will run the server in development mode.
Set up a new PostgreSQL database instance by following the instructions in the "PostgreSQL: Creating & Installing Databases" lesson.
Run cp ./back-end/.env.sample ./back-end/.env and update the ./back-end/.env file with the connection URLs to your PostgreSQL database instance.
Navigate to the backend folder, where the knexfile.js file is located, and run the npx knex commands from there.
To run the tests for the backend, you can use the npm test command from the root directory of this project.
As you work through the user stories listed later in this document, you will be writing code that allows your frontend and backend applications to talk to each other. You will also write code to allow your controllers and services to connect to, and query, your PostgreSQL database via Knex.
The table below describes the folders in this starter repository:
| Folder/file path | Description |
|---|---|
./backend |
The backend project, which runs on localhost:5001 by default. |
./frontend |
The frontend project, which runs on localhost:3000 by default. |
This starter code closely follows the best practices and patterns established in the Robust Server Structure module.
Note: Please do not submit a pull request to this repository with your solution.
The root directory (where this file is located) contains the instructions for your project, a .gitignore file, and a package.json file.
The package.json file includes a number of scripts which may be useful for building your project. Before beginning your project, make sure to look through the file.
The backend directory contains a working server although there are no pre-written routes. The following files and folders are present within it:
The following files will aid in configuring your backend project:
-
The
package.jsonfile includes a number of scripts which may be useful for building your project. -
The
.env.samplefile includes the environment variables you will need to complete your project. This file should be copied to a.envfile and then the values should be replaced. -
The
knexfile.jsfile includes configuration details for your Knex installation. Keep in mind that your connection will only work if you define aDATABASE_URLwithin your.envfile.
The src/ directory includes two files and two directories.
The app.js and server.js file will aid in running your application. You will likely not need to make any edits to the server.js file, but you will need to make edits to the app.js file to add your routes and potentially other middleware.
The db/ directory contains a connection.js file. When you create migrations and seeds, they should appear within this directory under new directories with the same name.
The two files within this directory will handle errors for your server. They are both used within the app.js file.
In order to trigger the function within the errorHandler file, you will need to call the next() function within a route. An object should be passed into your next() function and should have the following shape, although the values should be replaced with appropriate error messages.
next({ status: 500, message: "Your error message" });The only automated tests for this project are within this directory.
The frontend/ directory contains a standard React application. Keep in mind that React Router is already installed and that the public/index.html file includes Bootstrap 5 and Bootstrap Icons.
The following requirements are not optional for this project. Some tests depend on these structures being in place.
The following two tables are required. You will also need to figure out some way to keep track of the ingredient quantity overall as well as each recipe's ingredients, which may require one or more additional tables.
Each account represents an individual using the web application.
Note: This project does not require you to implement authentication as part of its requirements. While you may add authentication at a later point, it is not essential to completing the project.
While you made include additional fields to this table, you must have the following fields.
| column name | data type | description |
|---|---|---|
id |
integer |
A unique ID for each account. |
name |
text |
A title for the account. |
username |
text |
A unique username that represents the account. |
Each list represents a collection of shows from the TVMaze API. Each list is associated with a user.
While you made include additional fields to this table, you must have the following fields.
| column name | data type | description |
|---|---|---|
id |
integer |
A unique ID for each list. |
title |
text |
The title of the list. |
account_id |
integer |
A foreign key the represents which account owns the list. |
You will need some way to store at least the IDs of shows from the TVMaze API. It is up to you to determine how you wish to store and access this data.
Your seed data should meet the following requirements:
-
Accounts: Include at least 2 accounts.
-
Lists: Each account should have at least 1 list. Each list should have at least 3 shows.
The tests utilize an in-memory SQLite database, while the development environment uses a PostgreSQL database. Ensure your seed file can handle both PostgreSQL (development) and SQLite (test) databases. The code should detect the database type and apply the appropriate commands for truncating tables and resetting primary keys.
Below is an example seed file that meets the above requirements and handles both PostgreSQL and SQLite databases:
/**
* @param { import("knex").Knex } knex
* @returns { Promise<void> }
*/
exports.seed = async function (knex) {
const isPostgres = knex.client.config.client === "pg";
if (isPostgres) {
// PostgreSQL specific: TRUNCATE TABLE with RESTART IDENTITY
await knex.raw("TRUNCATE TABLE accounts RESTART IDENTITY CASCADE");
} else {
// SQLite specific: DELETE all rows and reset the primary key sequence
await knex("accounts").del();
await knex.raw("DELETE FROM sqlite_sequence WHERE name = ?", ["accounts"]);
}
// ...
};Your API layer should be written in Express and connect to your SQL database using Knex. It should include these routes.
| HTTP method | path | description |
|---|---|---|
GET |
/accounts |
Returns all accounts within the database. |
GET |
/accounts/:accountId |
Returns a single account with the matching ID. |
POST |
/accounts |
Should create a new account and return that account with its ID. |
PUT |
/accounts/:accountId |
Updates an account based on the |
DELETE |
/accounts/:accountId |
Should delete the specified account. |
GET |
/lists |
Returns all lists within the database. |
GET |
/lists/:listId |
Returns a single list with the matching ID. |
POST |
/lists |
Should create a new list and return that list with its ID. |
PUT |
/lists/:listId |
Updates an list based on the |
DELETE |
/lists/:listId |
Should delete the specified list. |
Keep in mind that you may need additional routes to manage the process of adding and removing shows from lists.
Your requests and responses should include a data key before any data is sent to or from the server. For example, a response from the server to the GET /recipes route could look like the following:
{
data: [
{
id: 1,
name: "Stephanie Lee",
username: "stephanie.lee",
},
// ...
];
}If an error occurs, the data key should not be present. See the backend/src/errors/errorHandler.js to see how errors should be returned.
Your application should be written in React and should make requests to your API. It should have these screens.
| path | screen name | description |
|---|---|---|
/ |
Home | The home screen should show all lists created by all accounts. |
/accounts |
Accounts Index | This page should show all of the accounts. |
/accounts/:accountId/new |
New Account | This page should allow for the creation of a new account. |
/accounts/:accountId/edit |
Edit Account | This page should allow for an account to be edited. |
/lists/:listId |
Show List | This page should show details about a single list, including all shows. |
/lists/:listId/new |
New List | This page should allow for the creation of a new list. |
/lists/:listId/edit |
Edit List | This page should allow for a list to be edited. |
/lists/compare |
Compare Lists | This page should allow for multiple lists to be selected and display common shows between those lists. |
/shows?q=<search> |
Search Shows | This page should display all shows returned from the API based on a search term. |
/shows/:showId |
Show Show | This page should display details about a single show. |
As a user
I want to be able to see all lists created on the application
to navigate to a specific list.
- The homepage (i.e.,
/) displays all lists created in the web application. - Clicking on a list brings you to that list's show page.
As a user
I want to be able to search for shows
so that I can add them to a list.
- All pages should include a search bar in the header where a user can search for shows.
- Upon searching they should be brought to a page which includes the search term in the URL (e.g.,
/shows?q=<search>). - All shows which have a title that matches the search term can be pulled from the TVMaze API and displayed on the page.
- There is a specific endpoint for searching shows via the API.
- Clicking on a show brings the user to the specific page for that show.
As a user
I want to view a show's page
so that I can see detailed information about that show and add it to a list.
- The
/show/:showIdpage should display details about the show. - There should be a way on this page to add the show to any list in the application.
- If the show is already on the list, an error should display to the user.
As a user
I want to be able to create a new list
so that I can build a collection of shows.
- The
/lists/newpage should include a form that allows for the creation of new lists.- These lists do not need to include shows. Those can be added from the list's page.
- If the data entered within the form is invalid, an error message should be shown.
- When a list is successfully created, the user should be taken to that list's individual page.
As a user
I want to view a list's page
so that I can see detailed information about that list.
- The
/lists/:listIdpage should show the list with all of its information, including its associated shows and the account it is associated with. - Links should be present so that a user can click on a link to go to an account's page, and that when clicking on a show they go to that show's specific page.
As a user
I want to be able to remove a show from a list
so that I can keep my list updated.
- On the
/lists/:listIdpage, there should be a button or link that allows for an show to be removed. When that button is clicked, the relationship between the show and the list is removed from the database. - The page should visually update to show that the show has been removed.
As a user
I want to be able to edit an existing list
so that I can keep my list details updated.
- The
/lists/:listId/editpage should include a form that allows for the given list details to be updated. - If the data entered within the form is invalid, an error message should be shown. Each list must have a title and an account.
- When a list is successfully updated, the user should be taken to that list's individual page.
As a user
I want to be able to delete a list
so that I can clean up outdated information.
- On the
/lists/:listIdpage, there should be a button that allows for the list to be deleted.- Before the list is deleted, a message should appear that asks the user to confirm that they wish to delete the list.
- When the list is deleted, that record should be deleted from the database. If other records depend on the list (e.g., a row within a join table), those records should be deleted as well.
- When the list is deleted, the user should be brought to the
/page.
As a user
I want to view an account's page
so that I can see what lists that account has.
- The
/account/:accountIdpage should display details about the account, including the account's name and username. - The lists associated with the account should also be displayed on the page.
- Clicking on a list should bring you to that list's page.
As a user
I want to be able to create a new account
so that I can build a profile of lists.
- The
/accounts/newpage should include a form that allows for the creation of new accounts. - If the data entered within the form is invalid, an error message should be shown.
- When a account is successfully created, the user should be taken to that account's individual page.
As a user
I want to be able to edit an existing account
so that I can keep my account details updated.
- The
/accounts/:accountId/editpage should include a form that allows for the given account details to be updated. - If the data entered within the form is invalid, an error message should be shown.
- When a account is successfully updated, the user should be taken to that account's individual page.
As a user
I want to be able to delete an account
so that I can clean up outdated information.
- On the
/accounts/:accountIdpage, there should be a button that allows for the account to be deleted.- Before the account is deleted, a message should appear that asks the user to confirm that they wish to delete the account.
- When the account is deleted, that record should be deleted from the database. If other records depend on the account (e.g., a row within a join table), those records should be deleted as well.
- When the account is deleted, the user should be brought to the
/page.
As a user
I want to be able to compare two or more lists
so that I can see what shows those lists have in common.
- On the
/lists/comparepage a user should be able to first select an account and then select a list associated with that account. - The user should be able to select at least two of these lists.
- When two or more lists are selected, all of the common shows between those lists should be displayed to the user.
- If there are no matches, a message should be shown.
- Clicking on one of those shows should bring the user to the show's page.
| Time frame | Goals |
|---|---|
| Week 1, Mon-Tues | Go through the final capstone lessons. Understand the final capstone requirements. Plan out your project, creating a Kanban board and schedule for your final capstone project. Deploy your application. Design the schema and pages for your household members. |
| Week 1, Wed-Fri | Complete user stories 1 - 5. |
| Week 2, Mon-Wed | Re-deploy your application. Complete user stories 6 - 8. |
| Week 2, Thurs-Fri | Complete user stories 9 - 12. Re-deploy your application. |
| Week 3, Mon-Wed | Complete any remaining users stories. Re-deploy your application. |
| Week 3, Thurs-Fri | Complete your README file and clean up your code. Submit your project. |
When your final capstone project is graded, your grader will use the above acceptance criteria and this rubric to assess your work.
- Are all the tests passing?
- Are all business rules enforced in UI, API, and (if possible) the database?
- Do all API calls make use of an AbortController?
- Do all API calls abort without error in the UI or console (e.g. click a submit button multiple times very quickly)?
- Do all API calls in React handle errors and display the error message to the user?
- Do all uses of key= in React loops use a unique value from the entity (key is never the array index)?
- Are all functions calls using async/await wrapped in a valid asyncErrorBoundary or try/catch block?
- Note two things that the student could improve upon.
- Note two things that the student did well.
Your grader may leave additional feedback on your submission once it's reviewed.