11  Rithika Silva

Author

4th Year
Computer Science
Minor in Combinatorics & Optimization
Infrastructure Developer

Building on the infrastructure foundations laid in Year 1, this year had three main focuses: continuing to grow and maintain the existing infrastructure, acting as a force multiplier for other students by unblocking infrastructure hurdles and providing hands-on guidance, and delivering proof-of-concept tooling to demonstrate what the existing infrastructure could enable. This was also my final year, as I’ll be graduating this spring.

Projects

Infrastructure Work

Most of my time this year was spent on the data infrastructure that underpins the rest of the program, both building and guiding others through it. This included setting up org-wide PR and issue templates, maintaining the project template and onboarding documentation, and providing direct support on individual projects.

  • balltime: guided Austin You with building and debugging a bronze-to-gold data transformation pipeline for Balltime.
  • instat-scraper: guided Jalal Bouri with extending the existing instat-scraper to collect play-by-play, player, and team information from additional endpoints.
  • TeamBuildr: guided the rewrite of the TeamBuildr scraper in Python, extending it to collect additional data fields with a GitHub Actions release workflow.
  • vald-client: guided the initial project setup for scraping athlete monitoring data from VALD.
  • 49ing-scraper: guided Jalal Bouri with setting up the 49ing-scraper bronze layer data collection pipeline.
  • usportspy: modernized the development toolchain for usportspy, switching to uv for dependency management, adding a Makefile, and introducing a basic test suite. Released as version 0.0.12.

The bullets above reflect what’s visible in the git history. The rest of the work is a bit harder to capture 🗿.

Athlete Nutrition Tracker (KIN472)

As part of a KIN472 course project, I worked on a proof of concept app designed to help men’s and women’s basketball athletes monitor their nutritional intake and hit their macronutrient targets. The app allows athletes to log meals, input ingredients they have on hand, and get meal suggestions tailored to their dietary restrictions. Macronutrients are calculated based on the athlete’s personal profile (age, height, weight, sex). Nutritional data was gathered through the Spoonacular API, though meal suggestions are hardcoded into the backend with the expectation that a registered dietician would provide the actual recommendations. It was built with React and Next.js for the purposes of the demo, and ideally this would move to React Native to function as a proper mobile app.

usportsmuse

usportsmuse is a platform that allows users to query U SPORTS data in natural language. It is built on a LangGraph backend with an assistant-ui React frontend, and is deployed on Railway.

The core of the system is an agent that translates natural language questions into SQL queries against our U SPORTS data (currently stored in DuckDB), executes them, and renders the results as structured UI components (e.g. player summary cards, game flow charts, and box score summaries). Building this required solving several non-trivial problems:

  • Player name disambiguation: player names vary across seasons and between data sources, so the agent needed a search layer that could resolve ambiguous queries to the correct player before generating SQL. Our current solution does some precomputation, as well as query-time resolution by deferring to the user for unresolvable cases. Our goal is to move towards a player UUID system so that the agent layer doesn’t need to piece data for a singular athlete together.

  • Sport-specific summary cards: each sport surfaces different statistics, so we built separate player summary components for basketball, volleyball, soccer, ice hockey, and football, each pulling career stats and league comparisons.

  • Deployment: we initially tried Vercel for deployment, since assistant-ui uses Next.js. However, deploying the LangGraph backend (which we chose to develop in Python) proved more involved than necessary for a project of this scale. Having prior experience using Railway, we chose to keep both the frontend and backend as separate services deployed under the same project.

Reflections

  • usportsmuse was only possible because of the data infrastructure we had already built. We’ve thought of a few use cases, but I think we’ve yet to really scratch the surface of where it provides value. I’m excited to see what the Data Solutions IST does with it.

  • The deployment experience with Railway highlighted a gap in our infrastructure: we do not yet have a reliable, reproducible deployment story for Python services. Having our own compute remains important.

  • This year we tried to use GitHub Projects to manage tasks for the infrastructure team. While initial setup went smoothly, it quickly became a burden to keep up-to-date rather than a source of truth. For future years, if a Kanban-style board is used, it needs to be the primary workflow tool. Individual members should track all tasks there to avoid periodic catch-up sessions.