My Singapore Library App Is Live!

Photo by Anna Hunko on Unsplash

I finally deployed my Singapore library app on a web server for anyone to use! My app provides a view of the Singapore library books that are saved by the user, and shows which libraries these saved books are at. I have wanted this feature for a long time, I have been working on this on and off since 2021 to have the service for myself : 1st, 2nd and 3rd posts. As of August 2023, this feature is still not available on the NLB app yet, which gives me the incentive to launch this web app to the world!

If you live in Singapore and love to bookmark and borrow a lot of physical library books in person like me, this web app makes it easier to track which libraries these books are available.

Fig 1 — The single view of all saved SG library books

In this post, I will discuss the considerations and functionalities of my web app, and I hope to entice some people to try my app out for free!

PS: As I am on a free web server tier for this side project, the site may take awhile to load, so please be patient. If enough users register and use my app, I will consider paying the USD 7 Starter package to make the site more stable.

1. User Registration and Login

Users need to register an account and login in order to add and track NLB library books with the app. I will want to eventually add more account related functionalities like resetting passwords and deleting accounts.

Fig 2 — The Registration and Login Page

2. NavBar (Top Bar)

Once you have an account and login, there is a navigation bar on top that shows the main features of the app. From left to right, the functionalities on the navbar are:

1. Main page that shows availability of all saved books
2. Filter to show saved books from a specific library
3. All saved books
4. A book search page to add NLB books
5. Button to update availabilities of all saved books
6. Logout button
7. Search box to search within books’ availability and books saved tables

Fig 3 — The navbar

3. Summary of library books

This summary view shows a few things:

1. Total books saved and available
2. Top 5 libraries by unique available saved books

Fig 4 — Summary view

4. Books availability

This table shows all the books saved by the user, which libraries these books are at, and whether they are available or on loan. Within this table, I include the time when the book’s availability was last updated, and a button to update the book’s availability. The user can filter for specific libraries that they are in. Data is extracted directly from the NLB API.

Fig 5 — Tells you if your book is available at a library

Fig 6 — Selecting a single library will show the available and saved books for that library

5. Books Saved

I included a section to show the user what books he has saved.

Fig 7 — Finished reading a book? Just delete it from the app

6. Search and adding library books into the app

This page allows the user to search and add books into the app. The search information shown here is also from the NLB API.

Fig 8— Search bar to find books in the NLB database

Fig 9— Results returned from a title search

PS: I previously had a feature on my app that scraps the users’ NLB account for their saved books. This will make it easier for the user to add their saved books directly from the NLB app, rather than have to add the books one by one through this feature. Unfortunately, it has been increasingly difficult to ensure the stability of the web scraper and hence, I have decided to kill off that feature.

Some Concluding Thoughts

My web app is very barebones and isn’t very aesthetically pleasing, but I am happy that as a self-taught programmer with no UI / UX training, I managed to build up a tech solution so that when I am at a library, I know which of my saved books are available for me to borrow.

Regardless of the output so far, building the web app has been a great experience learning, from implementing my backend and frontend using FastAPI, setting up the user authentication flow with FastAPI Login, migrating my data from a local SQLite database to a cloud database, and finally deploying my app on Render to surface it to the rest of the world.

As a freelancer, such a side project gives me many opportunities to learn how to think about creating software to deal with a real-world problem. This helps me understand how to better structure my solutions for my clients. For example, I am appreciating why a backend engineer is more keen on the performance and efficiency of their operational database, while the analytics person in me is worrying how I should capture and store all the data for future product analytics. The CFO in me, however, wouldn’t be so happy about the costs required to store all the data, just for potential future analytics

I also want to thank the IT folks from the NLB for creating and providing to the public their APIs. I am really glad that the team has shifted to a REST API over the legacy SOAP API too.

I will continue to use and improve this app, as long as I am continuing to borrow library books in Singapore. I still have a lot of features in my head that I want to implement, including deploying an analytics tracking service on my app to understand how my users are using my app, deploying the app on a different hosting platform (Google Firebase), figuring out how to run some data engineering jobs to allow more robust analytics to happen, and maybe even learning how to use a JavaScript framework for my frontend instead (I am looking at Vue over React).

In the meantime, I am happy to hear any constructive user feedback.

Appendix — My Tech Stack

Did I have to mention that currently, my entire tech stack is free? Some of the tools like Python, FastAPI and the NLB REST API are just free / open-source tools. The other technologies, namely MongoDB (cloud NoSQL), Render (web server) and Mixpanel (user / product analytics tracking) are all implemented under their respective freemium tiers (means they are free for now!)

1. NLB API — My very first app iteration had me scraping the NLB website for the data I need, but I have officially stopped using any scraper due to its instability. Before that I also started to use the NLB SOAP service, but I had to migrate to their REST API service recently too. While I had to do more work to migrate the code, I personally still prefer to work with a REST API over a SOAP one.
2. FastAPI — This provides both the backend and frontend components of my app. Most of my code is written in Python, with FastAPI handling my backend processes and endpoints. My frontend is made up of Jinja2, basic HTML and one piece of JavaScript code that I copied from the internet.
3. MongoDB — When shifting from a local to cloud deployment, I shifted my database choice from SQLite to MongoDB. MongoDB didn’t require a lot to set up, and their free tier is relatively generous and performant. I can totally understand why people use MongoDB for application developments, while as a data analyst, I can understand why MongoDB shouldn’t be used for large-scale analytics. This is something that I will explore as I plan to further expand the feature scope of my web app.
4. Render — I wanted a web server with a generous free tier to deploy and test my app’s functionalities. Render was really easy to use (I have no DevOps experience previously) and it allowed me to quickly deploy through Github. I am on its’ freemium tier here.
5. Mixpanel — Just as I deployed my app and wanted to share it to the world, I decided to spend a few more days adding some user / product analytics tracking using Mixpanel. While I was an Mixpanel implementation consultant previously, I never implemented the Mixpanel integration code from scratch. It’s Python documentation was a tad confusing, and it did take me awhile to figure out, but I was glad I got it to work after all. In particular, it was great to know that Mixpanel currently has a 100K Monthly Active User (MTU) freemium tier. So unless I get 100K registered users, I wouldn’t need to pay for Mixpanel’s implementation! Yeah!