Suggestion: Split backends into separate repositories/packages

[digitive]

Hi, thanks for building and maintaining this project — it’s really useful!

I’d like to suggest splitting the backend implementations (e.g., Redis, SQS, etc.) into their own repositories or at least separate Go modules. The main reasons are:

• Reduce unnecessary dependencies: Currently, when importing goqueue, projects pull in all backend dependencies even if they only need one. This can bloat go.mod and vendor files.
• Cleaner modularity: Having each backend in its own repo/module allows projects to explicitly choose which backend they depend on.
• Easier maintainability: Each backend can evolve at its own pace, with clearer separation of concerns.

A possible structure could be:

• github.com/saravanasai/goqueue → core interfaces & abstractions
• github.com/saravanasai/goqueue-redis → Redis backend
• github.com/saravanasai/goqueue-sqs → SQS backend

(etc.)

This approach is fairly common in Go projects with pluggable backends and could make adoption easier for users.

[saravanasai]

Hi @digitive thanks for the noticing & pointing the issue.

Drawbacks of Splitting :

1. More Complex Setup: Users need to import multiple packages
2. Documentation Overhead: Need to explain the modular system
3. Increased Maintenance: Managing multiple repositories

The core idea I have build this project is to make the developer experience fast & easy. Still I consider this as an issue & let me do a poll on community & let see what community wants & let me do the need full.

[ZackarySantana]

Hey @saravanasai, I think a monorepo setup like testcontainers/testcontainers-go would be beneficial. It circumvents most of the drawbacks you listed while unpolluting the go.mod of services that people won't need. E.g. if someone only uses in-memory, they wouldn't need the packages from redis/postgres, same with chosing one from redis and postgres.

[saravanasai]

@ZackarySantana Thanks for mentioning those examples. I feel it make sense. Am planning to refactor few parts of the library & how the metrics are handled. I try to make it as monorepo as well.