Initializing the project

[lledargo]

The project will start with a postgres backend driven by a deno/oak API. An Angular client will interface will interface with the API. I'll need to break down the steps to initializing the different parts of this project.

[lledargo]

I think the best place to start is with the database design. In my latest commit ,ade0b16, I have created an Entity-Relationship Diagram using PlantUML, and I have attached the resulting image to this comment.

There will be an accounts table for tracking payers and payees. These payers and payees may be one of the user's accounts at a financial institution (where accounts::internal == true), or any other entity which one of the "internal" accounts transact with (where accounts::internal == false). Some examples of "external" accounts include vendors the user purchases good or services from, and clients or employers for receiving payments/payroll. Each account will have an "account_type" such as checking, savings, line-of-credit, or external to allow for specialized handling within the app. Accounts also have an "active" attribute to determine visibility of accounts within the app.

The categories table will track budget categories, master_categories is used to group categories (e.g. Groceries and Transportation might be grouped as Spending Money, Vacation or New Computer might be groups as Savings Goals). Both categories and master categories have an active attribute, again to control their visibility within the app.

The assignment_ledger table tracks the assignment of funds to categories and removal of funds from categories either for reassignment or for use to cover a transaction.

The tracking of transactions between accounts is split into 2 tables, transactions and transaction_parts. This allows for a transaction to be split between multiple categories and/or multiple payee accounts. As an example a user might purchase goods in multiple categories from a retailer through a single transaction, or the user may withdrawal cash from an ATM to pay multiple payees (which would appear as a single withdrawal to the user's financial institution).

As such the transactions table will track a primary account, as well as transaction date, and the cleared and reconciled statuses. The transaction_parts table will reference the parent transaction and it will track the secondary account, category, transaction amount, and memo for that part of the transaction.

[lledargo]

Commit 15dec1c48ce49add19bd60d4da807579a4cafe36 introduces a script to initialize the outlined database structure. Commit b7cde79b24d72e9491a9cd304dda7efee70fa853 Sets up some database unit testing using pgTAP. More unit test work to come for more complete testing coverage and better test organization.

[lledargo]

Commit 8a955b03836c83e4b9e236a58b46ac66e4033449 provides the promised database unit tests improvements as well as some database improvements (moved away from using default role, database, and schema).

There is obviously more work to be done on the database by adding functions, procedures, and views, but I believe the best next steps are to initialize the deno/Oak API and the Angular client. Once that is complete I can start exploring release structure and some processes for deploying a production environment.

[lledargo]

I finally found the time to initialize the API in 21e11a2348a00d3586013b3377f6ef2a17fc13c8. As I mentioned before, it is running on Deno and Oak. Tests are being performed by Deno's built in test framework, using superoak to mock requests.

Eventually I'll need to implement a test/mock/stub database, but I am still exploring options for this. A test database is likely to be easier to implement and less error prone. Whereas, a mock/stub database would be more correct in terms of unit testing methodology, but likely require much more work and increase the chance of errors in tests.

[lledargo]

As of b39bd7472e7296f2cdff34148dc1640e3d8c2a04 a dev-deploy has a database, API, and web client. The web client requests /accounts and console.logs the response it receives from the API/database. Test coverage is still poor on the API and web client, but the framework is in place to build more tests. Before going much further I am going to start trying to define what a release looks like.

[lledargo]

A simple release structure is in place as of 5901a0ca5fded302e9e2d88500bddcd68b1f4775. ng build is used to package the web client for browsers. deno compile creates a single binary file for the server which looks in ./static/ for the webclient, and ./db.json for configuration of the deno-postgres client. Finally dbinit.sql can be run on the postgres to initialize the app schema.

This release structure is far from ideal and is subject to change as the app grows, requirements change, or I become aware of better practices. Speaking of better practices, I'll be looking to implement linting next.