go-patterns VS service

3). GO Patterns

Re Go, there are a lot of lot of good patterns available available, but a lot of them aren’t OOP specific. In fact, both Go and Rust have been influenced by multiple paradigms, including OOP. Like the FAQ says,

What's great is there are really great patterns to follow out there on github (both code patterns https://github.com/tmrts/go-patterns and examples https://github.com/avelino/awesome-go https://github.com/go-kit/kit and for the app itself, https://github.com/golang-standards/project-layout )... and for me a really naggy mentor who insists everything be "idiomatic go"

So I am trying to write a simple generator based on this pattern and the results are a little counter-intuitive. My goal is to create a generator like the above that takes a net.IPNet object and ranges over all net.IP`'s contained in that network. When printing results, I am seeing the same values show up in subsequent executions of the loop and am not sure why. Code follows:

Ultimate Service was useful for me. None of the "backend" concepts were new, but you get to see how Bill would layout/design an API-based service. If you're experienced you'll notice the opinionated choices he makes, and I found myself saying "Nah, I'm not sure I'd do it like that". I appreciated its use of Kubernetes and KIND as I'd never played with them before. How he uses Docker to spin up a DB instance for tests is pretty cool. There's a lot of copy & paste as you code along with him (you copy from the "finished project" and paste into your work in progress). The full example project is online at https://github.com/ardanlabs/service. You won't write all that code, and this version is newer than the one I did, but it gives you an idea of what you might learn.

So what can you do insted? For testing databases, setup a docker instance for tests (e.g. like in https://github.com/ardanlabs/service), or start an embedded-postgres daemon (see https://github.com/fergusstrange/embedded-postgres). For communication with external APIs, just pass the http.Client (either in context.Context or as a field on the struct). Then in tests, you can override the http.Client.Transport func.

Take a look at https://github.com/ardanlabs/service from Bill Kennedy. You can probably simplify the structure a bit since your project is minimal, but that repo is gold.

Checkout https://github.com/ardanlabs/service for inporation. Tip: try to avoid creating a service package with all services, a domain package with all domain structs, etc.

Or go through this repo https://github.com/ardanlabs/service

I've seen this handler modification and wrapping pattern in Ardan Labs' service repository. https://github.com/ardanlabs/service/tree/master/foundation/web

https://github.com/ardanlabs/service This is something which I really like and has taken into account a lot of engineering decisions.