Dependency injection?

[unleashy]

Hi! Sorry if this is a stupid question, but I've searched the documentation and it's very unclear to me how I can pass objects from outside Grape::API's scope through, say, a constructor, for dependency injection purposes?

I've tried using a bog-standard constructor, but a class derived from Grape::API doesn't seem to like being initialized:

class Foo < Grape::API
  def initialize(baz)
    @baz = baz
  end

  get :bar do
    @baz
  end
end

run Foo.new('hello') # ArgumentError

If I remove the .new call so it's just run Foo the constructor isn't even called, so @baz is obviously nil.

It seems configuration would be able to do this but it's incredibly unclear to me how to use it outside of mount, or, for that matter, when initialising the object which is what I want to do :)

There's also another, less related question. Are routes supposed to use symbols or strings? Or either? If it's either, is there a convention? That also isn't clear to me.

Thank you and I hope I'm not being too dense lol :p

[dblock]

The API is not the class being instantiated, you can check out the code in https://github.com/ruby-grape/grape/blob/45b12881f0a886f33d99f2f1d942a1ce9ef81171/lib/grape/api/instance.rb for how instances of the API get created, it's ... tricky.

It's a good question and we should write tests around this and document it. If you start on a PR and get blocked we can help you @unleashy.

[myxoh]

It's an interesting one, I don't think we properly support dependency injection from outside grape.
As you pointed out the configuration can be used for dependency injection from inside grape, but when calling run from a rack config file, I don't think there's an established way of passing in details.

Because run is actually a method from rack that doesn't call anything useful on grape, it would be hard to find an appropiate solution.

Perhaps we can do something like (this is just an idea, not an actual Feature)

class SomeApp < Grape::API
end

run SomeApp.with(configuration: {})

[unleashy]

@myxoh I like your idea. I think it would be rather easy to implement too (changed .with to .with_configuration because I think that's neater):

# in the class << self of Grape::API
def with_configuration(config)
  config.each do |key, value|
    @base_instance.configuration[key] = value
  end
end

I'll try to write a PR if that's okay. Thanks!

[dblock]

The call to Rack#run injects env automatically, doesn't it?

[unleashy]

@dblock what do you mean by env? just bog-standard ruby ENV?

[dblock]

@dblock what do you mean by env? just bog-standard ruby ENV?

Isn't Rack#run calling API#call(env)?

[unleashy]

Yes. Well, it's called for every HTTP request. What about it?

[dblock]

It's a way to inject something, no? At least Rack uses that as default? I am not saying we should not do configure, but i would like to hear some opinions on why we shouldn't "just use ENV"?

[unleashy]

I'm not sure how that would work. I can't see any way of injecting Rack's actual env without using a middleware (which is kinda onerous in my opinion). Of course, using ENV works fine:

# config.ru
require 'grape'

class API < Grape::API
  format :txt
  get '/' do
    ENV['hello']
  end
end

ENV['hello'] = 'bread'

run API

A GET / yields bread, as expected. Wait, actually, this could work fine lol so I think I see what you mean. Maybe #configure can use ENV:

API.configure do |config|
  config[:hello] = 'bread' # sets, idk, ENV['grape.config.hello'] = 'bread'
end

# ...

get '/' do
  configuration[:hello] # checks ENV['grape.config.hello'] as a last resort and
                        # tada, it exists
end

This would also fix the "non-inheritability" of the configure thingamajig. But, hmm, I'm not sure how elegant this API is; I mean, ENV is basically working as a kludgy dependency injection container. Thoughts?

[dblock]

Yes, ENV is a kudgy dependency injection container. I just wanted to bring this up as a thought, but I am not advocating for it.