A tricount like expense-sharing system written in Go
Go to file
2024-10-01 23:36:22 +02:00
api/openapi feat: use google/addlicense tool to add boilerplate 2024-09-30 23:40:34 +02:00
cmd/howmuch feat: use cobra to run the app 2024-10-01 13:37:31 +02:00
configs feat: integrate cobra+viper into the app 2024-10-01 21:43:44 +02:00
docs feat: project init 2024-09-30 22:32:53 +02:00
internal feat: Implement logging module with zap 2024-10-01 23:36:22 +02:00
scripts feat: project init 2024-09-30 22:32:53 +02:00
tmp feat: integrate cobra+viper into the app 2024-10-01 21:43:44 +02:00
.air.toml feat: integrate cobra+viper into the app 2024-10-01 21:43:44 +02:00
.gitignore fix: remove vue ignore added by accident 2024-10-01 14:04:49 +02:00
go.mod feat: Implement logging module with zap 2024-10-01 23:36:22 +02:00
go.sum feat: Implement logging module with zap 2024-10-01 23:36:22 +02:00
LICENSE feat: use nishanths/license tool to generate license 2024-09-30 23:24:17 +02:00
Makefile fix(makefile): add-copyright target 2024-10-01 13:35:49 +02:00
README.md feat: Implement logging module with zap 2024-10-01 23:36:22 +02:00

howmuch

A tricount like expense-sharing system written in Go


It is a personal project to learn go and relative technologies.


Project Diary

2024/09/30

The idea comes from a discussion with my mom. I was thinking about doing some personal budget management thing but she brought up the expense-sharing application that could be a good idea. I explained why it was a terrible idea and had no value but in fact it was a really a good idea.

First I have to set up a web server. I'm thinking about using gin, since I have played with chi in other projects.

Then I have to add some basic support functions like system logging, versioning, and other stuffs.

Next I need to design the API.

  • User management: signup, login, logout.
  • A logged-in user must be able to:
    • create an event
    • add other users to that event
    • A user can only view their own events, but not the events of other users'
    • A user can add an expense to the event (reason, date, who payed how much, who benefited how much)
    • Users in the event can edit or delete one entry
    • changes are sent to friends in the event
    • User can get the money they spent themselves and the money they must pay to each other
    • User can also get the total amount or the histories.

That is what I thought of for now.

Thus, Besides a web server, I must have a database that can store all the data. ex. PostgreSQL. I need a message queue system (RabbitMQ?) to handle changes for an event. That will results in a messaging service sending emails.

I also want to use Redis for cache management.

What else?

OpenAPI + swagger for API management.

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; etcds consistency is crucial for correctly scheduling and operating services. The Kubernetes API server persists cluster state into etcd. It uses etcds watch API to monitor the cluster and roll out critical configuration changes.

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.

2024/10/02

Logging

Use zap for logging system. Log will be output to stdout for dev purpose, but it is also output to files. The log files can then be fetched to Elasticsearch for analyzing.