4 ms·
For a slightly different take on this problem, check out Wire (https://github.com/google/wire https://github.com/google/wire).
by pbiswal 5y ago
For a slightly different take on this problem, check out Wire (https://github.com/google/wire https://github.com/google/wire).
- dcormier 5y agoHaving used both, I very much prefer wire's compile-time satisfaction vs fx's runtime satisfaction. If I miss something, I'd much rather know when I try to compile instead of waiting 'til a specific code path that uses a missing dependency fails.
- akshayshah 5y agoThat's a very fair perspective, and build-time verification of your dependency graph is great. That said, fx's approach allows for a more dynamic dependency graph. (For example, fx.Replace[0].) The documentation for Fx, along with nearly all the applications I saw internally, use the dependency injection container only in main - once the application starts successfully, there's no more interaction with the container. For Uber at the time, this struck a useful balance between safety and the difficulty of distributing yet another versioned code gen tool to thousands of repositories. [0]: https://github.com/uber-go/fx/pull/837 https://github.com/uber-go/fx/pull/837