finnow/finnow-api
Andrew Lalis 3394869410
Build and Deploy Web App / build-and-deploy (push) Successful in 1m8s Details
Build and Deploy API / build-and-deploy (push) Successful in 2m48s Details
Refactored category spend and balance analytics.
2026-03-10 21:50:35 -04:00
..
bruno-api/Finnow Added balance time series, fixed file selector behavior. 2025-11-04 17:20:49 -05:00
sample-data Added balance time series, fixed file selector behavior. 2025-11-04 17:20:49 -05:00
source Refactored category spend and balance analytics. 2026-03-10 21:50:35 -04:00
sql Added internal_transfer attribute to transactions, migration of schemas automatically. 2025-10-23 22:02:37 -04:00
.gdbinit Added confirm modal, ability to add profiles. 2025-08-03 10:46:01 -04:00
.gitignore Added web app, refactored api to use new handyhttp. 2025-08-01 18:43:58 -04:00
README.md Added bruno API thing, user account page, and user deletion logic. 2024-09-19 15:12:23 -04:00
currency_codes_ISO4217.csv Added basic auth system, profiles, and start of models and data. 2024-07-31 13:20:17 -04:00
currency_symbols.csv Added transaction searching, optimized transaction fetching as well. 2025-10-19 10:38:35 -04:00
dub.json Upgrade to SLF4D 4.2.0, simplify config. 2025-11-18 20:40:22 -05:00
dub.selections.json Upgrade dependencies, hide verbose logging. 2026-01-15 07:54:47 -05:00
finnow-api.service Added finnow-api.service, api.yaml workflow. 2025-08-08 18:56:08 -04:00

README.md

Finnow API

The Finnow API is primarily implemented as an HTTP REST API using D, and the handy-httpd library.

Architecture

This project is set up as a modular monolith, where the API as a whole is broken up into mostly-independent modules. Each module can be found under source/, like source/auth for example.

Within each module, you'll usually find some of the following submodules:

  • model.d - Defines models for this module, often database entities. Unless there's a very good reason for it, all entity attributes are marked as const. Entities are not mutable. They simply represent a view of what's in the database.
  • data.d - Defines the data access interfaces and associated types, so that other modules can interact with it.
  • data_impl_*.d - A concrete implementation of a submodule's data access interfaces, often using a specific technology or platform.
  • api.d - Defines any REST API endpoints that this module exposes to the web server framework, as well as data transfer objects that the API endpoints may consume or produce.
  • service.d - Defines business logic and associated types that may be called by the api.d submodule or other modules. This is where transactional business logic lives.