Refactoring database code out of main.go

At this point, main.go was starting to feel a bit too crowded…

After getting PostgreSQL connected and using it to store deployment status, I wanted to clean up the structure a little. I started by moving the database initialization into api/db/connection.go, changed conn into a public Conn, and added Init() plus migrate() so the connection setup no longer sits directly inside main.go.

The reason was simple… I was already starting to interact with the database from multiple places, so keeping everything in one file was beginning to feel messy. This refactor does not mean the architecture is finished, but at least now the DB connection setup has its own place.

Then I continued the cleanup by moving deployment-related queries into api/db/deployments.go. I separated things like creating a deployment, updating its status, and reading deployment data so main.go does not need to deal with those SQL queries directly anymore.

The nice result is that the flow already feels clearer. The handler can focus on starting the job, the db package handles persistence, and jobs.RunNginx() can receive the deployment ID and update its status after the Docker pull finishes.

So this was not really a frontend-visible feature… more like a small internal cleanup that made the project easier to grow. The main insight I got here is that once deployment state starts touching multiple parts of the app, leaving all database logic in main.go becomes awkward pretty quickly.