Bootcamp Week 5 – Working with an Existing Codebase

Similar to week 4, this week we were tasked with creating a website that utilised two different APIs in a group of three and followed the basics of a Figma design. But, this time we were starting from an existing codebase!

Codebase Review and Development Process

To start, my team and I spent some time reviewing the existing codebase and identifying which new components we needed to implement. The homepage and about page required some HTML, CSS, and basic JavaScript for the hamburger menu and tab functionality, while the Ask and Shop pages needed additional JavaScript and CSS styling.

Once we identified the requirements, we created GitHub Issues in our project board, discussed them as a team, and assigned the work accordingly.

For this project, I was responsible for the JavaScript on the Ask and Shop pages. These two pages used different API endpoints, whereas the existing code had been loading data from a JSON file. My task was to determine which parts of the existing codebase and API I could reuse and which pieces of functionality I needed to build from scratch. I updated my GitHub issues accordingly and got started…

Ask Page API

The Ask page uses an API that sends a query to ChatGPT with a predefined context:

“Concise responses in British English. Respond with a JSON object containing one parameter, results, which should be an array of five items. Each item must have two properties: title and description.”

I was able to further customise this API by applying additional context. After some experimentation, I settled on the following prompt:

“I only want answers about desserts and puddings. Write descriptions in an overly descriptive way, and make sure each title includes a pun.”

After testing and playing around with the API, I updated the JavaScript for the Ask Page to fetch data from the API instead of the json file, using the user’s search input as the query. Before sending the user’s input to the API, I cleaned it up a bit by replacing spaces with + signs and converting everything to lowercase. For example, "Chocolate Cake Recipes" becomes "chocolate+cake+recipes", making it URL-friendly and consistent for the API request.

I also added functionality to the “Show More” button. In the existing codebase, it didn’t actually fetch any new data — it was just there for show. Since the API only returns five responses at a time, I updated the button to fetch five new ones with each click. For a while, I thought it was just returning the same results over and over, but it turned out to be a quirky behaviour of ChatGPT’s API.

Shop Page API

For the Shop page, we fetched products from the API’s backend, where I had created ten sample products. In the existing codebase, the only working functionality was the search input from the Ask page. The API itself offered limited sorting options and only allowed specifying the number of products per page and the page number. After comparing the API’s capabilities with the existing codebase, I realised I needed to add some custom sorting features and ensure they worked properly with pagination.

To make sorting work smoothly, I added a couple of helper functions. The first, getAPISortValue(), converts the user’s chosen sort option (like “price-low” or “title-z-a”) into the API’s equivalent field, since the API only understands generic fields such as title, price, or rating.

The second, shouldReverseResults(), checks whether the API supports the requested sort order. For example, while the API can sort titles A–Z, it can’t do Z–A, so I reverse the results on the frontend when needed.

Finally, the processProducts() function prepares the API data for display. If reverseResults is true (for Z–A or high-to-low sorting), it reverses the product order; otherwise, it leaves them as-is. Together, these functions bridge the gap between the app’s sorting options and the API’s capabilities.

The Finished Site and Overall Thoughts

Overall, the site functioned as expected. As a team, we collaborated well by assigning tasks in a way that minimised conflicts. The main delays occurred when waiting for reviews - for example, the styling I used on the Ask page needed approval before applying similar styles to the Products page, to avoid redundant work.