COMP2406代写、代写Java，Python程序

日期：2022-04-11 11:22

COMP2406 Assignment 4 – Community

fridge web application with MongoDB

This assignment mostly focuses on content from Weeks 10-12 of class.

In the past three assignments, we have been building various parts of a community

fridge web application. In Assignment 1, we built the client-side functionality of the

application, to allow users to browse the list of fridges, browse items in a fridge, and

pickup items from a fridge. In Assignment 2, we built the server-side component of

the web application. Specifically, we created a Node.js server to serve all the

resources associated with the application (e.g., HTML, CSS, JavaScript, CSS, and

JSON). In addition to this, we also added persistence in our application. In

Assignment 3, we further built the assignment in Express, specifically focusing on

building a REST API.

In this assignment, we will connect our Express application to a MongoDB database.

This involves moving all of the data from our JSON files into the MongoDB

database and performing queries on this data.

This assignment should be completed individually. It must be completed using

Node.js, Express, and MongoDB/Mongoose.

Starting code

We have provided the solution for Part 1 of assignment 3 as starting code for this

assignment. If you were unable to fully complete assignment 3, you can use the

provided solution as a starting point for this assignment. We made some slight

changes to the Express routes from A3, so if you would like to use your own

Assignment 3, please make the required changes. These changes are highlighted in

the specification by the marker [***updated].

All of the application resources should be placed on the Node.js web server. You

should not save any resources on the client-side. With regards to resources, we

mean all assets associated with the application such as HTML files, CSS files,

JavaScript files, images, and any other such assets used by your web application.

All data associated with the application should be stored in a MongoDB database

as specified in the following sections. Questions that are implemented without

utilizing the database will receive a mark of 0. For example, if any of the JSON files

are updated instead of the database, a mark of 0 will be given for that question.

Similarly, the solution must be implemented using a REST API created in

Assignment 3. This API must be updated with the necessary changes required for

this assignment.

Requirements

The primary requirements of the assignment involve implementing a database for

our Express application. All routes will implemented on the server-side and tested

using Post-man. You do not need to implement the client-side HTML/JavaScript

code associated with the routes. However, there is a bonus question, which

involves implementing a client-side component of the "Search feature". As this is a

bonus, it is optional for the assignment. It is meant for those who would like more

practice working with the client-side code.

Part 1: Setting up a database

Begin by setting up your MongoAtlas cloud database account as explained in the

lectures. We also used this account in Tutorial 9. If you did not get a chance to

complete the tutorial, please watch the "Setting up a MongoDB Cloud account"

video from week 10. We recommend you complete this step well in advance of

completing the assignment, as not being able to setup the account will hinder your

ability to successfully complete the assignment.

As shown in the lectures, your code should have a config.js file, which includes the

connection information for your MongoDB database.

You must update the following information in the file to correspond to your

assignment setup:

• username: update the value in this variable to your MongoDB username

• password: update the value in this variable to your MongoDB password

• dbname: update the dbname to community-fridge-stdnumber", where

stdnumber is equal to your student number. For example, if your student

number is 100978291, then the value of the dbname variable should be

"community-fridge-100978291"

Failure to update any of these values correctly will result in a mark of 0 for the

assignment. The TAs need to be able to execute the code for a large number of

students and completing this part incorrectly will affect their ability to mark the

assignment in a timely manner.

NOTE: when you make changes to the database, you must "refresh" the MongoDB

Atlas page to see the new changes. Similarly, you must restart the Node.js server

anytime you make changes to your server-side code.

Part 2: Creating database schemas (6-marks)

Once the MongoDB database is setup, you need to use Mongoose to create three

schemas for your database. These schemas will be used to add elements into the

database. Specifically, the database should have the following three schemas:

1. Fridges: specifies the structure of the data associated with a fridge

2. Items: specifies the structure of the data associated with an Item

3. Types: specifies the structure of the data associated with a type

Remember, that schemas in Mongoose are used to create Models, which are used

to add documents (i.e., rows) into your database. Thus, each schema will correspond

to a collection in the database.

2.1: Creating a database schema for Fridges

The following are the schema requirements for a fridge and this schema should be

stored in a file called fridgeModel.js

• id: stores a unique ID for the fridge (e.g., fg-1). The type for the id should be a

String and it is a required field with a minimum length of 4 and a maximum

length of 6.

• name: stores the name of the fridge. The type for the name should be a String.

It is a required field with a reasonable minimum and maximum length. The

minimum and maximums must be implemented using the built-in scheme

validation in Mongoose.

• numItemsAccepted: indicates the number of items accepted by the fridge. It

should be a number and have a default value of 0.

• canAcceptItems: indicates the maximum number of items that the fridge can

accept. It is a required field and should have a minimum value of 1 and a

maximum value of 100. The minimum and maximums must be implemented

using the built-in scheme validation in Mongoose.

