Node
1. Changes made to the back end and reflections on HW1
While building the front end for HW2, I realized that my HW1 back end was written mostly in isolation. It worked, but it wasn’t designed with a UI in mind. The biggest change I made was
was moving my Zod schemas and inferred types into a separate types.ts file. In HW1, everything lived in server.ts, which was fine when I was only thinking about routes, but once I needed
to reuse types with the front end, that setup became limiting.
Another required change for HW2 was namespacing routes under /api so the front end could proxy requests correctly. I also had to make my query parsing more defensive. In HW1, query parameters
were clean because I controlled the requests, but in HW2 empty strings started coming from form inputs, which forced me to rethink how I validated and transformed query parameters before
using them.
One change that came directly from using the UI was normalizing genres. Filtering behaved inconsistently when casing or spacing didn’t match exactly, which isn’t something I would have
noticed just by testing the API.
2. Server-side vs client-side validation
When adding books and authors, I used both client-side and server-side validation. Client-side validation helped catch obvious issues early and made the UI feel more responsive. Server-side validation was still necessary to enforce rules and protect the database. Using both felt like the right balance once I started thinking about usability instead of just correctness.
React
1. General experience using React
Overall, my experience with React was mixed but mostly positive. The hardest part was understanding state, effects, and how asynchronous data affects rendering. I ran into situations where data wasn’t available yet or components re-rendered in ways I didn’t expect, which took some time to get used to. Once things started to click, I enjoyed how React handles UI updates automatically based on state. It felt much cleaner than manually managing DOM changes once I understood the mental model.
2. React vs plain JavaScript DOM manipulation (CS375)
Compared to writing plain JavaScript DOM manipulation code in CS375, React felt much more declarative. In CS375, I had to manually track when and how the DOM should update. In React, I focused more on describing what the UI should look like given the current state. React has a steeper learning curve, but for anything beyond small scripts, I prefer it because the code is easier to reason about as the application grows.
3. Experience using types on the front end
Using types on the front end was helpful but sometimes tedious. Types caught a few mistakes for me but typing async data and state required some trial and error. Overall, I think the benefits outweighed the frustration, especially when refactoring.
LLMs
1. How I used LLMs
I used LLMs mostly for planning and brainstorming rather than writing code directly. I used them to break the assignment into steps, think through how different parts of the app should interact, and talk through design decisions when I felt stuck.
2. Reflection on using LLMs
Using LLMs made the assignment feel less overwhelming and helped me get started more quickly. I still had to implement and debug everything myself, so I don’t feel like they took away from the learning. If anything, they made the process more enjoyable by helping with direction rather than execution.