What is the idiomatic/proper way to structure a Go project?

  Kiến thức lập trình

Somewhat new to Go, transitioning from C-like languages and I’ve been struggling on the proper way to structure my projects and avoid import cycles.

Consider the following scenarios:

We have a config package and a logger package, both of which need to “depend” on each other: config needs to log the config file loading process, and logger needs to know what logs to display. What is the proper way to approach this?

Combining both into one blanket package like startup feels like obscuring each package’s functionality.
Another alternative would be moving the config loading code to its own package so that it can properly depend on logger, but that separates logically similar concepts (config and config loading), and it results in non intuitive code, as we’d access the global config via something like config.Get, and load it via confloader.Load.

On a similar note, assume we have an http and an mqtt package, with distinctly different functionalities. They both need to have some utility functions. Is it better to contain each package’s utils to itself, but create bloat (http/utils.go, mqtt/utils.go), or have them “leak” to another package, but providing a cleaner structure for the individual packages? (utils/http.go, utils/mqtt.go)

Thanks in advance!

LEAVE A COMMENT