A tricount like expense-sharing system written in Go
Go to file
2024-10-01 13:35:49 +02:00
api/openapi feat: use google/addlicense tool to add boilerplate 2024-09-30 23:40:34 +02:00
cmd/howmuch feat: use google/addlicense tool to add boilerplate 2024-09-30 23:40:34 +02:00
configs feat: project init 2024-09-30 22:32:53 +02:00
docs feat: project init 2024-09-30 22:32:53 +02:00
scripts feat: project init 2024-09-30 22:32:53 +02:00
.air.toml fix(air): add full_bin command 2024-10-01 10:06:04 +02:00
.gitignore feat: add Makefile 2024-09-30 23:53:53 +02:00
go.mod feat: hello world 2024-09-30 22:42:07 +02:00
go.sum feat: hello world 2024-09-30 22:42:07 +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 docs: init the project readme 2024-09-30 21:52:50 +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.