Enhance cursor rules and add user management functionality
- Updated cursor rules to emphasize the importance of dependency injection and logging practices. - Introduced a new user management domain, including entities, services, handlers, and validation. - Implemented user authentication features such as login, registration, and role-based access control. - Added Redis integration for token management and caching. - Enhanced API documentation with Swagger for user-related endpoints. - Updated configuration to support new JWT settings and Redis connection parameters.
This commit is contained in:
n.nakhostin
+76
-31
@@ -32,6 +32,7 @@ internal/{domain}/
|
||||
- All files in a domain use the same package name for easy access
|
||||
- Repository implementations are in the same package as interfaces
|
||||
- Keep dependencies minimal and focused
|
||||
- **NO GLOBAL VARIABLES**: Everything must be injected, including validation functions
|
||||
|
||||
## 💻 Go Best Practices
|
||||
|
||||
@@ -81,6 +82,12 @@ internal/{domain}/
|
||||
|
||||
## 📝 Logging Standards
|
||||
|
||||
### Logging Location
|
||||
- **NO LOGGING IN HANDLERS**: All logging must be done in the service layer
|
||||
- Handlers should only handle HTTP concerns (validation, response formatting)
|
||||
- Service layer is responsible for all business logic logging
|
||||
- Repository layer can log database operations
|
||||
|
||||
### Using Custom Logger Interface
|
||||
- Always use structured logging with fields
|
||||
- Include relevant context (user_id, customer_id, request_id, etc.)
|
||||
@@ -93,19 +100,23 @@ internal/{domain}/
|
||||
|
||||
### Logging Examples
|
||||
```go
|
||||
// Good
|
||||
log.Info("Customer authenticated successfully", map[string]interface{}{
|
||||
"customer_id": customer.ID.String(),
|
||||
"email": customer.Email,
|
||||
"ip": clientIP,
|
||||
})
|
||||
// Service layer - GOOD
|
||||
func (s *CustomerService) CreateCustomer(ctx context.Context, req CreateCustomerRequest) (*Customer, error) {
|
||||
s.logger.Info("Creating new customer", map[string]interface{}{
|
||||
"email": req.Email,
|
||||
"company_id": req.CompanyID,
|
||||
})
|
||||
// ... business logic
|
||||
}
|
||||
|
||||
// Bad
|
||||
log.Info("Customer login")
|
||||
// Handler - BAD (no logging here)
|
||||
func (h *CustomerHandler) CreateCustomer(c *gin.Context) {
|
||||
// Only handle HTTP concerns, no logging
|
||||
}
|
||||
```
|
||||
|
||||
### Error Logging
|
||||
- Log errors with full context
|
||||
- Log errors with full context in service layer
|
||||
- Include error details and relevant fields
|
||||
- Don't log the same error multiple times in the call stack
|
||||
|
||||
@@ -153,6 +164,7 @@ log.Info("Customer login")
|
||||
- **Time Input**: Accept Unix timestamps (int64) for all time fields in requests
|
||||
- **Time Validation**: Validate Unix timestamps are within reasonable ranges
|
||||
- **Time Consistency**: All time inputs must be Unix timestamps (int64)
|
||||
- **NO LOGGING**: Handlers should not contain any logging statements
|
||||
|
||||
### Govalidator Usage
|
||||
- Use govalidator for all request validation
|
||||
@@ -161,6 +173,7 @@ log.Info("Customer login")
|
||||
- Validate at handler level before calling services
|
||||
- Return validation errors using `response.ValidationError()`
|
||||
- Use meaningful error messages for validation failures
|
||||
- **Validation Injection**: Pass validation functions as dependencies, never use global validation
|
||||
|
||||
### Response Format
|
||||
- Always use standardized response structure from `pkg/response`
|
||||
@@ -177,6 +190,40 @@ log.Info("Customer login")
|
||||
- Never log sensitive information (passwords, tokens)
|
||||
- Use HTTPS in production
|
||||
|
||||
## 📚 Documentation Standards
|
||||
|
||||
### Code Documentation
|
||||
- **Only document infrastructure and complex business logic**
|
||||
- Don't over-document simple operations
|
||||
- Document public interfaces and types that might be confusing
|
||||
- Use Go doc comments format
|
||||
- Include examples for complex functions
|
||||
- Keep comments up to date with code changes
|
||||
|
||||
### API Documentation
|
||||
- **Use Swagger/OpenAPI comments for all API endpoints**
|
||||
- Document all endpoints with examples
|
||||
- Include error response examples
|
||||
- Document authentication requirements
|
||||
- Keep Swagger documentation up to date
|
||||
|
||||
### Swagger Comment Examples
|
||||
```go
|
||||
// @Summary Create a new customer
|
||||
// @Description Create a new customer with the provided information
|
||||
// @Tags customers
|
||||
// @Accept json
|
||||
// @Produce json
|
||||
// @Param customer body CreateCustomerRequest true "Customer information"
|
||||
// @Success 201 {object} response.Response{data=Customer}
|
||||
// @Failure 400 {object} response.Response
|
||||
// @Failure 500 {object} response.Response
|
||||
// @Router /customers [post]
|
||||
func (h *CustomerHandler) CreateCustomer(c *gin.Context) {
|
||||
// Handler implementation
|
||||
}
|
||||
```
|
||||
|
||||
## 🧪 Testing Guidelines
|
||||
|
||||
### Test Structure
|
||||
@@ -229,21 +276,6 @@ log.Info("Customer login")
|
||||
- Avoid memory leaks in goroutines
|
||||
- Use sync.Pool for frequently allocated objects
|
||||
|
||||
## 📚 Documentation Standards
|
||||
|
||||
### Code Documentation
|
||||
- Write clear comments for complex business logic
|
||||
- Document all public interfaces and types
|
||||
- Use Go doc comments format
|
||||
- Include examples for complex functions
|
||||
- Keep comments up to date with code changes
|
||||
|
||||
### API Documentation
|
||||
- Use OpenAPI/Swagger annotations
|
||||
- Document all endpoints with examples
|
||||
- Include error response examples
|
||||
- Document authentication requirements
|
||||
|
||||
## 🔐 Security Best Practices
|
||||
|
||||
### Authentication & Authorization
|
||||
@@ -294,10 +326,12 @@ log.Info("Customer login")
|
||||
|
||||
### Anti-patterns
|
||||
- Don't use panic for regular error handling
|
||||
- Avoid global variables for application state
|
||||
- **Avoid global variables for application state**
|
||||
- Don't ignore context cancellation
|
||||
- Avoid deeply nested if statements
|
||||
- Don't use reflection unless absolutely necessary
|
||||
- **Don't log in handlers**
|
||||
- **Don't use global validation functions**
|
||||
|
||||
### Common Mistakes
|
||||
- Not handling database connection errors
|
||||
@@ -305,6 +339,8 @@ log.Info("Customer login")
|
||||
- Not validating user inputs
|
||||
- Exposing internal errors to clients
|
||||
- Not using proper HTTP status codes
|
||||
- **Logging in handlers instead of services**
|
||||
- **Using global variables for validation**
|
||||
|
||||
## 📋 Checklist for New Features
|
||||
|
||||
@@ -315,22 +351,28 @@ log.Info("Customer login")
|
||||
- [ ] Design database schema if needed
|
||||
- [ ] Consider caching requirements
|
||||
- [ ] Define custom validators if needed
|
||||
- [ ] Plan logging strategy (service layer only)
|
||||
- [ ] Plan dependency injection for validation
|
||||
|
||||
### During Implementation
|
||||
- [ ] Follow flat domain structure (all files in same package)
|
||||
- [ ] Use dependency injection
|
||||
- [ ] Implement proper logging
|
||||
- [ ] Implement proper logging in service layer only
|
||||
- [ ] Add govalidator validation tags to forms
|
||||
- [ ] Register custom validators in init() functions
|
||||
- [ ] Register custom validators as injected dependencies
|
||||
- [ ] Handle errors gracefully
|
||||
- [ ] Add Swagger comments to handlers
|
||||
- [ ] Ensure no global variables are used
|
||||
|
||||
### After Implementation
|
||||
- [ ] Write unit tests
|
||||
- [ ] Update API documentation
|
||||
- [ ] Update API documentation (Swagger)
|
||||
- [ ] Test error scenarios
|
||||
- [ ] Verify security implications
|
||||
- [ ] Check performance impact
|
||||
- [ ] Test validation scenarios
|
||||
- [ ] Verify no logging in handlers
|
||||
- [ ] Verify all dependencies are injected
|
||||
|
||||
## 🚀 Remember
|
||||
- Prioritize simplicity and readability over cleverness
|
||||
@@ -339,7 +381,7 @@ log.Info("Customer login")
|
||||
- Test your code thoroughly
|
||||
- Security and performance are not optional
|
||||
- **Follow the flat domain structure**: All files in a domain use the same package name
|
||||
- Use the custom logger interface consistently
|
||||
- Use the custom logger interface consistently in service layer only
|
||||
- Implement proper error handling and logging
|
||||
- Follow the repository pattern with interface and implementation in same file
|
||||
- **Time Consistency**: Always use Unix timestamps (int64) for input, storage, and output
|
||||
@@ -348,5 +390,8 @@ log.Info("Customer login")
|
||||
- **No Format Conversion**: Never convert between Unix timestamps and other time formats in the application
|
||||
- **Validation**: Always use govalidator for request validation with proper tags
|
||||
- **Form Design**: Define validation rules in request forms, not in handlers
|
||||
- **Custom Validators**: Register custom validators for complex validation rules
|
||||
- **Package Structure**: Keep all domain files in the same package for easy access and minimal imports
|
||||
- **Custom Validators**: Register custom validators as injected dependencies
|
||||
- **Package Structure**: Keep all domain files in the same package for easy access and minimal imports
|
||||
- **NO GLOBAL VARIABLES**: Everything must be injected
|
||||
- **NO LOGGING IN HANDLERS**: All logging must be in service layer
|
||||
- **SWAGGER DOCUMENTATION**: Use Swagger comments for all API endpoints
|
||||
Reference in New Issue
Block a user