Introducing db_logger

Over the last couple of weeks, I have been modernizing the codebase of the EndBASIC cloud service by applying many of the learnings I got from the development of EndTRACKER. The latter was a fork of the former and thus the foundations were the same, but as I iterated on the latter more recently, I got to refine my approach to writing a REST API in Rust.

During this refactoring process, there was a small piece of the system that routinely got in the way for various reasons. This piece was the “database logger”.

You see, before shipping the EndBASIC service, I wanted to ensure I had the ability to troubleshoot any problems thar arose after the launch. This meant having easy access to the verbose logs that many Rust crates emit—something that’s not easily doable from an Azure Function. I researched this topic a bit more and found that Azure provides its own native logging facilities, but I did not want to integrate with them: the process seemed complex without having first-class SDK support, the service seemed overkill for my needs, and I did not want to tie my code to a specific cloud provider too much.

So, instead, and as a fun (and frustrating) exercise, I chose the path of implementing a custom logging facility. I wrote a module to hook into Rust’s de-facto standard logging library (the log create) and save any logs emitted into a PostgreSQL database or an SQLite database.

From the inception of this logging code, I thought of making it public as its own crate, but I felt that it was unnecessary at the time. But because it was now getting in the way of my refactoring attempts, I decided to take this step as a way of “hiding the complexity elsewhere”. And thus db_logger was born last week.

To create the db_logger, I ripped out the logging code from the EndBASIC service verbatim. I could have published it “as it was”, but there were many rough edges that were bothering me. So I spent last week cleaning the code up and trying to conquer some of the refactoring difficulties I previously encountered. I finally succeeded at that after a few head-scratching mornings, so expect a future blog post on the topic of “public traits and leakage of internal types”.

Things are not perfect yet and there are many limitations, but I feel that the code is now in a reasonably good shape to cut a first release. Be aware that this crate might be a “dead end” and thus there might not be many more releases after this: I would have approached logging very differently last year if I knew what I know now, and I might pursue those alternate approaches next. That said, I can imagine db_logger being useful to some other people already.

Head to https://github.com/jmmv/db_logger for more details!