Hey folks! I'm diving into a project using Go Fiber for my backend and PostgreSQL as my database. Since I'm not the best with architecturing and deploying software, I have a simple question about structuring my local development environment. I'd like to use a monorepo and run everything with Docker Compose in one go. Here's my proposed directory structure:
```
app/
├── backend/ # Go Fiber app
│ ├── main.go
│ ├── go.mod
│ └── ... (handlers, routes, etc.)
├── db/ # DB schema and seed scripts
│ ├── init.sql # Full init script (schema + seed)
│ └── migrations/ # Versioned SQL migrations
│ └── 001_create_tables.sql
├── docker/ # Docker-related setup
│ ├── backend.Dockerfile
│ └── db-init-check.sh # Entrypoint to initialize DB if empty
├── .env # Environment variables
├── docker-compose.yml
└── README.md
```
Now, I'm a bit confused about running everything for local development.
1) Should I just run everything manually, or stick with Docker Compose even for my development environment? I plan to use Docker Compose for testing, but I'm wondering what's best for actual development.
2) Where should the .env file go? I want it to hold PostgreSQL credentials for the Go server. Should it be in the project root for easy Docker Compose access, or in the /backend directory to make local development smoother since I'd be working in that folder with my IDE?
Any insights would be greatly appreciated!
1 Answer
I've dealt with similar setups, and here are some tips:
1. Avoid trying to handle everything with Docker during development. Unless you're using an editor that supports dev containers smoothly, it can complicate things since you'll be working locally but acting like it's remote.
2. Use Docker primarily for dependencies that aren't part of your core project. For example, run PostgreSQL through Docker but develop your Go code directly on your host machine. Map the ports so everything's accessible.
3. It’s easier to manage your .env settings in the Docker Compose file rather than sharing one across different services. Keep a project-specific .env file and create a .env.example for others to base their own on.
4. Utilize tools like Make or bash scripts to streamline commands. It's less messy that way and makes onboarding easier.
5. Not every developer will want to use Docker; some might prefer running PostgreSQL locally, which could be better in certain scenarios.
6. Don’t stress too much about achieving a perfect local setup. Use your CI environment for checks—your local setups will never match perfectly across all developers anyway.
In summary, simplify things: keep your Go app running directly on your host and use Docker just for external services.
Thanks for breaking this down! You've definitely helped me see that I shouldn't aim for a super complicated setup for local development. Running my Go server and PostgreSQL natively makes more sense, especially for debugging!