EventHub

"EventHub" is a full-stack web application for campus events, built by a team of six as a university project. Students can browse events and RSVP, clubs can publish and manage their own, and admins look after users and events. We built it with Java, Spring Boot and MySQL, working in Scrum across three sprints with a product owner. I worked as a full-stack developer, and most of what a student sees and uses was my work: the header, browsing, RSVPs, their bookings, and every notification and email the app sends.

Browsing and booking

I developed the Browse Events page, where students can find every upcoming and past event. It includes a search that matches event names, organisers and keywords, as well as filters for tags and dates. I also built the RSVP functionality behind it. Once a student confirms their RSVP, the booking is saved and they receive a confirmation email along with a notification in the app.

My Bookings and check-in

On the My Bookings page, students can see every event they have booked and cancel any of them. Each booking has its own QR code that works as a check-in link for that student and event. Scanning it at the door checks them in, and the scan is rejected if they never RSVP'd.

Notifications and email

All of the notification and email features were my work. The bell in the header shows how many unread notifications a student has and opens a panel where they can mark them as read, with a small REST API behind it that the page checks every 30 seconds. For email, I used Spring's JavaMailSender to send a confirmation as soon as someone RSVPs, and a reminder the day before each event from a scheduled job that runs every morning.

Architecture and the pipeline

I was also responsible for the system and pipeline architecture. I designed the system in three tiers following the MVC pattern, with the app containerised in Docker so it runs the same way for everyone. The pipeline runs on GitHub Actions: every push and pull request runs the full test suite, the production image is only built once the tests pass, and a final job reports exactly what failed.

Planning and retrospectives

Along with the development work, I was in charge of our project planning and retrospectives. At the start of each sprint, we picked the user stories we would work on and estimated each one in story points, then tracked everything on our GitHub Project board. At the end of each sprint, we held a retrospective to look back at what went well and what we could do better next time. We also met three times a week for short standups, where we checked in on each other's progress and split up the tasks.

What I learnt

With six of us working in one codebase, EventHub taught me that on a project this size, how a team works together matters as much as the code. Early on, as more of us worked on connected parts of the app, merge conflicts took far longer to fix than we expected. We learnt to merge little and often, and to agree on API endpoints and data structures before anyone started building. The specification also left a lot open, which taught us to bring specific questions to our product owner early rather than guess.

Most of these lessons came out of our retrospectives. Each sprint we wrote down what we would change, such as writing tests before the code rather than alongside it, and agreeing on how to handle API keys and passwords at the very start of a project.

By the final sprint we were merging early and often, and it ran far more smoothly than the first two.