As [Matt Stele] prepared to bike a local 300-mile (~480km) race in addition to training, he had to prepare for food. A full day of riding was ahead on gravel trails, and one of the best options for him was Casey’s General Store pizza. However, as it was a race, other riders were much faster than him. So, all the hot slices were gone when he arrived. With the help of a serverless GPS tracker, some cloud lambdas, and some good old-fashioned web scraping, [Matt] had a system that could order him a fresh pizza at the precise moment he needed.

Each racer has a SPOT satellite GPS tracker, which emits GPS pings every 5 minutes, ingressed by an AWS lambda (code for that here). This provides geofences that can fire events that can, in turn, spin up lambdas. Since the resources aren’t persistent, the cloud bill runs around 77 cents a month. However, [Matt’s] journey wasn’t over yet. Ordering a pizza and sending push notifications to his watch was quite challenging. With no easily documented API, he opted to use a web scraper. However, as Casey’s website uses React, this meant that [Matt] needed a powerful scraping agent. After struggling, he managed to get Playwright, a chromium-based agent working in lambda.

At mile 180 (~290km), [Matt] got the notification from the pizza order on his watch. However, not all were roses. At Casey’s, there was no pizza waiting for him or record of the order. A quick check of the account showed no record of the order. Scratching his head as to what went wrong, he modified the system to record a video of the checkout process. To his surprise, this worked. His theory is that without saving the video, the lambda function shut down as soon as the form was submitted without giving it time to send the form request.

Could [Matt] have just called ahead? Yes. Would it have been nearly as good? Not even close. However, it’s a great lesson on testing before trying to put something into production.