Queen's AMS Event Finder

Problem

Browsing campus events as a separate list disconnects them from where they actually happen. I built an event discovery platform for the Alma Mater Society of Queen's University, and the idea I worked from was to connect events to the physical campus: a user should be able to search for a building, an event or an organizer, explore the campus on a 3D map, and click a building to see what is happening there.

Approach

I engineered the platform as a full-stack application that combines an interactive campus map with a centralized PostgreSQL event database. The frontend is a responsive React application; the backend exposes APIs for searching buildings, discovering events, filtering by time and category, and managing event data.

On the map side, I integrated campus geographic data with the database-driven event information. Building footprints come from OpenStreetMap and are rendered as 3D extrusions. Buildings are highlighted based on the events associated with them. Clicking a building opens its events, with name, organizer, date and time, description, room or location, and a registration link.

Search works across buildings, events and organizers. Events can be filtered by category, by current status, by today, or by this week, and there is a view of upcoming events. The interface also includes day and night map modes, recenter controls, responsive event panels, and a WebGL fallback for when 3D map rendering is unavailable. Event management covers adding, editing and deleting events.

Architecture

The repository is a pnpm workspace with two application packages under artifacts/ and three shared libraries under lib/.

React + Vite (artifacts/campus-map)
      ↓  Orval-generated hooks (lib/api-client-react)
TanStack Query
      ↓
Express API (artifacts/api-server)
      ↓  OpenAPI spec (lib/api-spec), Zod validation
PostgreSQL via Drizzle ORM (lib/db: schema + seed data)
      ↓
Buildings + Events

• artifacts/api-server holds the Express API.
• artifacts/campus-map holds the React web application.
• lib/db contains the database schema and seed data.
• lib/api-spec contains the OpenAPI specification.
• lib/api-client-react contains the generated API hooks and schemas.

The API is defined in OpenAPI and validated with Zod. The frontend communicates with the backend through API hooks generated from that spec, with TanStack Query sitting between the React application and the Express API. The map is built with Mapbox GL JS on the Mapbox Standard style, with its day and night light presets, and the UI uses Tailwind CSS and shadcn/ui. The API and the map run as separate workspace packages in development; the map needs a Mapbox access token and the API a PostgreSQL DATABASE_URL.

Technical decisions

• A 3D map (Mapbox GL JS) instead of a standard 2D map → the project is designed around 3D building visualization, and the map uses 3D building extrusions.
• WebGL fallback → used when 3D map rendering is unavailable.

Challenges

• Campus buildings come from OpenStreetMap footprints while event buildings come from the database, so the map matches the two by distance (within 50 m) to avoid drawing a building twice, and only footprint-backed buildings are matched so an imprecise pin never hides its neighbour.
• 3D rendering needs WebGL and a valid map token, so when either is missing the app shows a clear fallback panel instead of a blank map.

Results

The platform is a working pilot for the Alma Mater Society and hasn't been officially launched, so it has no public URL yet; the code is on GitHub. It covers the interactive 3D campus map, search across buildings, events and organizers, category and time filters, building-to-event linking, event detail views, event add/edit/delete, day and night modes, recenter controls, and the WebGL fallback. I did this work as Full Stack Engineer for the Alma Mater Society of Queen's University between June and September 2026.