Gyllsdorff

Configuring Plugs during runtime

The Plug.init/1 method gets called during the compile step and not during the startup like I thought, is there someway to update a plugs config when the router supervisor tree is being setup?

Background info: All of our applications/servers/api:s connect to a configuration server during startup and loads their config at that point, without the config the applications will not work since the configuration contains things like “How are the authentication rows formatted in redis”. The configuration can change depending on which datacenter the application will end up in so we can’t tell the application this during the compile step or by using environment variables.

Now, this was a easy problem to solve for most of our elixir apps, just add the configuration genserver to the top of the supervisor tree, it loads the config and the rest of the genservers can query it in their init/1 calls. Our only problem is the Plugs init/1 functions which are called during the compilation and we don’t have access to the configuration at that point. The config is a deeply nested, large (200 000 rows) map which means asking for the configuration rows each request might be too expensive.

We can of course just extract the plug functionality into a genserver but I would prefer to avoid the extra step if we could avoid it.

13 comments

#plug #how-to-question

0 4933 13

2018-08-12 14:48:00 UTC

First Post!

idi527

You can add a separate plug in the beginning of your “plug pipeline” to assign the necessary values into :private or :assigns fields, which can then be accessed by other plugs down the line.

This separate plug would act like the init callback in a genserver.

Post #1

Most Liked

Gyllsdorff

That was what I was afraid of. I think we will just add a backing genserver for each plug. If the plugs behaved like genservers then we would not have had this problem but perhaps the the current plug behaviour gives you some other benefits.

Post #4

idi527

Plugs are functions, basically … so they can’t really behave like genservers.

Why would you add a genserver for each plug though? Wouldn’t one be enough? It would be a bit more efficient (less message passing between processes, the webserver’s and your genservers’).

But I would probably go with the :code.load_binary/3 approach (you can see how it works in the fastglobal library), because calling genservers might result in a bottleneck.

Post #5

i-n-g-m-a-r

well I guess I expect the “runtime cache” to exist within the Plug.
to me init means setup the plug once initially, so not necessarily at compile time, but preferably at runtime using environment variables.
then call means use the configured settings that are already in place.

I would like to not only read values from environment variables into settings but also validate those settings as soon as the application starts (once). it seems “init” would be a nice place to be able to do that, just like Repo.init/2 and Endpoint.init/2.

Post #11

Last Post!

i-n-g-m-a-r

thx @LostKobrakai - I’m not very satisfied with that approach, but I guess there’s no way around it, unless you’re willing to (re)write your own plugs.

Post #13