CS 478 HW 2: Reflection

I restructured the project by moving the HW1 code into a /back folder. I also updated all routes to include an /api prefix (e.g., /api/books) so the Vite front-end could proxy requests. Additionally, I implemented ORDER BY title ASC in the GET books route to ensure books are returned in alphabetical order. If I could go back, I would have initially designed the backend with a consistent /api routing structure to avoid the need for later changes. Also, initially putting the code into a /back folder would also save some time when transitioning to a react frontend.

When adding books and authors, I used a combination of server-side and client-side validation. For the server-side, I used Zod schemas in my Express routes to ensure that all data entering the SQLite database was strictly validated, protecting the system from malformed requests. The primary advantage of server-side validation is that it acts as a secure, single source of truth, though it has the downside of latency since users must wait for an API response to see errors. I also implemented basic client-side validation using HTML required attributes and React state to provide immediate feedback to the user, preventing empty or obviously incorrect submissions before a network request is made. While client-side validation is less secure because it can be bypassed in the browser, its main benefit is a much smoother and more responsive interface.

My experience with using React was positive, for this assignment. I was able to create a structured framework for the dynamic user interface. I enjoyed the declarative nature of components, which made it easier to visualize how the UI should look based on the application's state. However, I initially struggled with the logic behind the useEffect hook, specifically ensuring that the dependency array was set correctly to prevent infinite rendering loops while fetching data from the backend.

Comparing React to the plain JavaScript DOM manipulation I did in CS375, the experience was significantly different because React manages the DOM updates automatically. In plain JS, I had to manually select elements and update their properties every time data changed, which was tedious. In contrast, React's state-driven approach allowed me to focus on the data itself rather than the mechanics of updating the screen. I prefer React because it results in cleaner, more maintainable code that is easier look at and also to debug as the application scales.

Using TypeScript on the front-end was a generally helpful experience that provided an extra layer of confidence when handling API responses. It caught several bugs early on, such as when I tried to access properties on a book object that didn't exist or had different naming conventions than the backend. I did find it tedious to define interfaces for every data structure, especially when dealing with nested JSON, the types ultimately felt more helpful than useless.

I used an LLM to assist with troubleshooting issues that I encountered and designing the AddForm.jsk file. Specifically, the LLM was helpful in resolving a dependency loop with the tar package and in drafting the initial structure for the BookTable and AddForms components to match my SQLite schema.

This significantly changed my coding experience by saving me time on repetitive tasks, such as writing CSS and defining TypeScript interfaces, which made the process more enjoyable. While the AI handled the more tedious parts of the assignment, I still had to engage with the logic to ensure the Vite proxy was correctly configured and that the state-driven UI updates functioned as intended. Overall, I believe using an LLM allowed me to learn more about high-level system architecture and front-end integration rather than getting stuck in syntax errors.