Hi @RuniVN,
One of the things Golang excels at is concurrency. Our server is designed to handle thousands of concurrent users currently and were we to add high availability it would be able to handle even more with a proper setup.
The reason we use channels for all our database communication is so we can take advantage of the concurrency features Golang offers. This allows us to have non-blocking interaction with the database, so every single one of our database accessors/setters returns a StoreChannel (and uses a goroutine to make the DB query) which will return a result no matter what and should never deadlock. We have unit tests that help to ensure this.
In the example you posted we are actually blocking the current method on the database access, likely because there is no more work that can be done until we have the Team object. In many places in the code you'll notice we do something like this:
tchan := Srv.Store.Team().Get(user.TeamId)
// do some work
if result := <-tchan; result.Err != nil {
c.Err = result.Err
return
} else {
team = result.Data.(*model.Team)
}This allows us to start the database query, do some other work and then wait on the channel returning once we hit a point where we can do no more work without the Team object.
If you'd like to read more about Golang's concurrency features like channels and goroutines take a look here.