Dependency Injection in Ruby - GOD Level! Meet dry-system! (Part 2)

In the last episode, I've covered deeply the reasons behind the existence of dry-container gem and shown how to implement dependency injection in Ruby from scratch.

This pattern, however powerful, can easily get annoying due to a lot of additional code one needs to write - and in most cases, it's repeatable code, nothing challenging, so boring.

This episode is a direct follow-up on that topic and today I'll focus exactly on problems related to: more overhead, and more code to be written, showcasing two great additions to dry-container, which are

• dry-auto_inject
• dry-system

By the end of this episode, you'll be able to make use of all the power dependency injection offers to you, without ANY excuses, as this DRY combo just solves everything.

Let me now then go through those remaining issues that can stop you from leveraging DI in your ruby applications.

Remaining problems with dependency injection in ruby.

While dry-container is awesome, there is still a lot of manual work to be done to actually register all dependencies for the first time.

You still need to know the exact way to register all components, even if you need to do it only once.

Then our initialize methods may become quite extensive, as I have shown in HME007.

Those methods have no logic at all. It's just defining some readers and assigning dependencies to them, so maybe we could automate this?

# lib/my_app/utils/loggers/io_logger.rb

module MyApp
  module Utils
    module Loggers
      class IOLogger
        def call(msg)
          puts msg
        end
      end
    end
  end
end

# lib/my_app/utils/services/subscriptions/email_subscription.rb

module MyApp
  module Utils
    module Services
      module Subscriptions
        class EmailSubscription
          attr_reader :logger
          def initialize(logger:)
            @logger = logger
          end

          def call(email)
            logger.call("@-_-@")
          end
        end
      end
    end
  end
end

# slices/blog/commands/become_awesome_subscriber

module Blog
  module Commands
    class BecomeAwesomeSubscriber
      attr_reader :logger, :service
      def initialize(logger:, service:)
        @logger = logger
        @service = service
      end

      def call(**args)
        logger.call("starting subscription...")
        service.call(args[:email])
        logger.call("subscribed to newsletter!")
      end
    end
  end
end

Good News!

Dry-rb team have you covered!

Slim down your classes with dry-auto_inject!

There is a gem that allows exactly for that. It's dry-auto_inject, one of the first DRY libraries written by Peter Solnica, Tim Riley and Nikita Shilnikov. What it does, is allowing you to automatically create attr_readers in your classes and override initialize methods, removing tons of code you'd need to write without it.

With this little gem we can now simplify our registration file by automatically resolving all dependencies!

First of all, in my container file, I just create Deps constant which will be the only thing I'll use across my classes.

require 'dry-container'
# define the container
class Container
  extend Dry::Container::Mixin
  import Repositories

  register('my_app.utils.loggers.io_logger') do
    MyApp::Utils::Loggers::IOLogger.new
  end

  register('my_app.utils.services.subscriptions.email_subscription') do
    MyApp::Utils::Services::Subscriptions::EmailSubscription.new
  end

  register('blog.commands.become_awesome_subscriber') do
    Blog::Commands::BecomeAwesomeSubscriber.new
  end
end

Deps = Dry::AutoInject(MyContainer)

And the cool thing that I cannot stop highlighting, is that this gem does not work exclusively with dry-container! It works with ANY container, as long, as it responds to the [] method!

It's just awesome!

Now in all our files, we can replace all initialize methods together with attr_reader definitions by including our Deps module.

module MyApp
  module Utils
    module Services
      module Subscriptions
        class EmailSubscription
          include Deps[logger: 'my_app.utils.loggers.io_logger']

          def call(email)
            logger.call("@-_-@")
          end
        end
      end
    end
  end
end

module Blog
  module Commands
    class BecomeAwesomeSubscriber
      include Deps[
        logger: 'my_app.utils.loggers.io_logger',
        service: 'my_app.utils.services.subscriptions.email_subscription'
      ]

      def call(**args)
        logger.call("starting subscription...")
        service.call(args[:email])
        logger.call("subscribed to newsletter!")
      end
    end
  end
