docs: the basic parts of a go project

README.md

@@ -54,3 +54,53 @@ And last but not least, `Docker` + `Kubernetes` for the deployment.
 
 That is what I am thinking of for now. I will note down other ideas during
 the project.
+
+### 2024/10/01
+
+A Go application has 3 parts:
+
+- Config
+- Business logic
+- Startup framework
+
+#### Config
+
+The application provides a command-line tool with options to load configs
+directly and it should also be able to read configs from the yaml/json files.
+And we should keep credentials in those files for the security reasons.
+
+To do this, we can use `pflag` to read command line parameters, `viper` to
+read from config files in different formats, `os.Getenv` to read from
+environment variables and `cobra` for the command line
+tool.
+
+The execution of the program is then just a command like `howmuch run`.
+
+Moreover, in a distributed system, configs can be stored on `etcd`.
+
+> [Kubernetes stores configuration data into etcd for service discovery and
+cluster management; etcd’s consistency is crucial for correctly scheduling
+and operating services. The Kubernetes API server persists cluster state
+into etcd. It uses etcd’s watch API to monitor the cluster and roll out
+critical configuration changes.](https://etcd.io/docs/v3.5/learning/why/)
+
+#### Business logic
+
+- init cache
+- init DBs (Redis, SQL, Kafka, etc.)
+- init web service (http, https, gRPC, etc.)
+- start async tasks like `watch kube-apiserver`; pull data from third-party
+services; store, register `/metrics` and listen on some port; start kafka
+consumer queue, etc.
+- Run specific business logic
+- Stop the program
+- others...
+
+#### Startup framework
+
+When business logic becomes complicated, we cannot spread them into a simple
+`main` function. We need something to handle all thoses task, sync or async.
+That is why we use `cobra`.
+
+So for this project, we will use the combination of `pflag`, `viper` and
+`cobra`.