Beet the Bookies, how it's made.

Why I started looking into this side project Link to heading

I decided to make Beet the Bookies in part due to my growing obsession with AFL and especially how predictive the odds betting companies set out for games were of results.

This was around 2018, and I’d recently started my first year of “Footy tipping”, this is where you go to the pub and get a free beer for predicting the winner of this weeks AFL games. I was looking for an easy way for me, someone who new bugger all about AFL, to put in a decent showing while I drank my beer. So I started to explore more around predicting AFL games and ended up exploring the odds bookmakers gave. ( I actually ended up coming joint second in the tipping that year, in a pub that is extremely close to the MCG inhabited by footy fanatics however all but 1 of them did worse than me, simply picking the favourite in every game.)

One other big motivation was for me to have a side project that would allow me to explore several technologies I was interested in but not able to work with in my role at the time.

Some considerations about what technologies to use Link to heading

At the time I was working in an organisation that used Google Cloud, I’d used lots of the different tools in that platform. But I knew that AWS was more widely adopted and I wanted to see what it was like. I wanted to first-hand see what its differences, strengths and weaknesses were. I was also predominantly working on an server-side application that actually didn’t have any real data storage, no database or nothing. So I decided I wanted to try out

• Lambda functions, because:
  • I wanted to gain some exposure to the serverless approach.
  • I knew they required very little overhead. I wouldn’t need to manage the infrastructure, just write the code and this could be iterated on quickly.
  • They have a “pay as you go” cost model. While basic server costs are low, I knew I was probably going to be the only one using the tool, so they were likely to be idle the vast majority of the time.
• DynamoDB because:
  • I wanted to gain experience with NoSQL databases as use of these for web applications was growing.
  • I knew I would need to work with a dataset of historic information, likely to be “semi-structured” but I didn’t want to have to change my table schemas all the time as I was developing as I might with an SQL DB.
  • I hoped that the low latency of the DynamoDB would help provide good response times for retrieving data.

I also knew that simply building an API wasn’t likely to encourage others to use it. (I didn’t think a basic probably not super accurate API for predicing AFL games was likely to go viral on HackerNews) I wanted to build some UI interface to show I’m “Full Stack” or “T-Shaped” or what ever the term is currently. So I wanted to make a basic UI with some sort of cross platform framework like:

• React/ React Native
• Flutter