3 ms·
Same. It’s nice to publish an fx module that implements a middleware that plugs into all of the 12000+ microservices we run. One example is adding a debug/flame
by leoqa 5y ago
Same. It’s nice to publish an fx module that implements a middleware that plugs into all of the 12000+ microservices we run. One example is adding a debug/flame graph endpoint to your service- it’s a one line import into your app.
- otterley 5y agoThe Go convention for adding features like that is import _ "example.com/feature" Á la https://pkg.go.dev/net/http/pprof https://pkg.go.dev/net/http/pprof Reads a heck of a lot easier!
- ravishi 5y agoIt sure does. But as I commented before, readability might not be the best/only metric to strive for.
- closeparen 5y agoIf the complaint about dependency injection is that it’s magic, brittle, and difficult to debug - globals mutation via init() is much worse. In FX codebases this is heavily discouraged. The concepts of constructors and lifecycle hooks in an FX graph are not that hard to grok; you can pretty readily figure out what’s going on if you want to.
- otterley 5y agoDependency injection happens all the time in Go. It's just a lot more elegantly expressed in idiomatic Go than in FX.
- closeparen 5y agoThe “import _” approach you recommend is idiomatic Go but it is inherently a global mutable state approach and not a DI approach. I suppose elegance is in the eye of the beholder. FX is very elegant in my opinion: just specify your constructors and your needs, let the computer do the topo sort. But you’re right it is not idiomatic Go. Idiomatic Go is always to maximize the volume of rote, low-information-density code to accomplish any given task. Any time you are being clever and automating grunt work you are certainly violating the spirit of Go.