Configuration package improvements (validation and data structure)

[System-Glitch]

#210 #211 started a discussion on inconveniences with the configuration package, especially when it comes to more complex data structures (slices of structures for example) and validation of the entries. I would like to take some time and think about improvements for the config package, or maybe a redesign for a future major version.

Please share here your wishlist for the configuration package, talk about your use-cases, etc. Feel free to share your ideas!

[BowlOfSoup]

Thanks for creating this discussion. I have several use-cases.

1. Support for slices of structures
For example; I want to support and configure a set of API clients, which use in the code is based on user input via an API request. The configuration I would like to use can look like this:

"some_config_list_of_endpoints": [
    {
        "name": "dummy entry",
        "api_key": "value123",
        "url": "https://example.com",
    },
    {
        "name": "yet another entry",
        "api_key": "uuid-something-something",
        "url": "https://some-url.com",
    }
]

I would like to have the some_config_list_of_endpoints as key/category and the specific properties, defined and validated. This will make Goyave more flexible and adaptable for varying config requirements.

2. Configuration in structs
To use configuration in certain services we could pass the main server or config struct and Get() config from there, but wouldn't it be great if we could pass specific configuration itself to services/functions to have clear separation of concerns? Why would I pass so much (potentially) information around if I just need the some_config_list_of_endpoints config? We could 'unmarshal' the config into structs.

• Better separation of concern
• Enhanced type safety
• Improved testability (of code that uses the config)

var EndpointConfigs []EndpointConfig // example

type EndpointConfig struct {
	Name      string `json:"name"`
	ApiKey    string `json:"api_key"`
	BaseUrl   string `json:"url"`
}

3. Content validation for configuration
Currently (upcoming Goyave 5.1) supports 'required' validation. This means that I can assert that the name property of the above config is required and should not be nil or be omitted entirely. This is good, but I would like to take it a step further by validating the actual value.

3.1 Validation through using a RuleSet (per entry)
This can be done like:

config.Register("some_config_list_of_endpoints.name", config.Entry{
	Value: "",
	Type:  reflect.String,
	Validation: v.RuleSet{
		Path: ".", 
		Rules: v.List{v.Required(), v.String(), v.Min(1)},
	}
})

This would remove boilerplate, because one does not have to define a separate validation layer in their app for config.

3.2 Validation via the eventual struct
This idea needs suggestion 2, putting the configuration in defined structs. We could then define validation on the struct and go from there. Example:

type CustomAuthService struct {
	Url string `json:"url" validate:"required, type=string, min=1"`
}

This way we circumvent "manually" defining the RuleSets and the need for validation boilerplate. Also this way we centralize defining, validation and containing configuration within Goyave.

We could even look into supporting custom validation libraries like go-playground/validator (or build better, because there are some quirks in that lib).

Generic Pros

• Goyave's configuration system would be more robust with these changes
• We have an enhanced development experience, develop faster and safer
• Improved flexibility and scalability
• Improved centralization of config logic overall

Possible cons

• We need to make sure performance is not negatively impacted
• We should keep backward compatibility in mind (breaking changes).

[System-Glitch]

By using an interface instead of *config.Config in the validation package, we would remove the hard dependency and could probably use the validation system directly in the config package. Using such interface would still be considered a breaking change though, as the config type available to validators would be different and would be missing the Set() method (which they weren't supposed to use though).