Tech Stack

For my fellow geeks interested in how this was put together...

Database info

The database is surprisingly small. There are only 3 tables.
  • The library table has the info on the OverDrive/Libby libraries. It is preloaded with all the OverDrive subdomains and their description/name. As they are queried, the row is updated with the OverDrive library id and the token to access its data in the OverDrive API and then it never has to be retrieved externally again.
  • The bookstatus table holds the OverDrive/Libby info for a book at a given library. I didn't want to hammer the OverDrive API needlessly so I cache the info in the DB. It's stored for 24h, so if you do a search then immediately rerun it without changing your shelf contents, it will just give you all the info from the DB and it won't re-query the OverDrive API. I also have a cleanup job that removes any entries older than 24h. At that point the data is old anyway and if someone re-queries, we have to go get fresh data anyway from the API, so why not just trim the DB? So the result of this is that this table only ever contains the book/library combinations that users have searched for in the past 24h. Thus keeping the table small and my costs down.
  • The kindleunlimited table keeps track of a book's Kindle Unlimited status. Getting this info is expensive (time-wise) so I cache this info in the DB too, much like the OverDrive info.

One of the nice things about the simplicity of the database is that there is no need to backup the data. If the data is lost, it just gets recreated as the site is used. I may want to rethink that as I start gathering stats.