Go project structure -- cmd/internal layout, handler/service/repository layers, Makefile, config from environment, domain error types, test placement, dependency injection
90
84%
Does it follow best practices?
Impact
100%
1.02xAverage score across 5 eval scenarios
Passed
No known issues
A SaaS company needs a user authentication microservice in Go. The service handles user registration, login (returning JWT tokens), and profile retrieval. It stores user data in a database and hashes passwords with bcrypt. The JWT signing key and database credentials must come from environment configuration.
The team wants clean architecture so different developers can work on handlers, business logic, and database code independently.
Produce a complete project structure with:
go.mod with proper module pathcmd/auth/main.go -- entry point that creates database connection, wires repository -> service -> handler, and starts HTTP server with graceful shutdowninternal/config/config.go -- Config with PORT, DATABASE_URL, JWT_SECRET, JWT_EXPIRY_HOURS, LOG_LEVEL from environmentinternal/domain/models.go -- User (ID, Email, HashedPassword, Name, CreatedAt, UpdatedAt), RegisterRequest, LoginRequest, LoginResponse (with Token field), UserResponse (without password)internal/domain/errors.go -- AppError, NotFoundError, ValidationError, UnauthorizedError, ConflictError (duplicate email)internal/handler/ -- Handler struct, route registration, endpoints: POST /register, POST /login, GET /me (protected), writeJSON/writeError helpers, auth middleware that validates JWTinternal/service/auth.go -- AuthService with Register (hash password, check duplicate), Login (verify password, generate JWT), GetUser; defines UserRepository interfaceinternal/repository/users.go -- UserRepo implementing UserRepository with SQL queriesMakefile with build, run, test, lint, tidy targets.gitignore for Gointernal/service/auth_test.go with table-driven tests for registration validation (empty email, duplicate email) and login (wrong password, success)