Wheel
Streamlined inspection and approval process
TL;DR
In order to automate administrative tasks for the NUS Cycling Club, I built a fullstack web application with Rust, Tokio, and Axum on the backend and SolidJS on the frontend. The platform had to check data across multiple different spreadsheets and APIs, and generate reports for the teammembers to review. The application was used for two years while I was in the club, and handled hundreds of signups automatically without any major hiccups. It reduced the amount of time needed to handle event signups by 75%.
My first production fullstack app
A bit of background for this one — I joined the NUS Cycling club in my second semester of university. The club was still new at the time (it was founded at the same time I matriculated).
And I had a rather lovely time as one of the members working under the administrative team, but the process that they'd come up with to collect signups, vet their physical fitness, and check their ticket puchase status was way too slow for my taste. I never did any formal measurements, but the amount of time it took to process each signup was somewhere in the ten minute range, and with over thirty students signing up for our events each month, it was a lot of work to handle it all.
Enter me, a first year computing student whose eyes were still bright and full of passion, whose mind was still filled with hope that his code would go on to do great things (and then ChatGPT was released).
The Tech Stack
The original tech stack was Rust with Tokio (asynchronous I/O library) and Axum (web framework) on the backend, and SvelteKit on the frontend. However, I was soon frustrated by the Svelte framework and eventually made an early switch to use SolidJS. This switch also brought my app inline with the industry standard of preferring whatever JavaScript framework was new and popular that month. I also utilized Bulma on the frontend for quick styling, since this app was supposed to be function over form.
The Goals
I wanted to build a web app that would handle most of the heavy lifting, and only require human intervention when verifying that the participant didn't report any debilitating illnessess that might prevent them from safely enjoying the event. There were three main parts of the process that I wanted to automate. Number one, I wanted to make the health check easier by highlighting potential issues to a reviewer. Secondly, I wanted to automate the sending of payment collection emails. Finally, I wanted to automate the checking of payment status, consolidating all participant information into a single spreadsheet.
The Outcomes
Automatic email sending - the bulk of the time savings
Over the next month, I worked diligently on my free time to build this application. I did the whole nine yards, checking in with my team to make sure they know how the app works and making sure they were okay with the direction I was taking the development. After about fifty hours of work, we finally got to deploy it and use it for a real event. I used my free DigitalOcean credits to host the server, and surprisingly, everything went smoothly during the first trial use. I was able to complete the tasks that would have usually taken the entire team.
Automatic payment collection - automating NUS's antiquated FastPay system
I also spent a decent chunk of time on documentation, ensuring that people would be able to utilize the software without my intervention. Sadly, after I left the club, nobody wanted to pay for VPS hosting, so we just let the project die in favor of completely simplifying our signup process to no longer require manually emailing participants.
The Lessons
The way I implemented per-event customization, including things like price, promo codes, banlists (yes, we had to ban some people from our events), etc. was pretty lackluster. I allowed users to upload scripts written in a DSL to handle special logic, but this was obviously very unfriendly to people who aren't familiar with programming. The assumption was that there would always be some computing students who could take up the mantle, but I realize that good apps usually need user-friendly options on top of their customizability.
The Conclusions
Writing this app was a lot of work, and it wasn't particularly interesting. It felt good to finally be working on a project with practical value, but it lacked some of the spark that my more freestyle projects had. All the same, it taught me a lot about the nuances of writing code that you expect other people to use, and I think that experience is pretty valuable for doing software engineering in the workplace.