finnow/finnow-api
Andrew Lalis b63ebef660
Build and Deploy API / build-and-deploy (push) Successful in 1m43s Details
Fix ddoc.
2026-03-14 22:37:36 -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 Fix ddoc. 2026-03-14 22:37:36 -04:00
sql Added internal_transfer attribute to transactions, migration of schemas automatically. 2025-10-23 22:02:37 -04:00
.gdbinit
.gitignore
README.md
currency_codes_ISO4217.csv
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 dub versions. 2026-03-14 22:35:46 -04: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.