DebDob: Wikipedia Racer

DebDob was both genuinely fun and unexpectedly exhausting. Our Algorithm Strategies course asked us to turn breadth-first search and iterative deepening into a race across Wikipedia.

I had seen social media trends about how many connections separate one person from another. Wikipedia racing felt like the same idea, except every step moved through an article link. The name came from our teammate Dabbir, who we called Deb. We added Dob simply because it sounded good.

At the time, I was actively learning frontend development. One teammate was especially interested in the algorithms, so our responsibilities separated naturally.

I led much of the frontend, including the search form, Wikipedia autocomplete, and graph visualization. I also worked on caching, Docker, and integration with the Go backend.

A list of article titles would technically show the result, but it would not communicate how the pages connected. I wanted every article to become a node and every link to become an edge so people could see where multiple shortest paths separated and rejoined.

Building that visualization with D3 was difficult. I spent a lot of time reading documentation and studying other GitHub projects before I could turn the API response into a readable graph. That made the result especially satisfying.

The algorithms could be correct while the application still felt slow. Every expansion required downloading and parsing real Wikipedia pages. Internet speed and request limits became part of the search.

I worked on a cache so the application could reuse article links it had already discovered. It taught me that real optimization often happens around an algorithm as much as inside it.

Breadth-first search is useful when finding the shortest path matters, but each level can contain an enormous number of pages. Iterative deepening explores with a growing depth limit, trading repeated work for a different memory and search profile.

Watching both strategies operate on Wikipedia made their tradeoffs concrete. The graph was no longer a small lecture diagram. It was a live network with unpredictable branching, latency, rate limits, and thousands of possible paths.

I would show live search progress, including the current depth, visited pages, and frontier size. I would also make dense graphs easier to navigate.

On the backend, I would add stronger time limits and improve the cache so the project could work reliably as a public application rather than only as coursework.