I’d really be curious why you need the data to be structs in config.exs .

The simple answer is, of course, that I don’t need to do it this way. I’m just trying to figure out a “low effort” solution that works with our current code while we further weigh the pros and cons. The structs used in the configuration are used in conjunction with a custom protocol – each implementation of the protocol defines supervisor children for an app that acts something like a job queue with lots of interconnected processes.

Previously, we had configured this with a list of simple maps; the functionality pivoted based on a :type key in the maps. However, this got a bit messy – partly because it was easy to fat-finger keys and partly because the list of all these maps became quite long because the maps had to be verbose (there aren’t default values in regular maps, so each key had to be included). The configs were sometimes thousands of lines.

After several trip-ups from the use of simple maps, we thought we’d try using structs and a custom protocol. Perhaps the most important factor was that the configuration became easier to read and document when defined with structs. Readability was helped because structs can require certain keys and provide default values, and by using a protocol, we could open the door for adding customizations on top of this dependency: we have multiple apps that use this dependency in different ways – otherwise we could feed the configs into calls to struct/2 as you demonstrated.

So this latest iteration has some pros and cons that I need to sit with before taking another stab at it. I’m always wary when a solution feels too much like “pushing the river”, so I don’t think this is where things will land permanently, but I’m not yet ready to retreat back to how we had this before.