Finding cheap long-distance train fares is currently tedious, as users must check each destination individually, which makes it easy to miss deals on routes or stops they haven’t considered.
A “Deal Hunter” feature could simplify this by letting users select a home station and then return a list of routes passing through that station. Users could pick a limited number of routes (possibly just one), a maximum price they'd be willing to pay for a ticket, and there could be a backend (or maybe user-defined) value for what counts as “long distance.”
The system would then search for fares meeting these requirements along the selected route(s). To avoid excessive API calls, it could identify the first stop meeting the minimum distance on the given route, check the fare, and then selectively check further stops until the budget limit is reached. This approach could efficiently find the furthest affordable destination without overwhelming the system.
My main concern is API load - especially if users are allowed to select a full 45-day window across multiple routes. It would likely be prudent to restrict users to 1-2 routes and to enforce a minimum distance to avoid searching numerous short, local trips in dense regions like the Northeast or Chicagoland.
Does this sound like a plausible feature as described? Would further restrictions on the search criteria be necessary to limit API calls? Is this too niche an issue? LMK!
(And thanks for making such an awesome tool!)
Finding cheap long-distance train fares is currently tedious, as users must check each destination individually, which makes it easy to miss deals on routes or stops they haven’t considered.
A “Deal Hunter” feature could simplify this by letting users select a home station and then return a list of routes passing through that station. Users could pick a limited number of routes (possibly just one), a maximum price they'd be willing to pay for a ticket, and there could be a backend (or maybe user-defined) value for what counts as “long distance.”
The system would then search for fares meeting these requirements along the selected route(s). To avoid excessive API calls, it could identify the first stop meeting the minimum distance on the given route, check the fare, and then selectively check further stops until the budget limit is reached. This approach could efficiently find the furthest affordable destination without overwhelming the system.
My main concern is API load - especially if users are allowed to select a full 45-day window across multiple routes. It would likely be prudent to restrict users to 1-2 routes and to enforce a minimum distance to avoid searching numerous short, local trips in dense regions like the Northeast or Chicagoland.
Does this sound like a plausible feature as described? Would further restrictions on the search criteria be necessary to limit API calls? Is this too niche an issue? LMK!
(And thanks for making such an awesome tool!)