* Reorganizing code into more logical modules:
- `routes` specifically for Rocket handler functions
- `receipts` data model for receipts
- `transactions` for Firefly transactions
* Encapsulate database operations for receipts using the repository
pattern; move SQL queries to external files (`sqlx` can only use
string literals or external files for queries, not variables or
constants)
* Remove obsolete routes, templates for old transaction-focused pages
Rethinking the workflow again. Requiring the transaction to be present
in Firefly already will be problematic for two very important cases:
* Gas station purchase never show up in Firefly automatically
* HSA purchase show up hours or days later and have no information
besides the amount
These are arguably the most important cases, since they are the ones
that really need receipts in order to keep the transaction register
correct. Thus, we need a different way to handle these types of
transactions.
Really, what I need is a way to associate transaction data with an image
I really liked the original idea of storing receipts in Paperless, but
that ended up not working out because the OCR failed miserably and thus
made it impossible to search, so finding a receipt meant looking at each
image individually. I think, therefore, the best solution is to store
the images along with manually-entered data.
To implement this new functionality, I am using `sqlx`, a SQL toolkit
for Rust. It's not exactly an ORM, nor does it have a dynamic query
builder like SQLAlchemy, but it does have compile-time checking of
query strings and can produce type-safe query results. Rocket has
support for managing its connection pools as part of the server state,
so that simplifies usage quite a bit.
On the front-end, I factored out the camera image capture into an HTML
custom element, `camera-input`. I did not update the original form to
use it, since I imagine that workflow will actually go away entirely.
Instead of reading our own TOML file for configuration, we can hook into
Rocket's [built-in configuration system][0]. Although it doesn't matter
much right now, it may if we end up using Rocket's SQL [database
integration][1], because it uses the same mechanism. Without making
this change, we would end up with two configuration files in that case.
[0]: https://rocket.rs/guide/v0.5/configuration/#extracting-values
[1]: https://rocket.rs/guide/v0.5/state/#databases
Dustin