Ok...I've thought about this a whole bunch. It took a while but after a lot of feedback and pain implementing this at work, I've come to the conclusion that Vapor needs to do about 10% of what its currently trying to do.
I believe that Vapor should be about exactly 1 thing: loading configuration values. In 99% of cases, all we want to do is load configuration values and pass them down to our children processes. Because we're just passing down data it's easier to spin up children in tests or in other use cases. But with Vapor's current design we're forced to modify children to fetch configuration in start link - coupling the child to vapor - or start vapor outside of the supervision tree. Neither of these are good solutions and cause quite a bit of friction. If we remove storage and watching these problems go away. I think this is an acceptable tradeoff. The user is still able to build that same functionality on their own if that's required in their application.
Ok...I've thought about this a whole bunch. It took a while but after a lot of feedback and pain implementing this at work, I've come to the conclusion that Vapor needs to do about 10% of what its currently trying to do.
I believe that Vapor should be about exactly 1 thing: loading configuration values. In 99% of cases, all we want to do is load configuration values and pass them down to our children processes. Because we're just passing down data it's easier to spin up children in tests or in other use cases. But with Vapor's current design we're forced to modify children to fetch configuration in start link - coupling the child to vapor - or start vapor outside of the supervision tree. Neither of these are good solutions and cause quite a bit of friction. If we remove storage and watching these problems go away. I think this is an acceptable tradeoff. The user is still able to build that same functionality on their own if that's required in their application.