MingPV/clean-go-template

This system is a Go backend application template built on Clean Architecture principles, providing a foundational structure for developing microservices. It supports concurrent REST (via Fiber) and gRPC interfaces to manage Order and User entities, with data persistence handled by PostgreSQL through GORM. The system includes built-in JWT authentication, centralized configuration, and standardized error handling to facilitate secure and consistent API development.

The application now includes middleware to handle cross-origin requests and logging, as well as a new JWT-based authentication mechanism. The common middleware (fiber.go) initializes request logging and CORS settings, while the JWT middleware (jwt.go) validates Bearer tokens from the Authorization header using a secret stored in the JWT\_SECRET environment variable, extracting the user ID for subsequent use in the request context.

pkg/middleware · high confidence

This change introduces the protocol buffer definitions and generated Go code for the Order service. The \order.proto\ file defines the \OrderService\ with RPCs for creating, finding (by ID and all), patching, and deleting orders, along with the corresponding request and response message structures. The generated \order.pb.go\ and \order\_grpc.pb.go\ files provide the Go types and client/server interfaces required to implement and consume this gRPC service.

proto · high confidence

The application now supports running a gRPC server alongside the existing REST server, with both listening on configurable ports defined in the application config. A new utility function handles graceful shutdown by listening for SIGINT and SIGTERM signals, ensuring that registered cleanup functions are executed before the process exits, providing a cleaner termination process for both server types.

utils · high confidence

This change introduces the complete initial structure for a Go backend application built on Clean Architecture principles. It provides a ready-to-use template featuring Fiber v2 for HTTP handling, GORM with PostgreSQL for data persistence, and gRPC for RPC communication. The release includes a Docker Compose setup for both development and test database environments, a shell script to automate project renaming, Swagger API documentation generation, and a comprehensive README with setup instructions. It also establishes the foundational configuration via a .env.example file and an MIT license.

(repo-wide) · high confidence

Added new Data Transfer Objects (DTOs) for the order domain, including a CreateOrderRequest with validation for the total amount, an OrderResponse exposing ID and total, and a mapper to convert internal Order entities into these response structures.

internal/order/dto · high confidence

The application now includes a dedicated database package that establishes a connection to a PostgreSQL database using GORM and provides a helper for setting up isolated test environments. The main module exposes functions to connect to the database via a DSN and gracefully close the connection pool, while the test helper automatically loads environment variables, connects to a test database, runs auto-migrations for User and Order entities, and ensures table cleanup before and after each test to maintain state isolation.

pkg/database · high confidence

The application now uses a dedicated configuration module to manage environment-specific settings. This change introduces a \LoadConfig\ function that reads values from \.env\ files (supporting environment-specific variants like \.env.development\) and falls back to system environment variables. It centralizes the setup for application ports, database connection details (host, port, user, password, name), and JWT authentication parameters (secret and expiration), automatically constructing the database DSN string from these components.

pkg/config · high confidence

Added new handler implementations for the order service, providing both gRPC and HTTP (Fiber) interfaces. The gRPC handler exposes standard CRUD operations (Create, FindByID, FindAll, Patch, Delete) and maps application errors to gRPC status codes. The REST handler exposes corresponding endpoints for creating, retrieving, updating, and deleting orders, including input validation for partial updates to ensure the order total is positive.

internal/order/handler · high confidence

The internal/user module now exposes a complete REST API for user lifecycle management, including registration, login, retrieval, partial updates, and deletion. The handler layer implements PATCH /users/{id} to update a user's name and DELETE /users/{id} to remove a user, in addition to existing GET and POST endpoints. DTOs define the request and response structures, while the GORM repository and use case layers enforce password hashing, JWT token generation, and proper error handling for these new operations.

internal/user · high confidence

The OrderRepository interface, which previously defined methods for saving, finding, patching, and deleting orders within the usecases package, has been removed from the codebase.

usecases · high confidence

The application entry point has been restructured to initialize and start both a Fiber-based REST API and a gRPC server simultaneously. The new setup logic wires the database and configuration dependencies to both server instances, registers the order service handler for gRPC, and manages graceful shutdown for both services together.

internal/app · high confidence

