Dependency Management in Rails

Ben and Joe dive into the Upcase exercises system, exploring inversion of control. We previously covered inversion of control, but now we tackle it with a new twist: a new dependency injection framework for Rails which makes this style of developm...
This is a companion discussion topic for the original entry at https://thoughtbot.com/upcase/videos/dependency-management-in-rails

It appears the github link to payload is not available

Actually, it appears that you haven’t accepted the invitation to join our GitHub team. Since you don’t have access, GitHub shows you a 404 page.

@benorenstein This looks cool, but how do you handle the ever growing config/dependencies.rb file? I guess we have to accept some complexity somewhere!

Also, you don’t seem to require the classes in that file either, do you just allow Rails autoloading to work? How does that effect test speed? I’ve been trying to use a fast_spec_helper for my POROs as much as possible to speed things up.

Also, is it actually ok to try to use the payload gem in an app? It would have to be a public repo on GitHub to add it to a Gemfile. We add private repo Gems with a url including an x-oauth-basic key in the URL, so we’d need to know Thoughtbot’s key to use it.

Really interesting concept. I think if you are not on the SOLID path, this is going to be really confusing to grasp. Here’s an explanation about it what it does - for myself and other object-orientated noobs…

It appears the problem arises when you start using lots of small single responsibility objects and end up with an object that has many collaborators and is difficult to manage or use in your Controllers. For example, in your Controller you may have a NotificationPayment object that requires a Payment and a PaymentNotifier to be passed in or injected.

Rather than specify all your dependencies in your Controller (i.e build up a NotificationPayment with Payment and PaymentNotifier) you can use Payload to extract the setup or configuration for your dependencies to this new file called config/dependencies.rb so that in your Controller you can simply use a one liner (via the dependencies method) to instantiate whatever it is that you need.

What seem’s cool about this is assuming you have lots of different objects, you can ‘mix and match’ your objects to compose other objects in this dependencies.rb file, and only have to worry about that in one place.

I know it’s not the same, but it kind of feels like using traits in factory girl, where you can configure your factory setup how you like and call them when you need. I really appreciate that feature in FactoryGirl.

I think there’s an obvious pre-requisite to using Payload and that’s having lots of collaborating objects interacting with one another via dependency injection (it is called a DI framework afterall). I find that as a noob beginning to use PORO’s in my code - my objects are not necessarily injecting more than one other object/collaborator. Notwithstanding, Payload may encourage you to use more factories and decorators which might help make things smaller and easier to manage?

Overall I’d say it looks very cool! I’m not sure if I should being using it straight away but certainly if my objects become ‘composed’ enough then I’ll start looking at adding it in, unless @jferris suggests otherwise :wink:

@aaronmcadam docs say you can group dependencies in a file like config/dependencies/payments.rb which may help in managing growing complexity?

1 Like

Aw geez… you’re right. I’m sorry. I expected it would be open source though, would be awesome to try this in a production application

I think you meant to direct that at me :wink:

Yeah I think this gem will solve issues with having lots of smaller objects that can work together to form larger dependencies. It’s cool that you can break up the dependency definitions into separate files.

I think a builders directory is probably the first place to put Builder/Factory objects extracted from a Controller. If you have a critical mass of builders/factories, maybe then an IoC container like payload is the right option. Looking at some of the definitions of the objects in upcase-exercises though, they look quite complicated, so I’d think you’d have to make sure the benefits really outweigh the complexity. I think you’d have to be careful that you actually have the problem of needing to swap dependencies around and actually have the objects that are composable

This looks cool, but how do you handle the ever growing config/dependencies.rb file?

There’s some work in progress to create namespaces/modules for dependencies, so that you can create little boxes of dependencies instead of having a giant graph.

I guess we have to accept some complexity somewhere!

Definitely. Some complexity is removed when factories can reduce the number of hops you need a dependency for, but mostly the goal is to break up complexity rather than remove it. The idea is to focus on dependency management in one place and let Ruby classes not worry about building instances of other classes.

Also, you don’t seem to require the classes in that file either, do you just allow Rails autoloading to work? How does that effect test speed? I’ve been trying to use a fast_spec_helper for my POROs as much as possible to speed things up.

We’re using Rails autoloading, yes. We use Spring, so it doesn’t affect our test speed at all. However, Payload doesn’t reference classes until you actually try to use a dependency, so you can still require things by hand if you prefer, in your specs or elsewhere. I’ve considered adding a facility to Payload to handle file loading, but it hasn’t been a pain point for us so far.

Also, is it actually ok to try to use the payload gem in an app? It would have to be a public repo on GitHub to add it to a Gemfile. We add private repo Gems with a url including an x-oauth-basic key in the URL, so we’d need to know Thoughtbot’s key to use it.

You can actually just add payload to your Gemfile, because it’s on rubygems.org. We’re not announcing or releasing it outside of Upcase yet, because we’re still trying to confirm whether or not this approach is viable and whether or not we want to maintain it. We decided to provide early access to Upcase subscribers, particularly since we talk so much about SOLID on the Weekly Iteration. That being said, we may decide not to continue pursuing this approach, so Payload may disappear some day.

Really interesting concept. I think if you are not on the SOLID path, this is going to be really confusing to grasp.

We haven’t found that to be the case so far when bringing on apprentice-level developers. There’s some ramp up time, but I’d say the difficulty is less than learning things like the asset pipeline, Mongodb, or Capybara. Learning to manage dependencies well is certainly difficult, but that difficulty exists whether you use small classes, large classes, dependeny management, or anything at all.

Aw geez… you’re right. I’m sorry. I expected it would be open source though, would be awesome to try this in a production application

We try not to open source things until we feel comfortable letting people depend on them. It’s always difficult to decide when that is. As mentioned above, though, you’re welcome to try it out if you’d like.

1 Like

Great insights, thanks @jferris! One thing I’m grappling with at the moment is how to test my dependency injector. I’ve been looking in the exercises repo, but can’t seem to find any coverage. Do you let your feature specs catch that correct dependencies have been passed?

Here’s an example I’ve been working on, I’m not sure whether it’s worth testing that the correct dependencies are passed to the constructor, it feels like it does add some value, otherwise anything could end up being passed as dependencies.

There’s a Builders::ProfilePage object that builds a ProfilePage instance: builders_profile_page_spec.rb · GitHub

Yeah, we assume the feature specs catch problems with dependencies not lining up. We try to keep as little business logic as possible in the dependency configuration. So far, this has not caused any problems.

Awesome episode, thanks @jferris and @benorenstein . We watched this at an interesting time - we just got done extracting some functionality to a dependency injection container. I’m curious about your opinion on the given solution vs what we’re trying out at ControlledVocabularyManager/vocabularies_controller.rb at master · OregonDigital/ControlledVocabularyManager · GitHub and ControlledVocabularyManager/vocabulary_injector.rb at master · OregonDigital/ControlledVocabularyManager · GitHub

I think one important to keep in mind is Inversion of Control. In the VocabulariesController example, control is still not inverted, because VocabulariesController instantiates VocabularyInjector and then delegates to it. This is using composition, which is a good way to break up large components or achieve reuse between several components, but it doesn’t invert control.

If you want to remove the concern of dependency management from your controllers, you’ll have to find a way to remove the reference to the VocabularyInjector class.

This is a good point - at this point we’ve declared our controllers as the entry point - largely because we haven’t found a good place to inject that concern. The goal is to invert control below that point - we’re not there yet, but this has been a good route there.

Thank you for the insight.