Bapple Finder Architecture
This site includes a Bapple Finder page that shows where Busch Light Apple has recently appeared across US ZIP codes. It's intentionally built like a small production system — batch data processing behind the scenes, deployment-driven, map-friendly in the browser, and designed so the user experience stays fast.
Architecture Overview
- Frontend: Next.js App Router application
- Presentation Layer: /bapple-finder page with a client-side Leaflet map and ZIP/city/state/retailer search
- Scan Layer: scripts/scanBuschLightApple.js checks Busch Light Apple availability across US ZIP codes
- Source Data: Busch locator backend GraphQL endpoint used by busch.com/locator
- Transformation Layer: scripts/syncBappleFinderData.js converts found.log into a committed JSON dataset
- Static Data Layer: lib/bapple/finder-data.json deployed with the site
- Automation: scripts/refreshBappleData.sh runs on a scheduled every-2-hour refresh cadence
- Source Control: GitLab (gitlab.com/daburritoking_project_group/personal-site)
- CI/CD & Hosting: Vercel (vercel.com/daburritoking-projects/personal-site)
CI/CD Pipeline
- Code is committed to GitLab and merged into main via standard Git workflows
- Vercel is connected directly to the GitLab repository
- Pushes to main trigger production deployments automatically
- Branches and merge requests generate preview deployments (when enabled)
- A scheduled task runs every 2 hours to scan ZIP-code availability, rebuild the JSON snapshot, commit it, and push it to GitLab
- That scheduled GitLab push triggers a fresh Vercel deployment so the public map updates from the new JSON snapshot
- Build step runs dependency installation and next build before deploy
Request Flow
- Scheduled automation runs the Bapple refresh task every 2 hours
- The scanner checks US ZIP codes against Busch's locator backend for BUSCH LT APPLE
- The scan writes structured results, including found.log for ZIPs with reported availability
- The sync script converts found.log into lib/bapple/finder-data.json
- The refreshed JSON snapshot is committed and pushed to GitLab
- GitLab triggers a Vercel deployment that publishes the updated dataset
- User visits the Bapple Finder page
- Browser fetches the deployed Next.js app and serialized Bapple dataset from Vercel
- The client-side map renders ZIP markers and lets the user search or inspect retailer details
Professional Enhancements
- The expensive nationwide scan is separated from the user-facing request path so the site stays fast
- The page is built around coverage discovery and retailer lookup instead of forcing users through Busch's one-ZIP-at-a-time locator flow
- Availability results are deduplicated by ZIP and packaged into a deployment-safe JSON snapshot for Vercel
- Search works across ZIP, city, state, and retailer labels so the page is useful for both local lookup and broad exploration
- Map markers represent ZIP centroids derived from scan data, which keeps the interface legible without pretending to show exact shelf locations
- The refresh loop keeps the site current without making every visitor wait on a live upstream scan
Security & Guardrails
Upstream Isolation
- User page views never call Busch's locator backend directly from the browser
- The heavy scan runs in automation rather than during public requests
- Vercel serves a committed snapshot instead of live-scanning on demand
- The deployed map exposes only the curated JSON dataset needed for the experience
Data Handling Controls
- Only valid US 5-digit ZIP codes are scanned
- Availability is split into found, missing, and error logs for operational clarity
- 429 status code rate limits and transient upstream failures are retried with bounded backoff
- The sync step normalizes retailer summaries into a cleaner JSON structure before deployment
Operational Discipline
- Dataset changes move through the same GitLab + Vercel workflow as application code
- The refresh cadence is explicit and repeatable rather than ad hoc
- Committed JSON snapshots make deployments traceable and rollback-friendly
Design Philosophy
Bapple Finder works best when the slow, failure-prone, upstream lookup process is treated as a background data pipeline and the public page is treated as a fast, static-first browsing experience. That separation is what makes the feature feel simple to users while still doing a lot of work behind the scenes.
Roadmap
- Smarter incremental refreshes instead of always scanning the full ZIP universe
- A small operator dashboard for scan health, retry counts, and refresh timestamps
- Historical change tracking to show where availability is expanding or shrinking over time
- Clustered or density-based map views for easier large-scale browsing
- Drink Bapple with friends