The order repository implementation has been restructured to return pointers to Order entities instead of value types for FindByID and FindAll, ensuring consistent handling of entity references. Additionally, the Patch and Delete operations now explicitly check for zero rows affected and return gorm.ErrRecordNotFound, providing clearer error semantics when operations target non-existent records.

internal/order/repository · high confidence

The routing layer in pkg/routes has been reorganized into distinct public and private route handlers. Public routes under /api/v1 now include user management (GET, PATCH, DELETE), order management (GET, POST, PATCH, DELETE), and authentication endpoints (POST /signup, POST /signin). A custom 404 handler has been added to return JSON error responses for unknown endpoints, and Swagger documentation is exposed at /api/v1/docs. Private routes under /api/v1 are protected by JWT middleware and expose a /me endpoint for the authenticated user.

pkg/routes · high confidence

The Order Use Case has been restructured within the internal package, moving the implementation to a new interface definition and updating method signatures to return pointers to Order entities rather than values. The PatchOrder method now returns the updated order object instead of a simple error, allowing callers to access the final state after modification. Additionally, a full test suite was added to verify order creation, retrieval, patching, and deletion behaviors, including edge cases like not-found records and zero totals.

internal/order/usecase · high confidence

The HTTP handler for order operations (create, find, patch, delete) has been removed from the adapters layer. This eliminates the direct Fiber-based request processing logic for orders, indicating that order handling is being migrated to a different adapter or implementation strategy.

adapters · high confidence

The project structure has been reorganized to follow a cleaner architecture. The application entry point is now located at cmd/app/main.go, which initializes the server via the internal/app package. Additionally, a new User entity has been introduced in internal/entities/user.go, defining fields for ID, Email, Password, and Name, with automatic UUID generation on creation. The existing Order entity has been moved from the root entities directory to internal/entities to align with the new internal package structure.

cmd, internal/entities · medium confidence

The application now uses a centralized error-handling mechanism that maps internal application errors to specific HTTP status codes and gRPC codes. This ensures that API responses consistently include structured error information, with dedicated response types for both error messages and general success messages, improving clarity and consistency for API consumers.

pkg/responses · high confidence

The project's Go module dependencies have been updated, notably adding gRPC support (google.golang.org/grpc v1.72.2) and Swagger integration (github.com/gofiber/contrib/swagger v1.3.0). The Fiber framework dependency was explicitly added as v2 (github.com/gofiber/fiber/v2 v2.52.8), aligning with the commit message to downgrade from v3. Several indirect dependencies were also updated or added, including gorm.io/gorm v1.26.1 and golang.org/x/crypto v0.38.0, while some older indirect dependencies were removed.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 56 → 58 (+1.7)
• Rubric changed (rubric-2026.08.17 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 100 → 99 (-0.3)
• Architecture 100 → 69 (-31.0)
• Maturity 90 → 69 (-21.1)
• Readiness 43 → 45 (+2.1)
• Security 60 → 82 (+22.3)
• Domain Modelling 57 → 65 (+7.2)

• Coverage not included — suite not readable by the collector
• Dependency hygiene not measured — no supported dependency manifest was read
• Duplicated block (5 lines × 2) (pkg/apperror/apperror.go)
• Further orphaned files (smaller)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• LLM evaluation failed
• Low: security finding (details withheld)
• Low: security finding (details withheld)
• No exposed public API
• Test reliability not included
• single-maintainer — knowledge-concentration (bus factor) risk

• Critical CVE: [GHSA redacted] (go.mod)
• Critical CVE: [GHSA redacted] (go.mod)
• Critical CVE: [GHSA redacted] (go.mod)
• Critical CVE: [GHSA redacted] (go.mod)
• Documentation: no installation or build instructions (README.md)
• Documentation: no usage examples (README.md)
• Duplicated block (10 lines × 2) (internal/order/repository/gorm_order_repository.go)
• Duplicated block (6 lines × 2) (pkg/apperror/apperror.go)
• Duplicated block (8 lines × 2) (internal/order/handler/rest/handler.go)
• High IaC: WD-COMPOSE-0002 (docker-compose.yaml)
• High IaC: WD-COMPOSE-0002 (docker-compose.yaml)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• …and 24 more

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

MingPV/clean-go-template was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.