Continuing from the previous chapter, I finally decided on the tech stack to build the system. I though choosing the path would be the hardest part. Turn out, walking it was even harder. Once the tools were set, I realized how much I didn’t know.
💭 Struggle from the Start
When I finally decided on the tech stack and started building, the real struggle began — not in the code, but in my mind. Every decision came with the question: Was this the right choice? Should I have done something differently?. That kind of uncertainty is probably familiar to anyone learning on their own. You never quite know if you’re moving forward or just wandering in circles. For me, it was even worse — this was a whole new domain, and I constantly felt insecure about every step I took.
🧱 Building from the Ground Up
When I started this project, I didn’t have to learn the everything from scratch. I already had some experience using Git — committing, pushing, merging — all that stuff. So this time, managing the source code on Github felt more natural, I knew how to handle branches and updates, though that whole branching process… well. that’s another story — I’ll tell you about later.
Back to the main story.
I focused on building the system with a multi-layer architecture so I could clearly understand what each layer was responsible for.
When I work with Express, the folder structure was flexible — maybe too flexible. You could organize it however you wanted, and it still worked. At that time, my main focus was frontend with React, so I only touched the backend just enough to make things run. Most of what I knew came from what others showed me or from small class projects. I understood the basic idea of separating routes, controllers and models — but only on the surface. I didn’t really understand why they existed or how they were supposed to connect. I just followed what I was told and made it work somehow.
Then I moved to Spring, and that’s when everything started to click. The framework didn’t force any structure, but as I went through tutorials and open-source projects. I began to notice a clear pattern — controller, service, repository, entity. Each one had its own clear purpose. That was the first time I truly understood what a layers architecture meant. That changed how I looked at backend development completely — from “just make it run” to “make it make sense”.
🪜A Foundation to Build On & Next
That was the moment things finally started to make sense.
And the next step? Going deeper — down to the repository (database) layer.