dynamic application_id and api_key

[ericsullivan]

I needed a way to specify the application_id / api_key per index (for a multi-tenant application).

In our case each tenant can have different fields that we index on, so we created one index (module) per tenant. That allowed the application_id / api_key to be a zero-arity function.

There's a little duplication on the requests application_id and the url_params application_id. I liked how the routes interpolated all the url_params though so I didn't want to have a special case.

[Jordan-Kowal]

Hey there! Thanks for your contribution and sorry for the lack of response! We'll try to have a look at this during the week 😊

[Jordan-Kowal]

Sorry for the late reply! Great work on the implementation 🔥 . We think it could be a great feature addition, but we'd like to discuss the implementation itself!

While we did drill-down module and settings in the past to perform apply(module, ...) like you did in your Utils.api_key function, it might be overkill to do it for every customization option. On top of that, we're working with application ID and api keys, which are sensitive information most likely stored in env variables.

Another way we could simplify this would be to simply set this up during the configuration, in the runtime.exs of your application:

config :algoliax,
  credentials: %{
    default: {"APPLICATION_ID", "api_key"},
    custom_1: {System.get_env("APP_ID_1"), System.get_env("APP_KEY_1")} # Reachable then using `Application.get_env`
    custom_2: {System.get_env("APP_ID_2"), System.get_env("APP_KEY_2")}
  }

Then, in your Indexer, you'd simply need to add within the settings something like credentials: :custom_1. And finally, we could simply fetch the id/key at any point with the credentials options and a custom utils function (which would return the default if not is provided and default exists)

This would avoid drilling down module + settings everywhere, and we could get away with passing down only one specific settings where we need to.

Would that still work with your usecase?

[ericsullivan]

@Jordan-Kowal What you suggested was close to how I had implemented this in my application. I skipped the default key as I thought it added confusion when there's already the application_id / api_key and the top level configuration (and I didn't want to deprecate that)