ChronoFlow covers the scheduling side of a team’s week: meetings, deadlines, leave requests, and the approval chain that sits behind all three. I wrote both halves of it, the Spring Boot service and the browser client, over about two months in 2025.
How it fits together
The backend exposes a REST API per workflow, each one backed by its own tables in a MySQL schema I normalized up front. Scheduling data duplicates itself easily once you allow recurring meetings and shared attendees, and the schema was the place to stop that happening.
The site is plain HTML, CSS and JavaScript with no framework. That was a deliberate constraint, and it held up better than I expected: a dashboard with a persistent sidebar, modal flows for creating and editing meetings, live participant search, and validation that runs before anything is submitted. Every screen calls the same API the rest of the system does.
Access control runs on JWTs with roles attached. There are three tiers of user and they genuinely see different records, so the checks live in the service layer where they cannot be bypassed by anyone who knows the URL.
Where the time went
Most of it went into the schedule views. They read across three tables and got noticeably slow under peak-load testing, well before the row counts justified it. Reading the execution plans showed the indexes I had added were the wrong shape for the queries the views were actually issuing. Rebuilding them took read latency down by 30% at the same load.
What I would change
The client has no build step, which means shared behaviour gets copied between pages more often than I would like. A thin component layer would collapse most of that duplication, and it would not require adopting a framework to get it.
