nodejs代写 COMP 2406 Fall 2018 Assignment 4: API-based Express App

COMP 2406 Fall 2018

Assignment 4: API-based Express App

Due Date: Thu. Nov. 22 by 10:00pm in culearn


Assignment Revisions and Corrections will be noted here.

Rev 1 (2018 11 10) Just added a note to let people know that both tutorials 06 and 07 will helpful for this assignment, not just tutorial 06.


Node.js/Exress.js Recipe Server

The purpose of this assignment is to give you practice building a node.js application that accesses a public API, uses the express.js framework and uses client side javascript that manipulates the DOM (document object model) directly.

This assignment is is based on work in Tutorial 06 and 07 and accesses the food2fork public API. (If there is some other API you are keen to work with then discuss with me the possibility of substituting it for the recipe API instead.)

The components are:

Server build with just Node.js and the Express.js framework.

Public food2fork API.

Client side application page served by the server.

Client side javascript that manipulates the DOM (HTML elements) directly based on the data the client has requested from the server.

Client-Server data exchange should be based on JSON.

Assignment restrictions:

You are (finally) free to use express.js and whatever other npm modules you find useful though no other ones are necessary for the assignment.

Note: this, and other assignments, can be done in pairs if you want to work with a partner. Please submit one copy to culearn with both your names on it.


Marking: This assignment is based on 16 design requirements numbered R1.1R3.7 for a total of 32marks.

Marks are awarded, or deducted, based on itemized requirements as follows:

Req Type Marking
R0.x Assignment gets 0 if any critical submission
requirement (shown in red) is not met.
R0.x You lose 2 marks for each good practice
requirement (shown in amber) not met.
R0.x You earn 2 marks for each design requirement (green) satisfied and well implemented; 1 mark if it’s partly met or met but not well implemented; and 0 if it’s not met.

Submission and Good Programming Practice Requirements

The following requirements pertain to all your assignments regardless of what your application is supposed to do (i.e. regardless of the design requirements). These requirements are to ensure that your code is usable, readable, and maintainable.

R0.0 UNIQUENESS REQUIREMENT. The solution and code you submit MUST be unique. That is, it cannot be a copy of, or be too similar to, someone else’s code, or other code found elsewhere. You are, however, free to use any code posted on our course website as part of our assignment solution. [Assigment mark =0 if this requirement is not met.]

R0.1 CODE SUBMISSION ORGANIZATION AND COMPILATION: You should submit all the code files and data files necessary to compile and run your app. The TA’s will execute your app with node app.jscommand unless alternative instructions are provided in the README.txt file. If you compress your submission to culearn you must use only .zip format (not .rar or .tar or whatever). Though you are permitted to write code on Windows, Linux, or Mac OS the code should be generic enough to be OS agnostic. Your code must work with at least a current Chrome browser. [Assigment mark =0 if this requirement is not met.]

R0.2 README FILE: Your submission MUST include a README.txt file telling the TA how to setup and run your app. The TA should not have to look into your code to figure out how to start up your app. Your README.txt MUST contain the following:

    • Your name, student number and email address and if you are working with a partner then their name, student number and email address as well.

    • Version: node.js version number and OS you tested on your code on.

    • Install: how to install needed code. This will likely look like npm install or npm install module_name

    • Launch: Instructions on how to launch your app. e.g. node myserver.js. As the course progresses there will be more launch options to it’s important to provide instructions.

    • Testing: Provide Instructions on what the TA should do to run your app. e.g. visit http://localhost:3000/mytest.html?name=Louis. If your app requires a userid/password to run then provide one for the TA to use. Your server should print to the console the URL’s that should be visited by the browser to demonstrate your app. List them in the order you want us to visit them:

    • Issues: List any issues that you want the marker to be aware of. In particular, tell us what requirements you did not implement or that you know are not working correctly in the submitted code. Here you are giving us your own assessment of your app.

Pay attention to any specific URL’s that must be supported by your app. [Assigment mark =0 if this requirement is not met.]

R0.3 VARIABLE AND FUNCTION NAMES: All of your variables and functions should have meaningful names that reflect their purpose. Don’t follow the convention common in math courses where they say things like: “let x be the number of customers and let y be the number of products…”. Instead call your variables numberOfCustomers or numberOfProducts. Your program should not have any variables called “x” unless there is a good reason for them to be called “x”. (One exception: It’s OK to call simple for-loop counters i,j and k etc. when the context is clear and VERY localized.) Remember javascript variables don’t have types which can help clarify things so choosing good names is even more important. Many functions in javascript are annonymous (have no name) and so the name of the variable that refers to them is even more important. [Minus 2 marks from assignment if this requirement is not met.]

R0.4 COMMENTS: Comments in your code must coincide with what the code actually does. It is a very common bug to modify code and forget to modify the comments and so you end up with comments that say one thing and code that actually does another. By the way, try not to over-comment your code but instead choose good variable names and function names that make the code more self commenting. Don’t be afraid to create local variables so that the variable name provides more clarity. [Minus 2 marks from assignment if this requirement is not met.]