end

This extremely simplifies the whole process of defining and injecting dependencies across the whole system.

Plese notice, that the rest of the classes did not change at all, as dry-auto_inject allows us to freely name any dependency we load from the container, so long names or paths are issues neither.

Using this code also didn't change at all.

cmd = Container['blog.commands.become_awesome_subscriber']
cmd.call(email: 'awesomesubscriber@hanami.mastery')

You still can just access the container, but now all our dependencies are automatically resolved based on the container definition!

However, can you spot further possible improvements on this?

Dry-System for what?

Having that covered, what's the point of dry-system?

In my article about dry-rb dependency graph, I've highlighted, that based on the gem relationships you can conclude which gems are supposed to be used directly, and which are designed as a low-level building blocks for other libraries.

dry-system is a high-level gem designed specifically for a direct use.

While dry-auto_inject and dry-container are extremely powerful, you'll still have a lot of manual work required to register all components and across large systems you probably would like to avoid that.

If I would have more than 50 files to be manually registered by the container, I'd think 10 times. before I'll actually do it and more likely would end up with a conclusion, that it's not worthy.

Imagine a boot file manually registering hundreds of services and utility classes and you'll quickly feel the pain.

But then imagine if all of those files in your projects, would be registered automatically, and all dependencies would be automatically resolved, without you being stressed about a typo.

Imagine whole trees of dependencies loaded by thread-safe environment, without a need to write a single initialization method!

Guest what!

Dry-RB team has you covered!

dry-system composes dry-container and dry-auto_inject together, adding powerful autoloading capabilities and configuration options to your application.

So Let's look at the example.

Creating container in dry-system

First let me visit my container file.

# system/container.rb

require 'dry/system/container'

class Container < Dry::System::Container
  configure do |config|
    config.root = Pathname('.')
  end
end

This little snippet uses dry-container under the hood, but it also leverages the power of dry-configurable to allow easy-to-use, thread-safe configuration for the gem.

So what's the point of it?

Well. So far, we needed to manually register all our files, didn't we?

However, now If we'll add a new directory to components files, we can now auto-register all our dependencies!

require 'dry/system/container'

class Container < Dry::System::Container
  configure do |config|
    config.root = Pathname('.')
    config.component_dirs.add 'lib'
    config.component_dirs.add 'slices'
  end
end

We completely don't need all the container registration code anymore, as everything is just automatically resolved based on our file structure!

This is the real game-changer!

With automatic registrations, and automatic injection we now can write our apps with 0 overhead whatsoever!

Nothing changes in our classes, nothing changes in the usage, but just every little piece of repeatable work is get off of our hands.

As I myself am productivity madman, I just cannot appreciate this enough.

Even though dry-validation is the actual, most popular gem from the dry family, for me it's dry-system, or rather dependency combo, that is my favorite trio.

Configurable file name resolver!

class Container < Dry::System::Container
  configure do |config|
    #...

    config.inflector = Dry::Inflector.new do |inflections|
      inflections.acronym('IO')
    end
  end
end

main_container = Main::Container
main_container.keys
# => []
sandbox[development]> main_container['repositories.articles']
=> #<Main::Repositories::Articles struct_namespace=Main::Entities auto_struct=true>
sandbox[development]> main_container.keys
# => ["repositories.articles"]
sandbox[development]> main_container.finalize!
# => Main::Container
sandbox[development]> main_container.keys
# => ["repositories.articles",
#  "application.notifications",
# ...
#  "application.rack_logger",
#  "view.parts.article",
#  "actions.articles.drafts",
#  "actions.articles.published",
#  "actions.home.show",
#  "repositories.authors",
#  "views.articles.drafts",
#  "views.articles.published",
#  "views.home.show"]

# /slices/main/actions/articles/index.rb

module Main
  module Actions
    module Articles
      class Index < Main::Action
        include Deps[
          repo: 'repositories.articles'
        ]

        def handle(req, res)
          res.render view, articles: repo.all
        end
      end
    end
  end
end

Thank you!