Description
Problem 1: Convert the web server to use the database
The webServer.js we give you in this project is like the Project #5 webServer.js in that the app’s model fetching routes use the magic cs142models rather than a database. Your job is to convert all the routes to use the MongoDB database. There should be no accesses to cs142models in your code and your app should work without the line:
in webServer.js . Note that any console.log statements in webServer.js will print to the terminal rather than the browser.
Web Server API
As in Project #5 the web server will return JSON encoded model data in response to HTTP GET requests to speci c URLs. We provide the following speci cation of what URLs need to be support and what they should return. Your web server should support the following model fetching API:
/test – Return the schema info ( /test/info ) and object counts ( /test/counts ) of the database. This interface is for testing and as an example for you we provide an implementation that fetches the information from the database. You will not have to change this one.
/user/list – Return the list of users model appropriate for the navigation sidebar list. Since we anticipate large numbers of users, this API should only return an array of user properties needed by the navigation side bar ( _id, first_name, last_name ). It replaces the cs142models.userListModel() call in the provided code.
/user/:id – Return the detail information of the user with ID of id. This should return the information we have on the user for the detail view ( _id, first_name, last_name, location, description, occupation ) and replaces the cs142models.userModel() call. If some thing other than the id of a User is provided the response should be an HTTP status of 400 and an informative message.
/photosOfUser/:id – Return the photos of the user with _id of id. This call generates all the model data needed for the photos view including all the photos of the user as well as the comments on the photos. The photos properties should be ( _id, user_id, comments, file_name, date_time ) and the comments array elements should have ( comment, date_time, _id, user ) and only the minimum user object information ( _id, first_name, last_name ). This replaces the
cs142models.photoOfUserModel() call. If some thing other than the id of a User is provided the response should be an HTTP status of 400 and an informative
message. Note this API will take some assembling from multiple di erent objects in the database. The assignment’s package.json le fetches the async (https://github.com/caolan/async/blob/v1.5.2/README.md) module to make the assembling the multiple photos easier.
To help you make sure your web server conforms to the proper API we provide a test suite in the sub-directory test . Please make sure that all of the tests in the suite pass before submitting. See the Testing section below for details.
Your GET requests do not return exactly the same thing that the cs142models functions return but they do need to return the information needed by your app so that the model data of each view can be displayed with a single FetchModel call. You will need to do subsetting and/or augmentation of the objects coming from the database to build your response to meet the needs of the UI. For this assignment you are not allow to alter the database schema in anyway.
(http://mongoosejs.com/docs/models.html) from the objects stored in MongoDB while the request itself should return the data models needed by the Photo App views. Unfortunately since the Mongoose models are set by the database schema and front end models are set by the needs of the UI views they don’t align perfectly. Handling these requests will require processing to assemble the model needed by the front end from the Mongoose models returned from the database.
Care needs to be taken when doing this processing since the models returned by Mongoose are JavaScript objects but have special processing done on them so that any modi cations that do not match the declared schema are tossed. This means that simply updating a Mongoose model to have the properties expected by the front end doesn’t work as expected. One way to work around this is to create a copy of the Mongoose model object. A simple way of doing the copy is to translate the model into JSON and back to an JavaScript objects. The following code fragment does this object cloning:
by taking modelObject converting into a JSON string and then converting it back to a JavaScript object, this time without the methods and special handling done on Mongoose models.
Problem 2: Convert your app to use axios
In preparation for the next assignment where we will use more of the REST API convert your photo app to use axios rather than your own FetchModel routine to fetch the models from the web server. Axios (https://github.com/axios/axios) is one of the many npm packages available for fetching data. It is faster and has more functionality than our FetchModel function, and it is what we will use to make our requests going forward. Your photo app should work without the FetchModel function de nition after nishing this problem. The functionality of your app should be exactly the same before and after removing the FetchModel function de nition — make sure you do not break anything in the process of making this switch.
In particular, any time you call FetchModel in photoShare.jsx or your other components, you should replace it with a call to axios.get . See the axios documentation (https://github.com/axios/axios) for more details.
Notice that axios.get returns a Promise, much like FetchModel . We can attach success and failure handlers using .then and .catch respectively. You shouldn’t have to change the logic of your handlers from FetchModel , very much, or at all, when attaching them to axios.get .
