Developing the Playlister App

HW 3: 3rd Technology Learning Assignment - Full-Stack Web App Development

In this assignment we'll again make the Playlister application but now we'll be adding a back-end, which means a Mongo database that we'll communicate with using the Mongoose ODM and we'll build a back-end API using Express. On the front-end we'll manage the application's state using the Context and Hooks APIs and we'll send http requests to the back-end API from our React application using Axios. So there are lots of new technologies that we'll be using but don't let that worry you, each of these tools makes our life easier than what we would have used in the past for doing such things. Note, we are not using NextJS at this time. We'll leave that for HW 4.

Note that it is important that you know how the pieces fit together before you start, so make sure you look through all the code I am providing you first and understand how it works. You may also wish to review the following before getting started:

http - a nice introduction from the Mozilla Developers Network.
How to create your first MERN Stack by Sam Barros - a nice introduction to the tutorials we are using in this assignment. It will guide you through routing on both the server and client sides as well as how to send and receive http requests.
Using React's Context API for Global State Management - this article introduces the Flux design pattern, which we'll make use for managing our application's state in a global store using Context and Hooks.

Setup

We'll again use Visual Studio Code and GitHub and make an application for the Node platform. To get started with this this assignment, do the following:

Create a local directory called 316-HW3-Playlister on your computer where you will do your work for HW 3.
Clone the provided 316-HW3-Playlister repository into your 316-HW3-Playlister directory by typing:
git clone https://github.com/TheMcKillaGorilla/316-HW3-Playlister .
Download and Install MongoDB's Community Server, which we'll run locally. If going to that URL gives you a 403 error, try it in private or Incognito mode. Note that once you're writing code you're going to need Mongo running. I like to start it and let it keep running while I do all of my work. So, once it's installed, start it and you should see the Compass view, which lets you view the contents of your databases, which we haven't yet created. Note, Mongo Compass should come with your MongoDB download, but in case it doesn't you can download and install it separately. This will provide a GUI view of your database.
Now we need to create a database. To do this, open Mongo Compass and press Create Database. Name your database playlister. This is what our application will connect to. You need to be careful to name it precisely as our db object will connect to it using this name. Inside your database, Create a Collection named playlists. Then, in the project, look inside the test directory inside server and you'll find a file named mckenna-playlists.json. This contains the example data we've been playing around with. Note, you will need to make your own test data file like this with different data per the instructions in the requirements section of this assignment. For now, let's just import this data into the database. To do this, from within Mongo Compass, you can select your database and click on Add Data and then Import JSON or CSV file and and select this file. The data in this file should now appear in your collection. Throughout your development process you will need to load test data and observe it in Compass as it changes and then remove all playlists to reset things and start all over again.
Almost time to start our application. Note that in this assignment we are making two applications, a client and a server. For this you should have two Terminals in VSC. In your first Terminal, go to the client directory by typing cd client. Create a second Terminal and go to the server directory by typing cd server.
We will use a process manager called nodemon for our server application so that we don't have to keep stopping, saving, and restarting our server every time we make changes during our development process. For this we'll use nodemon. First you'll need to install it in your server Terminal using npm install -g nodemon.
Now let's run the server. In your server Terminal window, make sure you are in your server directory, where package.json is located, and type npm install to make sure all the proper node modules are installed for your server application. Then, to start the server, type nodemon index.js. Again, nodemon is a process manager that will start your server and will keep it running and reloaded after each time you edit and save server code. Your server should start up and will be listening for connections on port 4000. Note that we need to make sure our client and server applications use different ports.
Now let's run the client. In your client Terminal window, make sure you are in your client directory, where package.json is located, and type npm install to make sure all the proper node modules are installed for your client application. Yes, this means our project (which is really 2 projects), will use two separate node_modules directories, one in client and one in server. To start your client, type npm start. Note that this should start a React web server on port 3000. Again, we need to make sure this is a different port from the back-server, which used 4000.
When the app opens in the browser you'll find that it is a partially working Playlister app. But this time we're not getting/setting things from/to local storage but instead a Mongo Database by sending/receiving requests to/from a back-end Express server. This is a significant difference. Also, the UI is not exactly like what we did in HWs 1 & 2, for example, there is no more sidebar, we're not duplicating anything, we've changed the name editing process, etc., but it's very similar, and since we loaded the data into our database already, the playlists from the test file should appear in your view. Play around with the application for a bit to see what does and does not work.
Let's think first about our back-end, which many times is made in parallel to the front-end or may even be made by a completely different developement team (or entity) altogether. Download and install the Postman application, which we'll use for testing our back-end API. This program creates http requests and sends them to our server for it to handle and then send back responses, which we can see inside Postman.
Next we need to setup Postman to test your back-end API. This means creating a number of test requests to make sure your database is working properly. If you look inside server/test directory of our Playlister project you'll find a file named postman-test-requests.json, which contains requests that Postman can use for testing your back-end application by sending http requests and displaying what is sent back. Note, in order to do this your server application would have to be running. To make use of these requests, in Postman, click on Import and then select files. You should then browse to your server directory and select the aformentioned test file. This will load our collection of Playlister requests. Notice the requests are organized in the following folders:
- Create Playlist - this contains three requests, one for each of our initial test playlists. You'll need to make three more with your own playlists. Note, you should be able to run these requests and they should work, as the back-end API route for this request is defined and the controller function for this request is implemented.
- Read Playlist - this contains three requests, one for each of our initial test playlists but note that the ids used by these requests will not work for you as it would depend on what id was assigned by Mongo when each playlist was created in your database. You will need to update the id each time it is created. If you do so, these requests should work as the back-end API route for this request is defined and the controller function for this request. Note, you will need to add three more, one for each of your own playlists.
- Update Playlist - this folder is empty as both the back-end API route and controller code for this request are not implemented. You will need to create these requests to test various updates.
- Delete Playlist - this folder is also empty as both the back-end API route and controller code for this request are not implemented. Again, you will need to create these requests to test various playlist deletions.
- Read Playlist Pairs - this contains one request which already works and should not be changed. You should be able to run this request and see the results.
- Query Playlists - this folder is empty but you will add requests for testing various mechanisms for searching the database playlists.
Note in this assignment you will not need to change any CSS or any render functions. Leave those as they are. You will really need to focus your efforts on five things:
1. In server: back-end server routing
2. In server: back-end server controller functions
3. In client: request generation (in store and requests)
4. In client: client state management (in store)
5. In test: test data and test requests
Make sure you have Version Control setup from the beginning. It is important that you get used to using Git throughout the development process. Every significant working change that you make should correspond with a commit to your GitHub repo.

