Skip to content

HW Assignment 2 - Backend Development

Possible Points Due Date
50 pts September 28th - Before Class

Overview

In this homework, you will create a simple microservice that fetches a dataset from a third-party API and offers endpoints for manipulating a local copy of this dataset.

Assignment Instructions

Step 1: Following the Tutorial for Setting up GitHub and Heroku

Please follow the instructions for setting up this homework assignment in GitHub Classroom and deployment of your project via Heroku.

Step 2: Describe 7 User Scenarios

In this step, you will identify 7 scenarios that your microservice will support. Each scenario should correspond to a separate endpoint your microservice offers. At least 3 endpoints should involve information that is computed from your initial dataset (e.g., may not entirely consist of information from a 3rd party API). Imagine your microservice is offering city statistics. It might expose the following endpoints

  • Retrieve a city
    • GET /city/:cityID
  • Add a new city
    • POST /city
  • Retrieve data on a city's average characteristics
    • GET: /city/:cityID/averages
  • Retrieve the list of top cities
    • GET: /topCities
  • Get the current weather on a city
    • GET: /city/:cityID/weather
  • Get the list of mass transit providers and links to their websites
    • GET /city/:cityID/transitProvders
  • Add a new transit provider
    • POST /city/:cityID/transitProvders

Step 3: Implement your 7 defined User Scenarios

In this step, you will implement the seven user scenarios you identified in Step 2. You should ensure that requests made by your code to the third-party API are correctly sequenced. For example, requests that require data from previous request(s) should only occur after the previous request(s) have succeeded. If a request fails, you should retry the request, if appropriate, based on the HTTP status code returned. To ensure that potentially long running computation does not block your microservice and cause it to become nonresponsive, you should decompose long running computations into separate events. To ensure that you load data from your data provider at a rate that does not exceed the provider's rate limit, you may decide to use a timer to fetch data at specified time intervals.

Requirements:

  • Use fetch to retrieve a dataset from a remote web service.
    • Data should be cached so that the same data is only retrieved from the remote web service once during the lifetime of your microservice.
    • You should handle at least one potential error generated by the third-party API.
    • Ensure all fetch requests are correctly sequenced.
  • Declare at least 2 classes to process and store data and include some of your application logic.
  • Endpoints
    • At least 4 endpoints with route parameters (e.g. /:userId )
    • At least 5 GET endpoints
    • At least 2 POST endpoints.
    • All invalid requests to your service should return an appropriate error message and status code.
  • Decompose at least one potentially long running computation into separate events. It is not required that the computation you choose to decompose execute for any minimum amount of time. But you should choose to decompose a computation whose length will vary with the data returned by your data provider (e.g., the number of records returned).
  • Use await at least once when working with a promise.
  • Use JEST to write at least 12 unit tests to ensure that your code works correctly

Using Resources

You are welcome and encouraged to consult any publicly available resource you wish (e.g., Mozilla Developer Network documentation, tutorials, blog posts, StackOverflow). However, in this assignment, all of the code you submit should be your own.

Submission instructions

In order for your assignment to be considered for grading, you must be sure that you fill out the following information at the top of your README file and ensure that this is up to date in your GitHub repo.

  • Student Name
  • Student G-number
  • Heroku Deployment URL
  • Description of your 7 API endpoints

Warning

Failure to include this information in your submission is likely to result in a zero for the assignment!

There is no formal submission process for this assignment. We will simply grade the last commit to the main branch of your repository before the deadline of 4:30pm on Wednesday, September 28th. If you make a commit after the deadline, we will grade the latest commit and your assignment will be considered late. Per our course policy, assignments submitted over 48 late will not be accepted.

Grading Rubric

The grading for this project will be broken down as follows:

  • API Endpoints - 4 points each (28 points total) We will take into account whether the requested Javascript features were used here.
  • Unit Tests - 1 point each (12 points total)
  • Coding Style - 10 points broken into the three categories below:
    • Documentation & Comments - 4 points
    • Modularity/Maintainability - 3 points
    • Identifier Intelligibility - 3 points

It is important to note that coding style will be an important component of this project's overall grading. Below, I provide some tips on earning these points:

  • Documentation & Comments - In order to earn these points, you should document all non-obvious functionality in your code. For example, if there is some complex computation that is not easily understood via identifiers, then this should be clearly documented in a comment. However, you should try to avoid documenting obvious information. For example, adding a comment to a variable named citiesList that states "This is the list that holds the cities" is not likely to be a valuable comment in the future. Part of this grade will also stem from your description of your endpoints in your README file.
  • Modularity - Throughout the course of this semester, one topic that has come up repeatedly is the idea of code maintainability. One of the best ways to help make your code more maintainable in the long run is to make it modular, that is try your best to achieve low coupling and high cohesion. We expect that you will break your project down into logical modules, and where appropriate, files.
  • Identifier Intelligibility - The final code style related item we will look at is the intelligibility of your identifiers. This should be pretty straightforward, use identifier names that correspond well with the concepts you are trying to represent. Try to avoid unnecessarily short (e.g., i) and unnecessarily long identifiers.