Server-Side / Client-Side Programming Assignment

Summative Assessment Programming Assignment 2 Server-Side Programming Outline • Components marked: Code, Documentation, Video Submission Source code (all zipped in a directory with correct file structure): 1. README.txt with execution instructions 2. HTML and CSS and any media 3. Client and server-side JavaScript 4. package.json including test and pretest scripts 5. the file .eslintrc 6. jest test cases e.g., app.test.js 7. documentation of API 8. demonstration video Note: You should not include the directory node_modules in submission Subject-specific Knowledge • A knowledge and understanding of good programming practice (for example, reuse, docu- mentation and style) • Building collections of data within a program and using JavaScript Object Notation (JSON) • Making programs robust through the use of exceptions and exception handling • A knowledge and understanding of good programming practice (for example, reuse, docu- mentation and style) Subject-Specific Skills • An ability to realise solutions to problems as working JavaScript programs • An ability to apply reuse by exploiting predefined components • An ability to use software tools related to programming (programming environments, code management, documentation tools, etc.) Key Skills • An ability to communicate technical information • An ability to recognise and apply the principles of abstraction and modelling Task summary 1. Construct a dynamic web site for an application of your choosing meeting constraints as written below in the Dynamic Web Site section. 2. Use static HTML page(s) loading dynamic JSON content from server via AJAX 3. Server must be written in nodejs and Express to provide JSON through REST API Dynamic Web Site • Design a website related to a Business, a Charity, or/and an Education related venture (feel free to use your imagination but justify it in the submission!) – The site must have at least two entities e.g. say, people (artists, musicians, scient- ists, customers, beneficiaries, study participants), business/charity/education related objects, places, events, comments etc etc. . . At least two entities must have One- to-Many or Many-to-Many relationship e.g. a Company may sell many products, a product maybe sold by exactly one company (This is a One-to-Many relationship) or maybe sold by many (sometimes maybe just one) company (This is a many-to-many relationship). – The website must have a clear purpose which is evident from/highlighted on the main/single page. Static HTML loading JSON via AJAX • ’Single page app’: page content loaded as JSON via AJAX • Can have more than one page e.g., for user and admin • Should provide clean and simple User Experience (UX) • Should be responsive i.e., work well on desktop and mobile • Recommend using framework such as Bootstrap, semantic-ui The picture in Figure 1 shows the interaction required as a Message Flow chart Figure 1: Server providing JSON through a REST API Entities Each entity (e.g., picture) must have at least: 1. GET method to list/search (returns a list of IDs and names) 2. GET method for individual details (includes details of related entities) 3. POST method to add new entity 4. Document your API in the style of the Twitter API 5. Response provided as JSON 6. Content-type needs to be correct 7. HTTP codes should be correct: use 200, 400 or 403 (if using authentication) Server (to be written in nodejs) Please follow these: • Use npm for management • Make sure you use –save or –save-dev option with packages you add • Write jest test cases: run with npm test • Use eslint: run with npm run pretest • Use express. Use any other packages along with as you see fit. Assessment Assessment Criteria The assessment is divided along the following criteria: 1. Client-side functionality 15% 2. Client-side quality 15% 3. Server-side functionality 30% 4. Server-side quality 30% 5. Video Presentation 10% In more detail, the critreria and requirements are as follows: Criteria Marks/100 Functionality (Client and Server) 45 -Functionality (both Client: 15 marks, and Server: 30 marks) assessed by what is shown/demonstrated in the video (as per criteria below). Quality (Client and Server) 45 Quality (both Client: 15 marks, and Server: 30 marks) -Assessed by Assessor as per detailed criteria that follows. Video Presentation (2 minutes with penalty for going over time). 10 Please read carefully below. Testing Environment • Mac OSX/Windows. Firefox (default). • Visual Studio Code • Standard packages covered in class (npm, express etc) (remember you need to include package.json) Client-side functionality Client-side functionality listed as follows: 1. User Experience (UX): clean layout and minimal clicks/entry required 2. App complexity: entities can be listed and edited 3. ’Single page’ style: asynchronous updates https://developer.twitter.com/en/docs/api-reference-index Client-side quality criteria 1. Standards compliant (HTML5) 2. Responsive to different viewport sizes 3. Gracefully handles server disconnection 4. Useful error messages 5. Recommences on server restart Server-side functionality criteria 1. At least two entity types, with relationships 2. REST API provides each entity with appropriate GET (at least 2)/POST (at least 1) methods 3. Installs with npm install 4. Starts with npm start Server-side quality criteria 1. Development tools and frameworks - NodeJs, Fetch, Express are mandatory. Additional tools/frameworks may be used. 2. Successful eslint (runs with npm run pretest) 3. Successful jest tests with good coverage (runs with npm test) 4. Testing includes content-type and HTTP code 5. Completeness of API documentation Video Presentation 1. Submit a 2-minute (max) video demonstrating your software 2. Include demonstration of how to start the program 3. All functionality will be assessed by what is demonstrated in the video 4. If it is not demonstrated in the video, you will not get a mark for it 5. Quality of video presentation will be marked separately from functionality: (a) Structure, (b) Visual Presentation, (c) Audio explanation You will lose 10% of marks for video presentation (10 marks), for every block of 10 seconds over 2 minutes. That is, if your video is 2 mins 1 second long, you lose 10%, if it’s 2 mins 11 seconds long, you lose 20%, and so on. You may view your marks along the following scale: 1. Fail (< 40) – Most of the basic requirements were not met; there are major errors in the website’s functionality. 2. Approaching expectations (40 − 59) -Many requirements were met, with some issues in the design and development methods, and some minor functionality errors are present. 3. Meeting expectations (60− 79) – The basic/mandatory quality/functionality requirements were mostly or all met; the website is fully or almost fully functional. 4. Exceeding expectations (≥ 80) – the website is fully functional, proficiently addressing all the criteria asked and possibly beyond, high quality code development. How to do the assignment 1. Design HTML 2. Design web service 3. Join with Fetch 4. Read the FAQ (Ver 1 as follows, updated versions (if required) will be posted separately, and class will be informed during lectures). Outline Submission Subject-specific Knowledge Subject-Specific Skills Key Skills Task summary Dynamic Web Site Static HTML loading JSON via AJAX Entities Server (to be written in nodejs) Assessment Assessment Criteria Testing Environment Client-side functionality Client-side quality criteria Server-side functionality criteria Server-side quality criteria Video Presentation How to do the assignment Summative Assessment Programming Assignment 2 Server-Side Programming Frequently Asked Questions Client-side functionality 1. Q. Do we need authentication, like username and password? Not recommended: Doing authentication properly may be quite hard. If you want to do authentication, maybe just include a function to authenticate, which maybe pops up an alert saying ’this page is private’ or something like that. Client-side quality 1. Q. Can I use react to build the web-site? No: It maybe difficult to assess the quality of your solution. 2. Q. Can I use jQuery to build the web-site? No: As discussed in class, JQuery is on the way out. It used to be essential to make things like event handling and AJAX work across browsers. However, now modern browsers of- fer the Fetch API which handles this. The small issue is with Internet Explorer support. However, IE has a minor share now and polyfills are available to make it look like it has Fetch. Many systems still do use jQuery (i.e. bootstrap) but are looking to remove is as a requirement (e.g. Bootstrap 5) so I wouldn’t recommend it for a new project. It would also be difficult to assess. 3. Q. Will I get marked on documentation of the client-side code? No 4. Q. What do you mean by ’gracefully handles server disconnection’? This means that your client-side code should do something sensible if the connection to the server goes down (as it might do if it were connected via the Internet). It should display an informative message to the user, and maybe try again later. You can test this by stopping the server and trying to interact with it through the client. Once the server is started up again the client should be able to carry on as before. Server-side functionality 1. Q. Are we allowed to include additional modules via NPM that provides additional function- ality? Yes. This is a good idea. This makes the code easier to read, more robust and more maintainable. Some frameworks (e.g. React) installed via npm essentially use a different language, so are difficult to read for non-experts. These are best avoided. 2. Q. How are we advised to save the data, i.e using database? In a real system, a database would be the best way to store data. However, databases are not part of this course. The recommendation would be to write functions for saving the state, which just write to file a JSON string representing the state. This will not work with multiple users but would be enough for simple testing. 3. Q. What do you mean by an ’entity type’? Refer to the lecture on REST. An entity or entity type is what you would have studied in your Databases module. In Objected Oriented programming, the counterpart would be what you would refer as a class. This is a distinct ’type’ or ’kind’ of thing. As an example (courtesy Steven Bradley): If your app is about poets and their poems then you would have two entitity types: ’poet’ and ’poem’. For each poet you might want to store their iID name(s), date of birth, url of image. For each poem, you might want to store an ID, the title, date of writing, and the text. The relationships between the entities would be of the form poet1 authored poem2. Exactly how you store the information about the relationship is up to you: you could store the au- thor id with the poem, or store a list of poems ids with the author, or have a separate store relating the two. In either case, when you get the details of an entity you should include everything, including the relationships. It may be a good idea to devote some initial effort on your entities and relationships e.g. using E-R diagrams. 4. Q. What kind of relationship should the entities have with each other? You should have (at least two) entities with One-to-Many or Many-to-Many relationships. You may have additional entities which may have One-to-One relationships but these are not likely to be as useful. Server-side quality 1. Q. Is the testing solely on the server.js file or on the other .js files the website uses also? You only need to test your server side javascript. 2. Q. Are we allowed to use an API documentation generator like Postman or must we create our own documentation from scratch? Yes, if you have a good tool for API generation such as https://learning.postman.com/docs/postman/api- documentation/documenting-your-api/ that would be fine, and a good idea. 3. Q. Will adding comments to the API be sufficient for API documentation, or would it be preferable to use something like postman or ’https://www.npmjs.com/package/node-api- doc-generator’ (an npm package)? One should not need to have to read the code to see the API documentation. You could write it in HTML by hand, or you could use a tool to do that. The postman tool maybe a good idea, the npm tool looks less maintained. 4. Q. What do we need in the API documentation? For the API documentation the ideal is something like the documentation of the Twitter API which lists the methods in the API and then provides the details for each method including details of parameters and response. 5. Q. How should we configure the ESLint file? Unless you have a good reason to do otherwise you should use this module.exports = "extends": "standard", "rules": "semi": [2, "always"], "indent": "off" ; But if you are using something else reasonable that is fine, but you must include the relevant .eslintrc. It shoud not require a whole load of work to set up. Video Presentation 1. Q. What information are we supposed to include in the video? Treat it as a sales pitch for the criteria listed under client-side functionality and server-side functionality. You don’t need to show every single thing that your site does, just show how it meets the requirements. Things like HTML validation, automated testing and the API documentation do not need to be covered. 2. Q. What software should we use to record the presentation, and where could we find it? The university provides Panopto (which is used for sharing lecture recordings) for record- ing and simple editing. Here are some instructions for use. Freely available desktop tools include OBS Studio and daVinci Resolve for recording and editing, which are both power- ful but have more of a learning curve. MacOS provides QuickTime player and iMovie for recording and editing. TechRadar have a list of screen recorder software for other altern- atives. https://www.dur.ac.uk/encore/howtouseencore/desktop/ https://obsproject.com https://www.blackmagicdesign.com/products/davinciresolve/ https://www.techradar.com/uk/news/the-best-free-screen-recorder Client-side functionality Client-side quality Server-side functionality Server-side quality Video Presentation Summative Assessment Programming Assignment 2 Server-Side Programming Assessment Criteria In more detail, the critreria and requirements are as follows: Criteria Marks/100 Functionality (Client and Server) 45 -Functionality (both Client: 15 marks, and Server: 30 marks) assessed by what is shown/demonstrated in the video (as per criteria below). Quality (Client and Server) 45 Quality (both Client: 15 marks, and Server: 30 marks) -Assessed by Assessor as per detailed criteria that follows. Video Presentation (2 minutes with penalty for going over time). 10 Client-side functionality 1a: User Experience (UX): clean layout and minimal clicks/entry required 4 1b: App complexity: entities can be listed and edited 4 1c: ’Single page’ style: asynchronous updates 7 Client-side quality 2a: Standards compliant (HTML5) 3 2b: Responsive to different viewport sizes 4 2c: Gracefully disconnect, error messages and recommence on server restart 8 Server-side functionality 3a: At least two entity types, with relationships 6 3b: REST API provides each entity with appropriate GET (at least 2)/POST (at least 1) methods 12 3c: Installs with npm install 6 3d: Starts with npm start 6 Server-side quality 4a: Coding with development tools and frameworks (Fetch, Express etc) used 7 4b: Successful eslint (runs with npm run pretest) 3 4c: Successful jest tests with good coverage (runs with npm test) 8 4d: Coverage e.g. testing includes content-type and HTTP code 6 4e: Completeness of API documentation 6 Video Quality (a) Structure 3 (b) Visual Presentation 4 (c) Audio explanation 3 (d) Going overtime (over 2 mins) -10% per 10 secs You will lose 10% of marks for video presentation (10 marks), for every block of 10 seconds over 2 minutes. That is, if your video is 2 mins 1 second long, you lose 10%, if it’s 2 mins 11 seconds long, you lose 20%, and so on. You may view your marks along the following scale: 1. Fail (< 40) – Most of the basic requirements were not met; there are major errors in the website’s functionality. 2. Approaching expectations (40 − 59) -Many requirements were met, with some issues in the design and development methods, and some minor functionality errors are present. 3. Meeting expectations (60− 79) – The basic/mandatory quality/functionality requirements were mostly or all met; the website is fully or almost fully functional. 4. Exceeding expectations (≥ 80) – the website is fully functional, proficiently addressing all the criteria asked and possibly beyond, high quality code development. Assessment Criteria