5 ms·

I've found that fx is very popular with java devs Can you help me understand what this style of dependency injection solves for in java? I use packages to enc

I've found that fx is very popular with java devs Can you help me understand what this style of dependency injection solves for in java? I use packages to encourage separation of concerns

latchkey 4y ago
If you start to write pkg.NewFoo() inside of functions, you get into a whole object dependency mess that makes testing really really difficult. Having something that encourages you to pass in constructed objects (ala: DI), in the constructor, it ends up being much easier because you can more easily mock objects as necessary. Obviously, you can use that same pattern on your own without fx, but going all in on fx really kind of forces you to do it. Bonus fx points for being able to start/stop services as well. However, this tends to factor more into single binary apps (which is what I've built), more than say restful web endpoints (also built, but don't use this feature of fx as much).
- randomdata 4y ago
  > Obviously, you can use that same pattern on your own without fx, but going all in on fx really kind of forces you to do it. Unless you are trying to add tests to legacy code, where you also wouldn't have much say in the use of fx, wouldn't the stated testing difficultly already force you away from that dependency mess?
  - latchkey 4y ago
    I've found that unless I write code in golang in a way that was intentionally written to be unit tested, it is very hard to bolt on unit testing after the fact. I'm stuck with effectively just integration testing. I don't envy you working on legacy code. struct Foo { } func (f *Foo) doSomething() { client := pkg.NewClient() client.doHttpRequest() } vs. struct Foo { client Client } func (f *Foo) doSomething() { f.client.doHttpRequest() } func NewFoo(client Client) *Foo { return &Foo{ client: client } } var FooModule = fx.Provide(NewFoo) then to use it... struct Bar { foo *Foo } func NewBar(foo *Foo) *Bar { return &Bar{foo: foo} } var BarModule = fx.Provide(NewBar) how do you unit test the first example? There is no easy way to that without having the client do things special internally, which leads to a rats nest of issues and doesn't scale. Easier to just pass in a mock client and make sure the right http request/responses are being done. fx kind of highly encourages the second approach for all of your code. It is a bit more boilerplate, but by default, I'm always going to be thinking about passing my dependencies around instead of just being lazy and doing NewClient in the function. I also get to take advantage of the fact that Client is just magically passed into my constructor. If there is some error doing so (like I forget to Provide), then fx will give me errors at start up. My dependency chain is clear. It just feels nicer to me. Once again, of course I can write it the second way without fx... but it is kind of nice that every time I want to use Foo, I don't have to type NewFoo() in a constructor... I just reference *Foo. By the way, mockery [1] generates super easy to use mocks for exactly this workflow. [1] https://github.com/vektra/mockery https://github.com/vektra/mockery
    - randomdata 4y ago
      > I've found that unless I write code in golang in a way that was intentionally written to be unit tested, it is very hard to bolt on unit testing after the fact. Absolutely. This is true in most, if not all, languages. But when you're in the driver's seat, able to make choices like whether or not to use fx, why would you bolt on testing after the fact? Not much you can do about legacy code, if that's what you have to deal with, but when dealing with legacy code it is unlikely the authors used fx, so...
      - latchkey 4y ago
        As you refactor the code to be more testable, you can add in fx. It doesn't have to be from the beginning.
        randomdata 4y ago
        If you refactor code to be more testable then it is testing that is forcing you, not fx.
        latchkey 4y ago
        Correct, I haven't argued any differently. You introduce fx in, start writing tests and it will convince the other developers you're working with that there is importance to how you build the codebase in such a way as to enable testing.
        randomdata 4y ago
        Then you must have mistakenly replied to the wrong thread? If you are in a position where you can introduce fx, then you are also in a position to introduce testing, and testing will already force testable code. If fx can help your code, great, but that's orthogonal to the discussion.

I've found that fx is very popular with java devs Can you help me understand what this style of dependency injection solves for in java? I use packages to encourage separation of concerns

latchkey 4y ago

If you start to write pkg.NewFoo() inside of functions, you get into a whole object dependency mess that makes testing really really difficult. Having something that encourages you to pass in constructed objects (ala: DI), in the constructor, it ends up being much easier because you can more easily mock objects as necessary. Obviously, you can use that same pattern on your own without fx, but going all in on fx really kind of forces you to do it. Bonus fx points for being able to start/stop services as well. However, this tends to factor more into single binary apps (which is what I've built), more than say restful web endpoints (also built, but don't use this feature of fx as much).

randomdata 4y ago
> Obviously, you can use that same pattern on your own without fx, but going all in on fx really kind of forces you to do it. Unless you are trying to add tests to legacy code, where you also wouldn't have much say in the use of fx, wouldn't the stated testing difficultly already force you away from that dependency mess?
- latchkey 4y ago
  I've found that unless I write code in golang in a way that was intentionally written to be unit tested, it is very hard to bolt on unit testing after the fact. I'm stuck with effectively just integration testing. I don't envy you working on legacy code. struct Foo { } func (f *Foo) doSomething() { client := pkg.NewClient() client.doHttpRequest() } vs. struct Foo { client Client } func (f *Foo) doSomething() { f.client.doHttpRequest() } func NewFoo(client Client) *Foo { return &Foo{ client: client } } var FooModule = fx.Provide(NewFoo) then to use it... struct Bar { foo *Foo } func NewBar(foo *Foo) *Bar { return &Bar{foo: foo} } var BarModule = fx.Provide(NewBar) how do you unit test the first example? There is no easy way to that without having the client do things special internally, which leads to a rats nest of issues and doesn't scale. Easier to just pass in a mock client and make sure the right http request/responses are being done. fx kind of highly encourages the second approach for all of your code. It is a bit more boilerplate, but by default, I'm always going to be thinking about passing my dependencies around instead of just being lazy and doing NewClient in the function. I also get to take advantage of the fact that Client is just magically passed into my constructor. If there is some error doing so (like I forget to Provide), then fx will give me errors at start up. My dependency chain is clear. It just feels nicer to me. Once again, of course I can write it the second way without fx... but it is kind of nice that every time I want to use Foo, I don't have to type NewFoo() in a constructor... I just reference *Foo. By the way, mockery [1] generates super easy to use mocks for exactly this workflow. [1] https://github.com/vektra/mockery https://github.com/vektra/mockery
  - randomdata 4y ago
    > I've found that unless I write code in golang in a way that was intentionally written to be unit tested, it is very hard to bolt on unit testing after the fact. Absolutely. This is true in most, if not all, languages. But when you're in the driver's seat, able to make choices like whether or not to use fx, why would you bolt on testing after the fact? Not much you can do about legacy code, if that's what you have to deal with, but when dealing with legacy code it is unlikely the authors used fx, so...
    - latchkey 4y ago
      As you refactor the code to be more testable, you can add in fx. It doesn't have to be from the beginning.
      - randomdata 4y ago
        If you refactor code to be more testable then it is testing that is forcing you, not fx.
        latchkey 4y ago
        Correct, I haven't argued any differently. You introduce fx in, start writing tests and it will convince the other developers you're working with that there is importance to how you build the codebase in such a way as to enable testing.
        randomdata 4y ago
        Then you must have mistakenly replied to the wrong thread? If you are in a position where you can introduce fx, then you are also in a position to introduce testing, and testing will already force testable code. If fx can help your code, great, but that's orthogonal to the discussion.