Homework 3: An AJAX-Based CRUD App

This assignment is due before class starts on Monday, October 23.

This assignment has two+two purposes:

  1. Familiarize yourself with writing JavaScript on the client side.
  2. Familiarize yourself with API-style application state manipulation.
  3. (Optional) get some experience with client side SPA libraries. (+10% bonus credit)
  4. (Optional) write some tests BEFORE implementing the code you’re testing. (+10% bonus credit)

The work will be split up as in Homework 1: you need to implement the six below tasks, but with all state manipulation taking place via AJAX calls initiated by the browser.

  • Allows visitors to register a new account with some basic user information which is visible on a user profile page.
  • Allows users to edit their own profile
  • Allows users to create new “posts” which each have their own unique URL.
  • Allows users to restrict their post visibility beyond “all visitors to the web app”. Note from in class discussion: Post authors must be able to see the current visibility setting for each post.
  • Allows users to view posts by other users according to visibility rules
  • Allows users to delete their own posts

Hints and Notes

  • You absolutely should send each page to the client statically. If you still want to write pug rather than HTML, you can do so with a package like semi-static. The page and the JavaScript should be served statically for this assignment, that way you don’t even need to write the routes that will be serving those files.
  • Just as with Homework 2, you do not need to keep your app pixel-perfect reproduction of Homework 1. But it still needs to work properly.
  • For an SPA version, ask the instructors if you plan to use a library besides:
  • I highly recommend you do not attempt to use an SPA library unless you are confident in your web app coding skills or are prepared to take the time to learn how to use those libraries. An SPA library is not the right tool for this job, as it is far too heavyweight for such a simple application (with so little functionality being provided on the client-side only).
  • I highly recommend you write the client side functionality first with stubs for the backend. You could even split your tasks up as front end and back end within your group, but be careful about how you test and integrate!
  • I do recommend taking your newfound testing experience to write tests for your application. Write these for the Express routes - testing UI code gets hairy quickly (but feel free to try!).

Grading oracle

This assignment is due before class start time on Monday, October 23. Due to the manual and potentially subjective nature of grading, if you have any questions regarding whether you have sufficiently implemented a given feature, we will provide a grading oracle service. This will be similar to code reviews, but for grading. Each group is allowed, once every 24 hours (with the exception of the last 24 hours before the deadline - none will be accepted then), to send a review request. The process will work like this:

  • Write your contribution to the assignment in a repository fork. You can learn about the GitHub flavored forking model of software development here.
  • Add me and the TA as collaborators on your team repository.
  • Create a pull request on your team repository. Be as concise and descriptive as you can with what you’ve done, how to run it, and what feature you’d like tested.
  • Request a pull request review from us (at most once per 24 hours).
  • Wait at most 24 hours for us to respond. I make no guarantees of any response in any amount of time less than that.
  • If for any reason we can’t successfully test your code (we follow your instructions and node doesn’t start correctly, a file that’s needed for correct operation doesn’t exist in the repository…), we’ll let you know what error we got. We’ll be descriptive, but we won’t debug the process with you (outside of your next PR request). This expends your grading oracle request for that 24 hour period.
  • You’ll get a full credit/failed bit of information feedback at minimum. Any other feedback will be at our discretion.
  • If it takes me more than 2 minutes from clone to test complete, we reserve the right to tell you that the test timed out.
  • You are only guaranteed a response if you request review from both of us, and it’s up to us to decide who reviews it. If you get a review from one of us, the other won’t also test it.
  • We’re keeping track of the 24 hour limit manually for now. You’ll get one warning if your group sends more than one review request within a 24 hour window. A second “too soon” review request will lock your team out of oracle requests for the rest of the class.

Note that getting positive feedback here does not guarantee that you will get credit for that feature. Regressions are real. If you somehow introduce a regression later on, you could still lose those points.

Once the deadline has passed, the grading decision of the grader is final unless the decision is deemed completely unacceptable by us. The sooner you get started, the more you can take advantage of the oracle.