Add account, nonce, and user schemas, and mock Postgres

[shanejearley]

See the @casimir/data README for background (and ignore the Jupyter notebooks).

For convenient iteration, running npm run dev (scripts/local/dev.ts) now hits npm run watch:postgres --workspace @casimir/data when local mock is enabled (default). The database reloads any changes from the @casimir/data schema files.

See a usage example in the @casimir/users service /user route (getUser from useDB).

Remaining task(s):

• Show stdout from spawn process in terminal (to notify when database is reloaded/ready)

Infrastructure, migrations, and environment variables are coming in a PR next week.

[shanejearley]

@ccali11 also added a seed script to users API. So to get up and running.

1. Run development server with mock @casimir/user API and mock @casimir/data database with default accounts, nonces, and users tables.

   npm run dev # --clean=false to keep data/database from previous run

2. Seed the database with mock store of users from @casimir/users/src/mock/user.store.json. (Right now just one user – this primary account is also added to accounts.)

   npm run seed --workspace @casimir/users # --resource=account to seed with something like `@casimir/users/src/mock/account.store.json` instead. Just add a mock store file and also a corresponding path to the /seed route.

3. Editing the schema files in @casimir/data/src/schemas will reload the database. This takes a minute, but in the meantime, there are manual changes sometimes need to be made (like changing the mock store data or @casimir/types).
4. When you are done and have stopped the development server, you can clean up the database (environment and data).

   npm run clean:postgres --workspace @casimir/data

With some optimization as we go, this can become much faster and convenient with better database bootstrapping and type generation (@hawyar is looking into schema-to-type generation).

[hawyar]

This sets great foundation for schema changes and using the JSON schema allows us to safely generate TS types. I have a working example that works with all our current schemas.

To generate correct types for properties of type array and object we should add the items properties. For example, the snapshot could be represented as snapshot: Array<Snapshot> instead of just Array<any>. Same goes for transactions: Array<Transaction>

Example:

"snapshot": {
  "type": "array",
  "description": "The account snapshots",
  "items": {
    "type": "object",
    "properties": {
      "date": {
        "type": "string",
        "description": "The date of the snapshot in ISO 8601 format"
      },
      "balance": {
        "type": "number",
        "description": "The balance of the snapshot"
      },
      "anotherprop": {
        "type": "string"
      },
    },
    "required": [
      "date",
      "balance"
    ]
  }
}

and the type output would look something similar to:

interface Snapshot {
  date: string;
  balance: number;
}

interface Account {
  snapshots: Array<Snapshot>;
  transactions: string[];
  // the rest
}

[shanejearley]

@hawyar Great! Thank you and nice work. Do you want to commit a change to add the array items field where it's currently needed? Just added items to snapshots as you mentioned, but leaving the rest of the missing props for us to fill out and iterate in another few PRs this week.

Thinking one other PR will also be to move some of this typegen logic into @casimir/data (or the existing @casimir/types, since that would be a nice place to output types), and then hook into the existing workflow (in the repo prepare and dev scripts for convenience). Happy to plug in the last part if you take up the first (maybe a PR off of this branch or after it's merged).

[hawyar]

Sounds good. After this is merged I will add typegen and update the rest of the schema as needed.

[ccali11]

@shanejearley @hawyar Looks great, guys. Will dive into this with my tasks this week and note any opportunities for changes/improvements.

[shanejearley]

Ready to review workflow and merge whenever. Schema reloads will be slow but will become much faster once we add proper migrations for schemas (which will be required when we add the deployment infra anyways).

[ccali11]

@shanejearley - did you want a sync review before merging? up to you.