Yes and written by some of the people involved in the original net package. Brad used to be one of the maintainers of net/http and net packages in go. I'm glad they are so conservative about changing the standard library though, even if it does mean warts like this persist.
Our crypto banking software development solution provides all the necessary banking functions that your customers expect from their core banking platform. It is designed to handle all your customers’ needs with secure API, intuitive front-end, and banking modules. To get complete information, visit our website today and get a free white label software demo.
Thanks for posting, this looks really interesting. The main problem I suppose would be deliverability, so you'd have to set up reverse DNS, SPF etc. use a rented server, and perhaps warm up the ip for a while.
Yes. I'm interested in this? Any links and research you want to share? Most localization is done with js and these guys localizejs.com even put it in their domain :) But if there is any Golang solution for this I wouldn't know.
The article does link to that blog post, and points out some problems with it.
I'm not a fan of this design either personally, in particular requiring a v2 suffix, I think it makes assumptions about versioning which don't withstand scrutiny, e.g. that major versions are always used for major breaking changes. In my experience they are more often used to indicate major feature releases.
I'd really rather go kept the culture of no breaking changes rather than explicitly encouraging them if you move past 1.x.
Looks like there's been a bit of work put in. I especially like how there's multiple sql drivers supported. Instructions on how to add slack were especially nice, I'd been somewhat stuck on the legacy keys (now deprecated).
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).