I can never remember the name of the son of my cousin (first cousin, once removed?). Heck, quite a number of my cousins are married now and I don’t always remember the name of their partners. While I don’t care too much being labelled as a “terrible human being” by my cousins, I do feel bad for their partners, even though I don’t care if they remember my name.

And if these people aren’t important, I want to at least do my best remembering the names of the partner of my friends. I wanna know if I should reconnect with a friend that I’ve not been in touch for a while. I wanna remember what I’ve did with them and not just forget about them.

It may feel like cheating, but it made me come up with this idea:

I wanna make a personal relationship manager

Hence, the idea of relman was born.

Goals of relman

relman is a darn-simple and dumb personal relationship manager system. Very little automation is involved:

• Adding new contacts is manual.
• Updating information for contacts is self-initiated (unless if it’s a no-brainer like age).
• Reminders can be set up for important events or overly long periods of non-contact for each contact.

To put simply, relman is a computerized notebook for users to jot down notes about their relationships, ready with various tools (e.g. reminder to replace overfilling a single calendar with life events) to help the user keep up with managing their relationships.

While relman is supposed to be easily translatable to what we would do when managing our personal relationships manually, the process should be made to be as easy and fluid as possible.

relman must also be private — we’re talking sensitive information being held within the confines of the app.

Initial ideas for relman

As a happy resident and consumer of FLOSS, and since relman should be a personal tool that contains sensitive and private information, I aim to make relman open source and free (as in, you can grab) as much as possible. It will be not-for-profit, but donations will be appreciated and accepted. Realistically, this does mean that I won’t be able to have anyone to work on relman full-time, under most circumstances, and I think that’s fine.

As a full stack software engineer now, my first thought was to make relman into a cloud service. However, doing so drastically increases the technical complexity that is required to meet the core goals set out for relman. As such, relman will focus on being offline, while allowing the user to easily transfer their data around if they wish to (think a single SQLite DB file, or some structured output format).

The search for a technical stack

I’ve spent many after-work-hours digging around for a suitable tech stack for creating relman. Here are a list of ideas that I’ve tried out, but decided not to pursue due to it adding too much overheadRead: It’ll take up too much of my time to learn. to the completion of an MVP (although I’ve yet to properly define the bounds of the MVP).

• Any of the Rust GUI libraries — They’re just not there yet :(
• GTK and Vala
• QT
• ReasonML (OCaml ecosystem)
• Tcl

One other big reason I did not want to invest time (at least for relman) into many of these projects is because I very much prefer the declarative style for writing GUI application, while many of them employ the imperative style. It quickly becomes rather awkward and clunky to manage states and transfer them around in a sensible fashion This is based solely on my experience of trying them out, and having written some basic GUI projects with Java Swing in the past. Of course, I’m also very inexperienced in this side of the software world, and I know there are many successful projects out there, with a lot of people writing GUI applications in these languages while fully enjoying themselves. .

Prior to rethinking relman as an offline app, I even played around with Rocket and Actix for the backend server, and spent many hours trying to set them up with dependency injection and dug around for a good logger.

Eventually, I decided to (temporarily) settle on using Electron, despite my many opinions of it My poor computer with 8GB of RAM. . One simple reason is that I can write in a language that I am very comfortable with (JS). Another one is that I can easily support shipping the application to, say, macOS.

Since Electron is (somewhat simply put) an isolated Chromium instance, I decided that (hey) I would try working on the project using just ESM. One frontend tool that immediately sprang to mind as I think of using ESM was Vite. Needless to say, I picked Vue.js, my favorite of the existing web frontend frameworks, as the underlying framework for relman.

How’s relman now?

The project is still in its infancy.

I’m bringing in many ideas and lessons that I’ve learned (and am still learning) during my time at my current company Check out my CV for the timeline. , and filling in gaps as I slowly go through the makings of the project.

There are also many little things that I have to figure out, like

• How should I handle use configurations with the Electron/Vite setup?
• How do I store data and how should the front end reach for and query the data, since I can’t run Node.js specific code on Electron? Does IPC fill that role? Is it suitable?

relman is definitely nowhere close to a release or an MVP right now, and will likely not arrive in the next few months to a year. There is, after all, my day job and my life plans that I have to attend to. But I am rather optimistic that relman will serve as a good learning experience for a full product delivery on my own (perhaps with some help along the way).

Where can I find relman

You can find the project repository on Gitlab.

I’ve also setup a Notion page on my personal workspace to let me keep track of ideas and notes for the project. It’s not always up to date, but hopefully it gives people more depth on where the project is. Comments for the page are disabled for now.