Why don't you instantiate a custom logger that you would inject as a dependency?

[lobre]

Hello,

Thanks for those articles and for that demo project. It helps a lot to study application design!

I was often being told that loggers are explicit dependencies like any other and that it was a good idea to inject them the same way as a DB or any other application dependency.

I know it is not a general rule, and that it always depends on context but I wanted to know why you decided to use the global logger of the log package instead of defining your own?

I also have another kind of related question about the setup and teardown of your HTTP servers. Here is the piece of code I will refer to (extract from func (m *Main) Run() in cmd/wtfd/main.go).

	if err := m.HTTPServer.Open(); err != nil {
		return err
	}

	// If TLS enabled, redirect non-TLS connections to TLS.
	if m.HTTPServer.UseTLS() {
		go func() {
			log.Fatal(http.ListenAndServeTLSRedirect(m.Config.HTTP.Domain))
		}()
	}

	// Enable internal debug endpoints.
	go func() { http.ListenAndServeDebug() }()

Why use log.Fatal for the "secondary" server that handles the 80 to 443 redirection? If I understand it well, that means if something bad happens with that server, that would directly exit the application without closing the main server in a clean way?

And the last question while having a look at this code. Why would m.HTTPServer.Open() launch a goroutine behind the scenes from the http package while explicitly handling the concurrency from the main for the other two usecases (redirection HTTP server and debug endpoints).

Thanks a lot for the clarifications!

[benbjohnson]

Hi @lobre, great questions.

I was often being told that loggers are explicit dependencies like any other and that it was a good idea to inject them the same way as a DB or any other application dependency. I know it is not a general rule, and that it always depends on context but I wanted to know why you decided to use the global logger of the log package instead of defining your own?

I used to inject loggers as dependencies to everything but I've found that's it's overly complicated in most cases—especially for small/medium-sized projects. Simply having a log available globally from anywhere makes things easier. I'll usually switch to an injected logger once I have a good reason.

Why use log.Fatal for the "secondary" server that handles the 80 to 443 redirection? If I understand it well, that means if something bad happens with that server, that would directly exit the application without closing the main server in a clean way?

I used log.Fatal() for the redirection server because I want to make sure the application is able to redirect HTTP traffic. If it fails then it kills the process and the main server would be closed automatically. The application is crash-safe so a panic shouldn't cause any issues. The debug server could also be wrapped in a log.Fatal() although it's less important.

Why would m.HTTPServer.Open() launch a goroutine behind the scenes from the http package while explicitly handling the concurrency from the main for the other two usecases (redirection HTTP server and debug endpoints).

The HTTPServer.Open() handles its own goroutine because it's also used in the unit tests so it needs to be able to startup & shutdown properly. The redirection server & debug endpoints only run in the main package so they will automatically be cleaned up when the process ends. I could do explicit concurrency handling with those too but there wasn't any benefit.

[lobre]

Thanks for taking the time to answer those questions. That's appreciated.

I really like your mindset and balance between what is considered as being a best practice and reality. Breaking rules and trying to avoid the "over-engineering effect" is a great skill and it seems you learned how to master it!

It is basically about starting simple and refactor, clean and make abstractions only when it is really needed. But that's something I find complicated in an ecosystem where everyone is sharing best practices.

I often find myself stuck in a loop where I try to improve my code based upon other's recommendations (shared regardless of the context of my project) and I realized this kind of refactoring rarely brings value ¯\_(ツ)_/¯.

I think you are right in saying that using the global logger is fine for most projects. Thanks again for shedding light.