Hm, at least the handling of interface definitions seems very unidiomatic to me, specifically implementation packages also containing the interface definitions. At least those interfaces are not returned, but structs instead.
Usage of the internal/ package would make sense too. All in all this seems as it would benefit from some go specific patterns.
Options would be nice and i still do not understand the benefit of build tag based config compared to env or flag based approaches.
Indeed, the build tag approach here seems to be just config in code (and thus in version control), switched with compile time flags. Functionally very similar to using a flag when running to do the same thing. ENV or flags for every config option does get quite complex quickly, and you also need defaults so you end up with some config in code and some config passed in (thus keeping state outside the app). I prefer a config file myself, one file per environment, and you can keep them out of version control. Another option is a config service on the private network which apps communicate with to pull configs securely.
On the database side, I simply wouldn't use mongodb, and prefer sql migrations as they're simple and portable. I also prefer using the db for testing where required rather than faking behaviour with mocks.
Agreed interfaces really must be defined at the point of use.
Overall there is far too much abstraction here in pursuit of arbitrary structure borrowed from other people (Bob Martin,12 Factor).
Hm, at least the handling of interface definitions seems very unidiomatic to me, specifically implementation packages also containing the interface definitions. At least those interfaces are not returned, but structs instead.
Usage of the internal/ package would make sense too. All in all this seems as it would benefit from some go specific patterns.
Options would be nice and i still do not understand the benefit of build tag based config compared to env or flag based approaches.
Indeed, the build tag approach here seems to be just config in code (and thus in version control), switched with compile time flags. Functionally very similar to using a flag when running to do the same thing. ENV or flags for every config option does get quite complex quickly, and you also need defaults so you end up with some config in code and some config passed in (thus keeping state outside the app). I prefer a config file myself, one file per environment, and you can keep them out of version control. Another option is a config service on the private network which apps communicate with to pull configs securely.