Ruby Dependency Injection Libraries

Ruby dependency injection libraries

Jamis Buck, who wrote Copland and Needle, posted here about Needle, dependency injection and their usefulness in a Ruby world.

It's long but worth reading, but in case you want the single paragraph most relevant to your question, I'd suggest this one, from just before the end:

DI frameworks are unnecessary. In more
rigid environments, they have value.
In agile environments like Ruby, not
so much. The patterns themselves may
still be applicable, but beware of
falling into the trap of thinking you
need a special tool for everything.
Ruby is Play-Doh, remember! Let’s keep
it that way.

HTH

Technique to inject dependencies in Ruby without using DI frameworks

Looks fine to me. Classes are objects in Ruby, so dependency injection is just setting a variable at runtime. In your case, you are setting the @http_client instance variable of the AppClient class. Once that variable is accessed by the code that needs the implementation, the class you configured the application with will be returned and it will do the job as long as it responds to the correct messages.

Be careful, though. Remember that classes are singleton objects that are shared within a single Ruby process. Other code could call that accessor method and change that variable as well. This could happen at any point, not just at start up, and will affect all code that uses the implementation. The potential for conflict exists.

This makes this pattern specially unsuitable for use in libraries. Passing the implementation class as a parameter on the call site should be a more robust solution in that case.

Does dependency injection exist in Rails?

Dependency injection is usually unnecessary with Ruby. Jamis Buck blogged extensively about the reasons why. Well worth a read.

Ruby on Rails Dependency Injection

Dependency injection is usually unnecessary with Ruby. Jamis Buck blogged extensively about the reasons why. Well worth a read.

Are dependency injection frameworks worth the extra indirection layer?

Yes, your code becomes much more decoupled and much more testable. This in particular becomes handy when you have lots of tests and each test requires a heavy object such as database layers.

If you use dependency injection, you can simply create so called 'mock' objects or stubs and use those to let your tests run more quickly and have less side effects (database state).

It is true that you cannot see directly which implementation is used by looking at the code. You will see a reference to the interface. A good IDE might have functionallity to view all implementations for a particular interface, so use that to your advantage.

What's the best practice to achieve dependency injection with ruby-graphql?

As you've mentioned, injection through the initializer might not be super straight forward, so if you want to go fully into dependency injection and inversion of control, you could leverage an IOC Container library like Dry Auto Inject. I know it might be a full blown solution, and it could possibly be too heavy handed for your use case (not sure), but since you're already using repositories in Ruby, it might not be.

---

Related Topics