initial release testing
This commit is contained in:
55
docs/adr/0001-monolith-nextjs-sqlite.md
Normal file
55
docs/adr/0001-monolith-nextjs-sqlite.md
Normal file
@@ -0,0 +1,55 @@
|
||||
# ADR 0001: Use a Next.js Monolith with SQLite for Initial Deployment
|
||||
|
||||
- Status: Accepted
|
||||
- Date: 2026-03-23
|
||||
|
||||
## Context
|
||||
|
||||
The system needs to support inventory management for stocked parts and assemblies, sales orders and shipping, purchase orders and restocking, customer and vendor records, and an initial accounting module. The first deployment target is a single Docker container on Unraid with SQLite as the database.
|
||||
|
||||
## Decision
|
||||
|
||||
Use a single Next.js application with TypeScript and SQLite.
|
||||
|
||||
Key aspects:
|
||||
|
||||
- UI and backend live in one deployable unit
|
||||
- SQLite is the primary datastore and is persisted through a mounted `/data` volume
|
||||
- Inventory is modeled as a transaction ledger, not an editable balance table
|
||||
- Assemblies are first-class items with bill-of-material component records
|
||||
- Accounting starts as an operational journal tied to stock-affecting workflows
|
||||
|
||||
## Alternatives Considered
|
||||
|
||||
### Separate frontend and API services
|
||||
|
||||
Rejected for now because it adds deployment and operational complexity that does not help the initial Unraid target.
|
||||
|
||||
### Python monolith
|
||||
|
||||
Reasonable, but not selected because the project defaults favor TypeScript for full-stack work and Next.js gives a fast path to a polished UI and server-rendered workflows in one application.
|
||||
|
||||
### Direct quantity-on-hand fields without a transaction ledger
|
||||
|
||||
Rejected because the system needs reliable traceability for receipts, builds, shipments, and later accounting reconciliation.
|
||||
|
||||
## Consequences
|
||||
|
||||
### Positive
|
||||
|
||||
- Simple deployment model
|
||||
- Minimal infrastructure requirements
|
||||
- Clear path from operational workflows to accounting entries
|
||||
- Good developer velocity for admin and internal-tool style features
|
||||
|
||||
### Negative
|
||||
|
||||
- SQLite concurrency limits will eventually matter at larger scale
|
||||
- Server actions are tightly coupled to the app process
|
||||
- Accounting capabilities are intentionally lightweight at this stage
|
||||
|
||||
## Follow-Up
|
||||
|
||||
- Add auth and permissions before multi-user production rollout
|
||||
- Add partial receipt and shipment workflows
|
||||
- Add lockfile and CI once dependencies can be installed in a build-capable environment
|
||||
Reference in New Issue
Block a user