The Playlister App - Requirements

When you run the application you'll notice that it loads and displays what lists are in the database, lets the user load/view a list and close a loaded list. There's an edit button for each list that lets you edit the name but when you hit ENTER you're back to the same old name. When you double click on a song an edit screen opens but your changes are not applied. You can drag and drop songs but they are not applied either. This is where you come in. Note that in order to get everything to work you'll need to first make sure you understand how the application currently works, especially data management in the data store. The good news in this assignment is you don't need to change any components. Add the necessary code to do the following:

Create Three Test Lists - you may name them anything you like. Note, you'll need to put them in a separate JSON file similar to the provided mckenna-playlists.json but instead called netid-playlists.json, where netid if your NetId. Use a similar format to the one provided. Your playlists should be:
- Old Songs you Like - we want varied data so make a playlist with at least 20 songs from all different eras and years.
- Your Favorite Songs - make another list with your favorite 20 songs ever.
- Songs you find Interesting or Unusual - when we combine all student lists together we want a varied set of songs, so provide a list with at least 20 songs you find interesting that you suspect others may have never heard.
Define Postman Test Requests - as you'll be defining back-end code, before doing you should specify Postman requests to test them. It is common practice to define how you will test something before implementing it. Implement the following requests:
- 3 Create Requests, one for each of your playlists
- 3 Read Requests, one for each of your playlists
- Multiple Update Requests, at least one each for:
  - changing the name of a playlist
  - adding a song to a playlist
  - moving a song in a playlist
  - changing a song (one or more of title, artist, year, youTubeId) in a playlist
  - removing a song in a playlist
- 1 Delete Request, just make this simple, we can simply change the Postman request to use which ever playlist id we want each time.
- Multiple Query Playlists, at least one for:
  - getting all the playlists that start with a specific string
  - getting all the songs in all the playlists with no duplicates where a song has a specific one or more title, artist, and year
Implement New Endpoints - Note that you'll need to implement new endpoints on the server for all of the aforementioned requests. You may name your name/route your endpoints as you like but the names should be obvious. So this inclueds:
- Updating a playlist - could be changing the playlist name or the songs
- Deleting a playlist
- Getting Playlists that Start With (note, we are not using this in the client, it can only be tested via Postman)
- Get All Songs with No Duplicates that Meet Criteria (note, we are not using this in the client, it can only be tested via Postman)
Client Functionality - you will need to update the data store and request sender such that the client application now works properly. This includes:
- Renaming a List
- Deleting a List
- Adding a Song
- Editing a Song
- Moving a Song
- Removing a Song
Undo/Redo - all playlist editing should be undoable/redoable. Note, this is already implemented but don't break it.
Edits Saved to Database - note that all edits should be immediately saved to the database on the back end.
Foolproof Design - make sure the buttons are disabled when not usable. This should already be implemented, don't break it.

Handin Instructions

When you are done, zip up your entire project, but do not include the node_modules directory. Then submit that single ZIP file via Brightspace. Note, it must be a .zip file, not a .rar file. Remember, if you include the node_modules directory it is a 5 point deduction.

Grading

Note that grading will be based on program performance and will only be done by appointment with each student's prescribed Teaching Assistant. This part of your grade will be based on how well your program performs specific required tasks and you must use Version Control throughout.