After merging icssc/peterportal-client#297 (search pagination), I think PeterPortal specifically could benefit from an API route tailored to our use case.

Current implementation of our search makes a fuzzy search limiting results to the first 5 pages (50 total, 10 per page). Then it makes a GraphQL request to the API requesting data for the 10 courses on the current page. Each time the page is changed, another API request is sent for the courses on that page.

If the user moves on to page 4+, an additional fuzzy search is made without a limit to get all results (for an empty query this is about ~6000 courses). More results are needed once page 4+ is reached since we need to know how many pages remain to know what page number buttons to render below. This unbounded search is pretty slow, hence why we limit to 50 initially (site would freeze when loading otherwise). A button to the last page is also omitted in our current implementation because we don't know what the last page number initially given that we limit to 50 results.

I think we could benefit from an API route where we have parameters similar to the current fuzzy search (query, filters, number of results, etc.) and a new parameter for offset (so we can get a range of results from [offset, offset + number of results)). In response, we would get the full course/instructor data for that range rather than just metadata and the total number of results that match the query so we can determine how many pages of results there are.

Lastly, I think the current fuzzy search being called "fuzzy" is a bit of stretch lol. It seems to only match substrings and won't find results if there's a typo/a single letter missing.

For AA I kinda am fine leaving it janky and never touching it, but if PeterPortal switches solutions then I think it'd be pretty easy for us to just copy paste real quick