Question: Good practices for app config when using Aff/Eff

[benjstephenson]

I'm stating to have a play around with the Aff and Eff types that take a runtime and was hoping someone could give me some opinions on good way to handle config across an application.

Say we have some service in our application that takes some config as a dependency:

public class CustomerService
{
    private readonly CustomerServiceConfig _config;
    ...
}

If I wanted to add this config to a runtime that I can use with Aff<RT, T>, what's the best way to do that?
1 - have a single HasConfig trait that provides methods to access all the different config types for the whole application
2 - define a HasXXConfig trait for all the different types of config that parts of the application would need

I feel like option 2 would be nicer in theory as then only the config that's needed for the current service is accessible, but it would mean defining a lot of interfaces, traits and static accessor classes. On the other hand, option 1 would mean only one interface, trait and accessor class but having all of the config available to every consumer feels like a smell.

Are there some other approaches I could try out?

[louthy]

Both option 1 and 2 are fine, it really depends how much config you have. Remember you can inherit traits (because they're just interfaces), so you can have:

    public interface HasAppConfig<RT> { ... }
    public interface HasServiceConfig<RT> { ... }
    public interface HasWebConfig<RT> { ... }

And then package them up with inheritance:

    public interface HasConfig<RT> : 
        HasAppConfig<RT>, 
        HasServiceConfig<RT>, 
        HasWebConfig<RT>
   {}

That means you can use HasConfig in general areas of the application, and Has* in more specific areas, like a service-subsystem.

The other thing to remember is to only expose configuration that's not related to the underlying implementation(s) of any trtait.

For example, if you had a HasDatabase<RT> trait, then don't make your HasDatabaseConfig<RT> trait contain connection strings, or anything specific to the underlying database. Instead place the configuration into an evironment type and pass that into the construtor of the underlying implementation. There's another similar question to this where I give more specific examples.

The key reasoning behind this is that you don't want implementation details leaking into your runtime. It's there to be an abstract representation of IO. You shouldn't know whether the database you're 'connecting to' is SQL Server, or some in-memory solution.

[benjstephenson]

Remember you can inherit traits gah, I don't know why that didn't click in my head; that makes so much sense.
That example is really helpful, tysm!