Kuule hain nussivan posted:

Hello Go-thread. I'm planning my first Go-project with a couple of people and am having a hard time figuring out whether my design choices are sane or not, please help if you have the time.

The plan is to make a backend consisting of several microservices and run it off Google Cloud Run. A Kubernetes Engine would probably be a better choice, but it doesn't have a free tier and we don't want to spend money, so we decided that Cloud Run should be fine for a proof-of-concept / minimum viable product. My background is primarily in C#, so I'm used to singletons and the like. So my plan was to have my main.go file instantiate a single copy of my other classes (logger, db, etc.) and then pass pointers around. For example, my db class does some logging, so after creating an instance of the logger in main, I would then create an instance of the db class and pass a pointer of the logger to the db class, instead of creating a new instance specifically for the db class. To me, this also feels like it would mesh well with Cloud Run, because there's generally no need to create multiple instances of service classes.

Does this seem sensible? It's technically not a strict singleton, since there's nothing limiting me from creating 10,000 loggers in main. Because of this, I think trying to keep a singleton pattern going on might be a bad idea, and if someone else keeps working on the project it'll eventually lead to a situation where you have a mixed bag of a single instance being passed around as a pointer and some classes creating their own instances. Is there a way of forcing a strict singleton pattern with go? Am I overthinking this too much and should I just go gently caress it and implement what feels good to me?