yuriytkach / fundraiser-tracker Goto Github PK

Currently only the integer amount can be tracked.
Need to support specifying decimal amount in track command.

Since we're storing simple secrets without rotating or managing them, we can use AWS SystemsManager property store.
The main reason - AWS SSM is free to use for our simple secrets. And the SecretsManager is $0.04 per month :)

When we see a debit (money out) transaction in either Privatbank statement (type is D) or Monobank (negative amount), then we can notify somehow about that, as it can lead to potential issues. Notification can be via slack channel, for example, or Slack private message (which is better). Email works as well, if needed.

Migrate to Java 17, updated github actions and pom.xml file accordingly

Currently, we import aws sdk v1 library for dynamodb with test scope because we use it in tests to do direct calls to dynamodb without quarkus involved.

Let's move to sdk v2

If two http requests come to track donation simultaneously it can start 2 lambda functions in parallel. Then we'll have a race condition in updating fund total - both lambdas will read the current fund total, then add a sum and then write. This can lead to one write overriding the other. We need to resolve that with DynamoDB conditional writes.

We could have used sqs to publish event there and then process them one by one, but that will require to have SQS. If we're still OK and within the processing time limit from Monobank to perform conditional write, then that could be easier to implement.

For fund list REST endpoint let's add sort ASC/DESC query param that will allow to return sorted entries by donation date. Default is DESC.
Also, let's add page and size query params that will allow to return paginated items.

Add command to disable fund that should lead to the following outcomes:

• cannot track donation - should respond with error that fund is disabled
• when viewing all funds, disabled funds should show at the bottom
• when returning fund status and list of funders it should set browser cache to 1 month (configurable)

Obviously, since we will have command to disable fund, we should also have command to enable fund :)

Use the signing secret from Slack to verify message instead of older token that is used now.
For information on signing secrets see https://api.slack.com/authentication/verifying-requests-from-slack

Basically, a filter can be added that will verify messages before continue with command processing

The single table design is likely more appropriate. Here's why:

• Moderate Data Volume: The number of records per fund is not so large that it would necessitate separate tables for performance reasons.
• Temporary Funds: The temporary nature of funds means that the number of active tables would continually grow, increasing management overhead.
• Access Patterns: Most queries are for the current fund, which can be efficiently handled with a GSI (Global Secondary Index).
• Simplicity: A single table is simpler to manage, and you can use GSIs to efficiently query for donations related to a specific fund.

Arguments for Separate Tables (good arguments, but something that we don't need):

• Isolation: Each fund is completely isolated from the others. This can simplify some aspects of data management, such as access control, backup, and deletion.
• Schema Flexibility: If different funds might have slightly different data requirements, separate tables can accommodate these differences more easily.

Since we already have separate tables, we would need to write a script that first populates that newly created table with data from existing donations tables. We have switch in lambda to single donation's table, deploy it and then run the script. For a short time list of donators won't be visible, which is fine.

This will require to re-write the common code for tests, as we would need to create tables in some code that will be executed at the beginning, before all tests start.

Details

When donation is tracked the fund's total amount is updated. Currently it simply adds donation amount to fund and then saves the fund. When saving we should use DynamoDB's conditional write to verify that current fund amount is what it was before added the donation amount. If condition fails, then we should retry at most 3 times with exponential backoff. On every retry we should recalculate new fund total based on new total that is present in DB.
Add integration test to check that update does not happen if current fund amount in DynamoDB is not what we expect.
Use 'final' keyword for local variables and function parameters.
Validate for unused imports and remove those.
Use 2 spaces indentation.

Create GitOps Actions for building release package (function.zip) and upload it to Release so it could be downloaded

Create a script for AWS infrastructure setup.

It can be either CloudFormation or Terraform.

The list command from Slack returns all funds. Since number of funds can be huge, let's return only active (enabled) funds. And allow to view all with the help of -all parameter.

Currently, the slack token is provided in Environment variable.
Also, after we add support for Privatbank statements upload we would need to store token somewhere.

The AWS Secrets Manager is a good place to store secrets there. Also, quarkus has support for it!

Details

If two http requests come to track donation simultaneously it can start 2 lambda functions in parallel. Then we'll have a race condition in updating fund total - both lambdas will read the current fund total, then add a sum and then write. This can lead to one write overriding the other. We need to resolve that with DynamoDB conditional writes.

Add support with special slack command to be able to track spending of fund.

Command to support:
spend 1500 uah 2022-05-29 11:14 "Buy the drone", where

• spend - command name (required)
• 1500 - amount (required)
• uah - currency (optional, use fund's currency by default)
• 2022-05-29 - date (optional, use today's date by default)
• 11:14 - time (optional, use current time by default)
• "Buy the drone" - description (optional, put something by default)

Tracking of spending should go into separate table.

Add field to Fund object called spent to track total amount that was spent. Update that field each time a spending is recorded.

Return total spent amount when processing list command.

Return all spending records together with donations records when processing list <fundname> command.

Add support for the edit fund command.
It should allow to edit fund data, like goal, currency, description, color.
If currency is changed, the raised field should be converted to new currency.