Project Log: Lessons Learned In Building a Meeting Room Booking System - Part 1

Preface

Recently, I have developed a meeting room booking system (ughhh this is like a todo list app) for my peers that is already in use. I thought I would use this chance to document my journey, thought processes, and lessons learned.

At the same time, I am quite sure most people will be bored of articles like this, so please feel free to skip this if this does not interest you.

However, I do personally enjoy reading such blogs about how software are designed and the thought processes behind it. I hope that this series of articles (or ramblings) will be helpful, especially for students starting out.

If you are reading this till the end, thank you very much. :)

Introduction

Not too long ago, I have been on a passionate grind on learning C++, a language that is used in so many applications around us, yet surprisingly absent from my coursework. I wanted to practice my skills by building a real-world application - one that people use. A quick project that should take not more than a week.

Enter: the North Hill Meeting Room Booking System (or MRBS for short).

The Legacy Application

To give a little bit of background, my school offers meeting rooms that are shared by students across cohorts. To coordinate the usage of the meeting rooms, we use a web app to book the meeting rooms.

The interface was anything but polished, and the experience was poor. Opening the application from a cold start took around 3 seconds, and there is a noticeable (to me at least) lag when placing bookings.

To give an example, this is how the interface looked like (unfortunately I was not wise enough to take a screenshot of the original interface before taking it down).

I did some digging and surprise (nah not really) the original application was built with php and held together with a thousand band-aids. I am sure there is not a single person who knows php development among my course, so this application is definitely unmaintainable.

I thought to myself: "Perfect! A perfect chance to practice what I have been learning so far and build a much better replacement."

The Initial Idea

The initial idea was very system. A C++ backend server to handle booking creation and user management. A frontend built using React, most likely with Vite (Next.JS is an overkill).

Of course I am not going to build the server from scratch, that would be a mammoth task and risk security vulnerabilities. I knew from experience (FYP) that I needed to look for a web framework.

After some searching, I settled for Drogon. Drogon is a HTTP application framework that also includes a lightweight ORM implementation - convenient as I do not have to look for a database library. The author of the Drogon framework also happens to be the one that posts really good solutions on the Leetcode dailies.

Scaffolding the Application

Not gonna lie, setting up the framework and getting it to work on my machine was a huge pain. In my head, I envisioned a simple project that will take at most a week to complete. However, setting up the framework and learning it took me almost a full week.

I managed to build a simple web server that can:

• Create new bookings
• Fetch a list of all bookings
• Login through a super simple login endpoint

Maintainability

I was about 20% done with this (maybe even less) when I had a moment of clarity - how are my juniors going to maintain this?

Sure, building this in C++ will be useful to my portfolio. It will be useful in showcasing what I am capable of, and a chance to write production quality code.

However at the same time, I also realized that building this in C++ will be relatively unmaintainable, considering the steep learning curve of the language.

After some pondering, I decided to make a switch in the backend to use Golang, another popular backend language instead.

Yes, there is still a learning curve, but it will be a lot easier to maintain than C++. Plus, many companies such as Google and Bytedance are using it too, so I do expect to have peers to already have some familiarity with the language.

Side note: of course the most practical choice would be to use Python and FastAPI from the start. But there will be no value add to my learning.

Gin Gonic

Leveraging my experience from my Final Year Project, I built the backend using Gin, a full featured web framework for Go. Instead of writing raw SQL statements, I used Gorm, a Object-Relational Mapping manager for Go.

My vision is a lightweight application that will handle the logic and serve the static webpages.

Sneak peek

After about 3 weeks of rigorous testing, here is the new interface (which I personally think is better than the original):

In hindsight, I should've taken the screenshot in light mode. But oh wells.

What's next

Over the next few chapters, I aim to talk about:

1. How I migrated from the old schema to the new one, while preserving bookings
2. How I deployed the application

Future Plans

This application is already deployed and in use, but I do have future plans for it:

• Telegram bot to handle bookings
• SSO login