Homework 1 Reflection

• Coding
  • I spent about 5 hours on this assignment altogether. I spaced out the work over a couple of days rather than one sitting.
  • I spent most of my time fixing configurations and setup, followed by creating and debugging test cases. I was initially having issues getting TypeScript to compile to JS during the build process, even after installing necessary packages, and then decided to copy some of the contents in the activity 1a package.json to replicate its behavior.
  • I think I struggled the most with determining any additional features this REST API needed to support beyond the basic CRUD requests. The requirements left things a little open-ended, which is nice, but I feel like a more strict list of objectives would have saved some time on brainstorming.
• TypeScript
  • Some of the common bugs TypeScript was able to catch were type mismatches, such as when I passed in a string with the intent to use it as a number, as well as syntactic issues like typos when referencing a variable. I noticed the compiler was helpful in identifying failing lines quickly for these smaller errors. One of the errors it did not catch was a SQL querying error, as I left in four "?" in the insertion when I was only providing two fields for the statement. The compiler still processed successfully when running db.get on this, but the TS test file was able to capture this mistake.
  • Running the tests helped pinpoint specific bugs in my request handlers and in my database setup. The tests revealed an issue with my primary key generation that was leading to unexpected ID values in both tables. I also resolved issues with my status codes and response JSON structure based on whether they matched the expected output.
  • In the future, I will try to structure my tests better so that one test is not dependent on another, or more so in conflict with each other. I had some issues initially because I was trying to return a row of data that had been deleted in a previous request. One thing I learned while testing is that status codes are very useful in a number of different scenarios, as there are several codes available to suit a given test case. Basing the success of my request handler off the status code that the server returned made things easier for getting through basic applications of CRUD in REST.
• Testing
  • Testing was mostly enjoyable as it provided a very efficient way of translating the API request handlers to actual request cases. Once the request endpoints were defined and the methods were written, I was able to utilize some of the starter code examples to write tests that checked basic CRUD functionality, as well as additional cases (e.g., deleting an author that still has books associated with their ID).
  • Running the tests helped pinpoint specific bugs in my request handlers and in my database setup. The tests revealed an issue with my primary key generation that was leading to unexpected ID values in both tables. I also resolved issues with my status codes and response JSON structure based on whether they matched the expected output.
  • In the future, I will try to structure my tests better so that one test is not dependent on another, or more so in conflict with each other. I had some issues initially because I was trying to return a row of data that had been deleted in a previous request. One thing I learned while testing is that status codes are very useful in a number of different scenarios, as there are several codes available to suit a given test case. Basing the success of my request handler off the status code that the server returned made things easier for getting through basic applications of CRUD in REST.
• LLMs
  • I only slightly utilized an LLM for this assignment. I ran into a consistent error with my primary key ID column in both author and book tables where the value is incremented from the last saved sequence prior to being dropped. When I put this into ChatGPT, I learned that setting my primary key to auto-increment was the culprit as this would mean that the ID values would always be unique in the DB table (even after rows are deleted).
  • My small usage of ChatGPT did highlight an important distinction that I needed to make when I changed my ID field type from text, like in the starter code, to integers. Since they were being auto-generated, I had to manually check the DB in case there were any issues with those values. By doing this and then asking the LLM, I saved a bit of debugging time.