Ginject - A Simple, Global Injection Library for Elixir

Your Libraries & OS Mentoring Libraries
1

Hi everyone!

I’d like to share a small library I’ve recently extracted from a project I’m working on: ginject.

ginject provides a minimal global injection mechanism, letting you register and inject services without plumbing extra configuration throughout your application.

Why this exists

In the app I’m developing, I needed a pragmatic way to inject alternative behaviors mainly for testing purposes.
Mox and behaviours are great — but switching implementations in test environments often requires more setup than necessary for small or isolated cases.
ginject aims to keep things lightweight and comfortable.

Part of a bigger effort

This is the first of some tools I plan to extract and publish from this project.
There are a couple more utilities in the pipeline — once cleaned up and documented — that I hope will also be useful to share with the community.

Thanks for checking it out — and I’d love to hear any feedback!

5 Likes
2

What do you mean? Without ginject

  @ms Application.compile_env(:app, [__MODULE__, :mapset_module], MapSet)

  def new_mapset(x) do
    @ms.new(x)
  end

And test config like

config :app, MyModule,
  mapset_module: TestMapSet

But with ginject

  use Ginject
  service MapSet, as: MS

  def new_mapset(x) do
    MS.new(x)
  end

And

config :ginject, Ginject.DI,
  strategy: Ginject.Strategy.BehaviourAsDefault,
  services: [
    {MyModule, [
      %{service: MapSet, impl: TestMapSet}
    ]}
  ]

What’s the difference?

1 Like
3

With ginject, in most cases you only need two lines of configuration:

# config.exs
config :ginject, Ginject.DI, strategy: Ginject.Strategy.BehaviourAsDefault

and in test:

# test.exs
config :ginject, Ginject.DI, strategy: Ginject.Strategy.Mox

The BehaviourAsDefault strategy uses the behaviour’s own module implementation as the default service.

For example, a typical service in my project looks like this:

defmodule MyProject.ServiceA do
  @callback foo() :: any()

  @behaviour __MODULE__

  @impl true
  def foo do
    ...
  end
end

You only need to configure BehaviourAsDefault like:

services: [
  {MyModule, [
    %{service: MapSet, impl: TestMapSet}
  ]}
]

if you want a custom override for a specific service used by MyModule.

If you prefer to separate behaviour definitions from implementations, you can also define your own strategy, for example based on naming conventions.

Testing

In the test environment, the Mox strategy automatically creates mocks for you, and you can set expectations directly on them.
You can see an example here

Without ginject, you typically need to define configuration entries like:

config :app, MyModule, mapset_module: TestMapSet

for every module and every injected service.
This grows quickly in large codebases, and you must duplicate these configs in both config.exs and test.exs, plus define mock/test implementations somewhere.

I also find

service MapSet, as: MS

much easier to read and write than:

@ms Application.compile_env(:app, [__MODULE__, :mapset_module], MapSet)

and then calling:

MS.new(x)

versus:

@ms.new(x)

Additionally (though I’m not 100% certain), using module attributes may cause you to lose autocompletion and jump-to-definition features in editors.

Edit:

I realize the docs could be clearer and needs some more refinement - I’m working on it!

1 Like
4

Nice!
Could u point out the differences between Ginject and Mimic lib? :thinking:

5

I didn’t know the mimic library. Reading the docs, it seems to be a mocking library similar to Mox or Hammox. It seems capable of swapping a module’s implementation with a mocked one during tests.

ginject, on the other hand, is a dependency injection library. It allows you to choose a service implementation based on any criteria, one of which could be the environment (test/dev/prod).

6

Oh, so your library just calls Mox.defmock automatically and provides syntax sugar, I see, that’s a nice thing.

I have these questions and notes

  1. I think that service and some other macros won’t work with erlang style module names like :something. This is a quick thing to fix
  2. I think that name service for the macro is somewhat misleading, since injected modules can be not only services. Calling it a “service” is an inheritance of original DI practice from OO languages, and I think it’s the bad one. I’d just call it a dependency or I’d call a macro inject
  3. If di configuration is changed, and user calls recompile I suspect that the modules using this di configuration won’t be recompiled, cause you don’t use compile_env and you just use get_env during compile time. This can be very frustrating for someone who debugs their tests and is used to compile_env’s behavior
  4. Is it possible to make some module which implements two or more behaviours with ginject?
  5. Do you plan to support other strategies aside from Mox?
7

That applies only to the Mox strategy. The library itself provides dependency resolution and injection functionality, independently of Mox.

Yes. I’m considering one based on naming conventions. Other ideas are definitely welcome.

I’m not entirely sure I understand. Could you elaborate a bit more on this?

Good point, thanks for catching that. I’ll fix it as soon as possible.

As for the macro name, I like inject, but I want to think a bit more about this.

1 Like