Release the Sauce
This was our project for the Software Engineering 2 module. The task was to build a recipe platform aimed at students using Spring Boot as the backend framework, which none of us had worked with before. The point was explicitly to practise picking up an unfamiliar technology and building something real with it.
Visual Overview
The backend is written in Kotlin with Spring Boot 3 and follows Clean Architecture strictly, with separate modules for domain logic, use cases, persistence and the web layer. None of these layers know about each other except through defined interfaces, which made the codebase noticeably easier to test and reason about as it grew. Authentication runs via JWT, the database is MariaDB, and the API is fully documented through SpringDoc with a live Swagger UI. Tests are written with Kotest and cover both unit and integration scenarios per use case.
The frontend is a Vue 3 and TypeScript app with Pinia for state management and a fully auto-generated, type-safe API client derived from the OpenAPI spec. This meant the contract between backend and frontend was always explicit so if something changed in the API, the frontend build would break rather than silently misbehave. The recipe overview supports search by name, tag filtering and sorting by popularity, duration or difficulty. Logged-in users can create and edit their own recipes with image uploads, mark favourites, rate recipes and manage their profile.
The whole application is deployed via a GitLab CI/CD pipeline with build, test and deploy stages, and was running publicly at releasethesauce.de until recently.
Our architecture choices was more deliberate than the task strictly required. Clean Architecture on a student project is a bit over-engineered by most definitions, but it was worth it as a learning exercise because it forced us to think carefully about where logic actually belongs.
We also ran the project properly with Scrum, meaning we worked in sprints, kept a backlog, and did regular reviews to check what was actually done versus what we had planned. It added some overhead, but it made a real difference in how we stayed coordinated, especially since the backend and frontend work often had to move in sync.