Heirloom Database

Bradley Gannon


Some older people in my family own a house that contains a lot of old stuff. A subset of that stuff has associated family history and sentimental value, but the only people who know it are the oldest members of my family. The younger people in my family (like me) don’t have much of a clue what’s valuable and what isn’t, and someday when the older people have died, their knowledge may be lost forever. In that case, those of us who remained alive would have to guess the value of these items based on scraps of conversations, context, and intuition. We certainly wouldn’t know the details of any stories attached to the items, which contain a good portion of their personal value.

My family identified this issue a few months ago, and I recently took on the task of designing and building a simple system to collect and store this important data. The system more or less needs to be a simple CRUD app with mobile photo capture. I started the project by defining a few design goals:

The result is a Web application that accepts photos from a mobile device and a text caption for each item of interest. Users can view, edit, or delete existing entries. Mobile photo capture is accomplished with

<input type="file" capture="environment" />

which sends the user to a native camera interface to capture their photo.

The Web server is a single Python file relying on the aiohttp library. It has a handful of endpoints for the typical CRUD tasks and serves templated HTML with jinja. There is no separate database. Instead, the server stores images and their captions in directories on the filesystem. User authentication is provided with HTTP Basic Auth, although all users must share a set of credentials2.

The frontend uses CSS grid to lay out the main view and HTML form elements for CRUD operations. The style is underwhelming but functional. There are a few lines of vanilla JavaScript that provide a preview of the user’s photo before uploading it. The app does not require JavaScript in order to function.

As for deployment, I stole a basic Dockerfile from ChatGPT, so the server can be deployed on the host OS or under Docker3. The server supports using a custom URL slug, meaning that if you want to serve the app on /heirlooms instead of /, you can set that in the config file and it’ll “just work”. The config file itself is a file containing key-value pairs separated by =.

I didn’t learn as much as I could have in this project, but that wasn’t the main goal anyway. Normally I like to use personal projects as motivation for overcoming the confusion and discomfort associated with learning something new, but what I really needed from this project was a finished system that would work reliably for my family. In that sense, I see this project as an application of my knowledge rather than an opportunity to gather more.

As my family begins to use the application, I’m sure that little tweaks and improvements will be necessary. For example, it’s already becoming clear that there will need to be some kind of pagination, sorting, filtering, or directory system in order to handle a large number of records. If/when that additional work begins, I intend to maintain the design goals I set above.

  1. This point is especially important because the system may need to run for many years as my family slowly adds information. The system should also store the data in a format that I can expect to be usable in the future.

  2. This is meant to provide family privacy, not a robust user auth scheme. The app doesn’t know anything about individual users and doesn’t need to.

  3. In both cases, a reverse proxy is a good idea.