Refresh according to context
The live dashboard uses a 15-second interval for live sessions and slows to five minutes when the tab is hidden. Recent, upcoming, and idle sessions have their own intervals.
01 / CASE STUDY F1 Pitwall Analytics
F1 Pitwall
Analytics
From race results to race context. A Formula 1 platform that connects historical results, live-session views, and personal watchlists in one place.
CONTEXT
Personal project · Active development
MY ROLE
Full-stack development
BUILT WITH
THE PROJECT IN MOTION
See the race data in action.
Music only · No narrationOpen video
Tour overview & credits
- 00:00 F1 Pitwall Analytics — an introduction to the platform.
- 00:04 Championship standings and the leading drivers.
- 00:10 Compare drivers head to head and change the selection.
- 00:16 Explore pit-stop stints and highlight Norris’s race strategy.
- 00:21 Follow points progression across the season.
- 00:27 Browse driver profiles and open Verstappen’s details.
- 00:33 Search for Monaco and explore its circuit information.
- 00:39 Visit the project to explore more.
Dashboard scenes use the project running locally with public historical data.
Music: Happy Beats & Business Moves Vol. 12 by Sascha Ende, CC BY 4.0. Edited excerpt with volume adjustments and fades.
Configured refresh and caching
- Live-session refresh
- 15s
- Hidden-tab refresh
- 5min
- Completed-session cache
- 24h
01 / THE PROBLEM
One sport. Several kinds of data.
Season standings, session telemetry, and a fan’s saved interests have different data needs. The challenge is to make them feel like one application while keeping frequent updates and account-specific data under control.
02 / THE APPROACH
An application with a supporting service.
Next.js handles the interface, authentication, watchlists, and API routes. Prisma connects the application to MongoDB. A separate Node.js service supports polling, Redis caching, and email notifications.
- 01Sign inNextAuth session
- 02Send requestNext.js API route
- 03Check ownershipSession-scoped access
- 04Store the listPrisma → MongoDB
Race data follows a separate path through external feeds and internal API routes. The diagram focuses on the authenticated watchlist workflow.
03 / KEY DECISIONS
The details that shape the build.
Treat finished sessions differently
The telemetry route caches completed sessions for 24 hours and live sessions for 15 seconds. These are cache settings in the implementation, not measured response-time claims.
Keep personal data scoped to the user
Watchlist reads and writes require a session. Queries use the signed-in user’s ID, and creation validates the name and description before writing the record.
04 / THE RESULT
A working foundation for following the race.
The platform combines standings, results, telemetry views, authentication, and watchlists. The repository remains in active development, with room to extend the analytics experience.
A constraint worth understanding
The telemetry cache is process-local, so separate application instances do not share it. Data availability and refresh timing also depend on the upstream feeds.
05 / EXPLORE THE CODE
Go one level deeper.
Follow the implementation behind the decisions.