R0.5 CITATION REQUIREMENT: If you use code from other sources you should cite the source in comments that appear with the code. If the source is an internet website then put the URL in the comments. You may use bits of code from outside sources but this may not form the complete solution you are handing in.You DON’T have to cite demo code we provide on the course web site or with tutorials and assignments, however that code should not be used for things you post publicly (like on GitHub). [Minus 2 marks from assignment if this requirement is not met.]

VERY IMPORTANT: Any sample code fragments provided may have bugs (although none are put there intentionally). You must be prepared to find errors in the requirements and sample code. Please report errors so they can be fixed and an assignment revision posted.


Application Requirements

Background

Public API’s (often referred to as RESTful API’s) have become very popular. They typically serve JSON data based on client HTTP queries. They also respect the stateless nature of HTTP -the client provides everything in each query that the server needs to respond. API’s don’t typically serve web-pages rather they serve XML or JSON data that other servers or “smart” clients can use to populate web pages. Or, in the internet of things, maybe no web pages are ever involved. API’s are nice because their data can be consumed and repackaged in many different ways (browsers, mobile apps, IoT devices).

We want to build a client-server app that uses the www.food2fork API for providing recipes based on ingredients specfied by the client. (If you want to substitute a different API in the assignment please discuss it with me ahead of time.)

The client should access the application at http://localhost:3000/recipes and they should be presented with a webpage that looks like the following:

pics

 

Application Requirements

1) Server-Side Requirements

R1.1 The server should be built as an Express.js application. It could be a very simple or minimal express app or use many express features -no particular complexity is specified.

R1.2 The server application should make use of a package.json file to specify all the npm modules needed by your app (possibly only express.js) The marker should be able to install all the module by executing npm install. DO NOT submit installed npm modules with your assignment. We want to install those ourselves and keep the submitted code size small. In other words, don’t submit your node_modules directory with your code.

R1.3 Your package.json file should list specific version numbers of the modules you install. Don’t have it install “the latest” modules. You must be specific about the version number. You may use the optimitic version numbering if you want (i.e. the version number with the ^ character in front of it.)

R1.4 With Express.js and package.json comes new ways of launching your server app. Up until now we have always lauched with the command node server.js. Make sure your README.txt file tells us exactly how to launch your app; the marker will not be expected to try and figure it out. Also include the instructions for installing the npm modules you need in your README.txt file.

R1.5 The server should obtain recipe data from the www.food2fork public API. You server code should already contain the required APP ID which you need to obtain from www.food2fork. That is, hard-code your API key in your server so we can just run the code and not have to substitute other keys. (We promise not to abuse your key.)

R1.6 When asked, the Server should provide its clients with recipe data in the form of a JSON object string. (The request could be either a GET or POST request depending on how you organize your application.)

R1.7 If your server needs to serve static files to the client then it should provide a static server using the express use(express.static …) middleware. If your application does not require a static server part then you don’t need to provide this.

R1.8 The amount of data served by the server should be reasonable. (If the food2fork queries provide too much data the server should reduce it to a reasonable amount before sending the response to the client).Thus the client can be coded to render all the data provided by the server. Currently the API seems to serve 30 recipes by default. That is fine and you don’t need to reduce that further.

 

2) Client-Server Data Exchange

R2.1 The recipe data exchanged between client and server should be in the form of JSON object strings. (The initial launch of the app will just be the result of a GET request for the app’s web page).

 

3) Client Requirements

R3.1 The client should be able to reach the app at any of the following URL’s
http://localhost:3000/recipes.html
http://localhost:3000/recipes
http://localhost:3000/index.html
http://localhost:3000/
http://localhost:3000

That is, all those routes should amount to the same thing. Here you need to figure out the best way to handle multiple URL’s that should resolve to the the same result. The specific set of recipes displayed, if any, as a result of visiting these URL’s is up to you (unlike the next requirement R3.2).

R3.2 The client should be able to start the app with http://localhost:3000/recipes?ingredients=Basil,Cumin in which case the recipes shown would be those obtained from food2fork that include those ingredients. The purpose of this requirement is to have a convenience feature where the client can launch the app with an intial set of recipes based on the query parameter ingredients.

R3.3 When the client types an ingredient into the labelled text box and presses the “submit” button (or whatever you want to call it) then a page should be refreshed with new recipe data obtained from the server.

R3.4 A application should allow the user to enter a single ingredient or a list of comma-separated ingredients when requesting recipe data. (Food2Fork accepts comma separated ingredients so there is no special processing required with regard to using the API.)

R3.5 The client side javascript should use the JSON recipe data obtained from the server and modify the application web page by manipulating the DOM. That is, add or remove the appropriate HTML elements using client-side javascript (either using native javascript or jQuery).

R3.6 The client web page should show the recipe images as shown above or layed out in some other well organized way.

R3.7 The recipe images or recipe names should be active links. If the user clicks on one the browser should open the food2fork.com page for that recipe in a new tab. (You will need to research how to specify a new browser tab -but it’s not hard.)

Here is a short video demonstration of how the app might work.