OverReader Tech
Tech Stack
For my fellow geeks interested in how this was put together...- Coded in Java using Spring Boot and Thymeleaf
- Database is currently file-based h2, though I can switch it to something else like mysql if I need to.
- Some OverDrive/Libby library data courtesy of u/coolopalhues
- Bootstrap is used for the UI
- Search results layout is based on Start Bootstrap - Shop
- Multisearch code is from jQuery UI MultiSearch
- Hosted on AWS Lightsail
- Code is stored in a private repo on GitHub.
- Github is used for issue tracking
- Coded using Eclipse as my IDE
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.
- The bookstatus table holds the library 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 a bit, 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 a certain amount of time. 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 recent past. 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 library 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.