• [***updated] contactInfo: specifies the contact info for a fridge. It should be

an object consisting of two properties: contactPerson and contactPhone. The

type of both of these properties should be a String. As you can see from the

comm-fridge-data.json file, the structure of this field has been modified

compared to previous assignments. Please update this field in your code if not

using the starter-code.

• address: specifies the address information for a fridge. It is a required object

with the following five fields{

street: type of String

postalCode: type of String

city: type of String

province: type of String,

country: type of String

• [***updated] acceptedTypes: an array indicating the types of items accepted

by the fridge. This field is required. The types of items accepted in previous

assignments included a name (e.g., dairy, produce). We will now create a types

collection, which will store all of the types available in our application. So, the

acceptedTypes array now will have a list of ids instead of the names of the

types (e.g., 839201, 1801920).

• items: an array of item objects. Each item object has two properties: id and

quantity. The id of the item in the array must correspond to its id in the items

collection. The quantity field should be a number.

2.2: Creating a database schema for Items

Create a schema for an Item. Specifically, the item schema should be stored in a file

called itemModel.js and must have the following fields:

• id: stores a unique ID for the item (e.g., 1). The type for the id should be a

String and it is a required field with a minimum length of 1 and a maximum

length of 4.

• name: a required field, which stores the name of the item. It should be of type

String and have a reasonable minimum and maximum length. The minimum

and maximums must be implemented using the built-in scheme validation in

Mongoose.

• type: a required field, which stores the type of the item. The type of the item

should be an id which corresponds to an id in the "types" collection.

• img: a required field, which stores the path to an image. It should be of type

String and have a reasonable minimum and maximum length. The minimum

and maximums must be implemented using the built-in scheme validation in

Mongoose.

2.3: Creating a database schema for Types

Create a schema for the type of an item. This schema should be stored in the a file

called typeModel.js, and it should have the following field:

• id: stores a unique ID for the item type (e.g., 1). The id should be a String and it

is a required field with a minimum length of 1 and a maximum length of 4.

• name: a required field, which stores the name of the type (e.g., dairy, produce).

It has a type of String and a reasonable minimum and maximum length. The

minimum and maximums must be implemented using the built-in scheme

validation in Mongoose.

2.4: Populating the database with data from the JSON files (already completed for

you)

Once the schemas are created, we will need to use them to initialize our database

with contents from the comm-fridge-data.json, comm-fridge-items.json, and commfridge-types.json

files. This part has already been completed for you.

Part 3: Creating database queries (94-marks)

Once the database is created and initialized with data from the JSON files, you will

write queries for creating, retrieving, updating, and deleting data for the community

fridge application. The queries must be integrated with routes in Express. Some of

this will involve updating the existing Express routes created in Assignment 3, and

others will involve creating new routes. Details on each are provided below.

3.1 Updating existing express routes (54-marks)

When updating the existing Express routes from Assignment 3, the goal is to modify

the code so that the CRUD operations on the data are performed on the MongoDB

database, instead of the underlying JSON files. None of your code should update

the JSON files. If a route is completed by updating the JSON files, then you will

receive 0 for that question. In addition to modifying the routes, you will also need

to add additional validation on the data to ensure that it meets the schema

requirements.

1. Retrieving information for all fridges: when a GET request with the URL

/fridges is received AND the content-type requested by the client is JSON,

then the server should perform a query on the Fridges collection of the

database, and respond with the data associated with all of the fridges in the

application.

2. Retrieving data associated with a specific fridge: when a GET request with

the parameterized URL /fridges:/fridgeID is received, then the server should

query the Fridges collection of the database, and respond with all of the data

associated with the fridge with the fridgeID. A 404 error should be returned if

the fridgeID does not exist.

3. Adding a new fridge: when a POST request with the URL /fridges is received,

the server should add a new fridge in the Fridges collection of the database.

Information provided in the body of the POST request should be used to

perform the addition. If the body of the POST request does not meet the

Fridge schema, then a 400 error message should be returned. Otherwise, the

fridge should be successfully added and 200 should be returned with

information about the new fridge in the response body.

An example of a POST body which violates the Fridge schema is: {"name": "StLaurent

fridge}, because it is missing some required fields.

4. Updating information about a fridge: when a PUT request with the

parameterized URL /fridges/:fridgeID is received, the server should update the

information for the specified fridge in the Fridges collection of the database.

The information to be updated should be provided in the body of the PUT

request. The body of the PUT request should only contain information which

was updated. The body of the PUT request should adhere to the requirements

of the Fridge schema. Any violations of the schema should result in a 400

error.

An example of a valid PUT request is: {"canAcceptItems": 50}

5. [***updated] Adding an item in the fridge: when a POST request with the

parameterized URL /fridges/:fridgeID/items is received, the server should add

an item into the specified fridge in the database. At minimum, the body of the

POST request should contain information for all of the required item fields. If

the item already exists in the fridge, then a 409 error message should be

returned to indicate duplicates. The body of the POST request should adhere

to the requirements of the Fridge schema. Any violations of the schema

should result in a 400 error.

6. [***updated] Deleting an item from a fridge: when a DELETE request with the

parameterized URL /fridges/:fridgeID/items/:itemID is received, the server

should remove the specified item from the fridge in the database. In

Assignment 3, this was addressed using various approaches (e.g., reducing the

quantity of the item by 1 or deleting the item). When implementing this using

a database, the easiest option would be to completely delete the item

regardless of the quantity, which is the requirement here. Decreasing the

quantity of the item would be considered an update, and should be done using

a PUT request instead. We have provided a new route for it in this

assignment. If you had alternate implementation for this in Assignment 3,

please make the necessary adjustments to it for Assignment 4. You can review

the solutions to see how to complete this route for Assignment 3. The input

validation requirements for this route are the same as in Assignment 3,

specifically that the fridgeID and itemID must exist before a delete can be

successful. If either the fridgeID or itemID does not exist, a 404 error should

be returned.

7. [***updated] Delete a list of items from a fridge: when a DELETE request with

a query string is received for the URL /fridges/:fridgeID/items, the server

should remove the list of items from the fridge database, as specified in the

query string. For example, if the query string

/fridges/:fridgeID/items?item=itemId1&item=itemId2 is received, then item1

and item2 should be removed from the fridge if they exist inside the fridge

specified in the URL (e.g., fridgeID). If a query string is not provided, then ALL

OF the items from the specified fridge should be removed. This requirement is

slightly updated from Assignment 3, so please make the necessary

adjustments to your code or use the provided solution. If the fridgeID or any

of the itemIDs doesn’t exist, then an error code of 404 should be returned

with an error message.

3.2 Creating new express routes (40-marks)

In this section, you will create some new routes for the Express application to add

additional functionality into the community fridge application.

1. Updating the quantity of an item in the fridge: when a PUT request with the

parameterized URL /fridges/:fridgeID/items/:itemID is received, the server

should update the item quantity for the specified fridge in the database. The

updated quantity information should be provided in the body of the PUT

request. Before performing the update, the route must check that the fridgeID

exists, and the itemID exists inside the fridge. If these requirements are met,

then the update should proceed. Upon a successful update, the server should

return a status of 200 with the updated item in the response's body. If either

of the IDs do not exist, then an error of 404 should be returned.

2. Adding a new item into the items collection: this route concerns adding to the

items model/collection and NOT adding an item to a fridge. Thus, this route is

different from Part 3.1.5. When a POST request for the route /items is

received, the server should add a new item into the Items collection in the

database using the information provided in the body of the POST request. The

item should only be added if it is not a duplicate. Specifically, if the item has

the same name as another item in the Items collection, then a 409 error

should be returned. In addition, the body of the POST request must meet the

Item schema. Any violations should result in a 400 error. If the item is not a

duplicate and meets the Item scheme, then the item should successfully be

added into the Items collection. A 200 code should be returned with the new

item in the response body.

3. Search for an item in the items collection: when a GET request with a query

string is received for the route /search/items?type=""&name="", the server

should return a list of items from the items collection which match the query

parameters. For example, if the following route was received:

/search/items?type=dairy&name=milk, then the server should return a list of

items from the items collection that have a type of dairy and contains milk in

their name. If an improperly formatted query string is received, then a 400

error should be returned.

Bonus: Client-side application (5-marks)

In this assignment, there are no requirements to connect the routes in Part 3 to a

client-side application. However, we have included a bonus question for those who

would like to implement a client-side component for the new search route specified

in Part 3.2.3.

Specifically, as a bonus question, implement a "Search" screen which includes the

following UI elements:

• Two textboxes for the query: one labelled "type" and the other labelled

"name". These allow the user to specify the values of the type and name query

parameters.

• A submit button: this allows the user to execute the query. This button should

be labelled as "Search".

When the submit button is pressed, the values provided by the user in the

textboxes should be used to form a URL which matches the route in Part 3.2.3. An

AJAX request should be sent to the server to execute the search query. Results

from the search, namely the item data can be displayed in the browser's console or

in the "Search" screen.

Submission

Submit your code as one .zip file which contains the following:

1. A Readme text file which includes:

. your name

a. your student number

b. brief description of the contents of the .zip file

c. any relevant instructions for running your code

2. You must also check that the config.js file is created according the

specification provided.

To submit your assignment, please zip all of your files for the assignment and

submit the zip file on Brightspace. This .zip file should be named as

follows: “COMP2406_A4_firstname.zip”. Make sure you download the zip after

submitting and verify that the file contents are correct and your instructions are

sufficient to install/run your solution.

Marking Scheme

/0 Part 1

/6 Part 2

/94 Part 3

Due Date

Apr 12, 2022 11:55 PM