Technical Tutorials

Since the introduction of Go 1.18, the Go ecosystem has evolved significantly. The addition of generics has addressed one of the most common complaints in Go development: the need for boilerplate code to handle multiple types. For intermediate and advanced developers, leveraging generics is no longer optional if you want to write clean, DRY (Don't Repeat Yourself), and maintainable code.

In this post, we will explore how to implement a robust, type-safe Repository Pattern using Go generics. This pattern is crucial for database abstraction, allowing your business logic to remain decoupled from specific database implementations while ensuring type safety at compile time.

Why the Repository Pattern in Go?

The Repository Pattern acts as a mediator between the domain and data mapping layers, providing a collection-like interface for accessing domain objects. In traditional Go development without generics, implementing a repository for every entity (User, Product, Order) required repetitive boilerplate code for each database operation (Create, Read, Update, Delete).

By using generics, we can define a single Repository interface and implementation that works across different entity types, reducing code duplication and enhancing maintainability.

Defining the Generic Repository Interface

The core of our solution lies in defining a generic interface. We use a type parameter T to represent the entity type. Additionally, we introduce a constraint interface Entity to enforce that only structs with specific fields (like an ID) can be used as entities.

package repository

import "context"

// EntityConstraint ensures that only structs with an ID field can be used as entities.
type EntityConstraint interface {
	~struct{
		ID int64
	}
}

// Repository defines the generic interface for database operations.
type Repository[T any] interface {
	Create(ctx context.Context, entity *T) error
	Read(ctx context.Context, id int64) (*T, error)
	Update(ctx context.Context, entity *T) error
	Delete(ctx context.Context, id int64) error
	List(ctx context.Context) ([]*T, error)
}

Here, any allows any type, but in practice, you might restrict T to implement the EntityConstraint interface if you need to enforce structural rules. The methods accept *T, ensuring that the caller provides pointers to the specific entity type.

Implementing the Generic Repository

Let's create a concrete implementation using sqlx, a popular SQL library for Go that supports scanning into structs. This implementation demonstrates how generics allow us to write a single handler for multiple table types.

package repository

import (
	"context"
	"database/sql"
	"fmt"
)

type GenericRepository[T any] struct {
	db *sql.DB
	tableName string
}

func NewGenericRepository[T any](db *sql.DB, tableName string) *GenericRepository[T] {
	return &GenericRepository[T]{
		db:        db,
		tableName: tableName,
	}
}

func (r *GenericRepository[T]) Create(ctx context.Context, entity *T) error {
	// In a real-world scenario, you would use reflection or a macro-generated query
	// to dynamically build the INSERT statement based on the struct fields.
	// For brevity, we assume a helper function exists that generates the query.
	query := fmt.Sprintf("INSERT INTO %s VALUES (?, ?, ?)", r.tableName)
	_, err := r.db.ExecContext(ctx, query, /* fields from entity */ )
	return err
}

func (r *GenericRepository[T]) Read(ctx context.Context, id int64) (*T, error) {
	var entity T
	query := fmt.Sprintf("SELECT * FROM %s WHERE id = ?", r.tableName)
	err := r.db.QueryRowContext(ctx, query, id).Scan(&entity)
	if err != nil {
		return nil, err
	}
	return &entity, nil
}

Notice how the Read method returns *T. The compiler ensures that if you call this method, the returned variable matches the type you instantiated the repository with. This eliminates the need for type assertions (entity.(*User)), which are error-prone and slow.

Using the Repository in Service Layer

The true power of this pattern is visible when using it in your service layer. Here, we can inject a generic repository and perform operations without knowing the underlying SQL specifics.

type UserService struct {
	userRepo repository.Repository[*User]
}

func NewUserService(userRepo repository.Repository[*User]) *UserService {
	return &UserService{userRepo: userRepo}
}

func (s *UserService) GetUserByID(ctx context.Context, id int64) (*User, error) {
	return s.userRepo.Read(ctx, id)
}

In this example, userRepo is typed as Repository[*User]. This provides strong compile-time guarantees. If you accidentally try to pass a *Product to this user-specific service, the Go compiler will throw an error, preventing runtime bugs.

Best Practices and Considerations

Avoid Over-Abstraction: Generics add complexity. Use them only when you genuinely need to reuse logic across different types. For simple applications, concrete implementations might be clearer.
Performance: While generics reduce code duplication, ensure that your generic functions are inlined by the compiler. Avoid excessive reflection within generic methods, as it can impact performance.
Error Handling: Ensure that error handling in generic functions is robust. Since the type T is unknown at compile time, you cannot rely on type-specific error types.

Conclusion

Mastering Go generics opens up new possibilities for building scalable and maintainable applications. By implementing a generic Repository Pattern, you can achieve a high degree of code reuse while maintaining the type safety that Go is known for. As you continue to develop in Go, embrace generics not just as a feature, but as a fundamental tool for designing clean architectures.

Start refactoring your repetitive database handlers today and experience the benefits of type-safe, generic code.