Constructing services, dependencies during server creation

[Kamariw95]

Hey, I'm an "advanced beginner" that's relatively new to golang, and I had a question.

	repo := postgresql.NewTask(conf.DB)
	search := elasticsearch.NewTask(conf.ElasticSearch)
	mclient := memcached.NewTask(conf.Memcached, search, conf.Logger)

	// msgBroker, err := rabbitmq.NewTask(conf.RabbitMQ.Channel)
	// if err != nil {
	// 	return nil, fmt.Errorf("rabbitmq.NewTask %w", err)
	// }

	// msgBroker := kafka.NewTask(conf.Kafka.Producer, conf.Kafka.Topic)
	msgBroker := redis.NewTask(conf.Redis)
	svc := service.NewTask(conf.Logger, repo, mclient, msgBroker)

How would your approach to constructing services and dependencies (redis, rabbitmq, repositories, etc) change if there were multiple entities similar to Task (e.g. adding User, TaskGrouping, Subtasks)?

[MarioCarrion]

Hello @Kamariw95

The initialization process would be similar; if the concrete repositories use the same underlying datastore (literally the same host) then they would be initialized with that variable, for example (assuming postgresql-related types):

user := postgresl.NewUser(conf.DB)
subtask := postgresl.NewSubtask(conf.DB)

Those instances then would be sent to the corresponding service types to initialize the corresponding type, for example:

svcUser := service.NewUser(user)
svcSubtask := service.NewSubtask(subtask) 

The "tricky" part of all of this is to properly organize the repositories in a way they make sense for the data they are using behind the scenes, for example, let's assume the hypothetical domain types Task and Subtask are used together, this means:

• Tasks have Subtasks
• Subtasks need Tasks and can't exist without Tasks

If you're using a relational database for storing this, this is a "one to many" relationship, so in this case we have at least two options, either:

1. We define one repository that happens to be using both database tables behind the scenes but defining methods to interact with those types independently, or
2. We define a new repository that happens to only deal with Subtasks

// option 1
type TaskRepository interface {
  // Create / Delete / Find / Update
  DeleteSubtask(ctx context.Context, taskId, subTaskId string) error
  FindSubtask(ctx context.Context, taskId, subTaskId string) (internal.Subtask, error)
  UpdateSubtask(ctx context.Context, ....) error
}

// option 2
type SubtaskRepository interface {
  Delete(ctx context.Context, taskId, subTaskId string) error
  Find(ctx context.Context, taskId, subTaskId string) (internal.Subtask, error)
  Update(ctx context.Context, ....) error
}

Both have their tradeoffs (like not being able to share transactions or too large interface types) and choosing one or the other depends on your case; I will cover this is more detail in the future because it gets complicated really quickly when dealing with domain types that include too many types that can't be accessed without their parent.

[Kamariw95]

Gotcha, that makes a lot of sense. Thank you for the response. Looking forward to you covering related domain types.