tblumer/obsidian
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Correct TallyFlow architecture based on source code review in ~/src/

Browse Source 
- Core is central and owns MongoDB (not Assets)
- Core: Go backend + Vue.js frontend (no Node.js)
- Verified against tallyflow-web, photomicroservice, tallyflow-iot, tallyflow_mobile, tallyflow-print
- Updated diagram, legend, cards, and description for accuracy
This commit is contained in:
TNB
2026-07-07 09:15:19 -04:00
parent 31d267a211
commit 0bbe00b75e
2 changed files with 108 additions and 106 deletions
Download Patch File Download Diff File Expand all files Collapse all files
TallyFlow/TallyFlow-Architecture.md
+21 -14
View File
@@ -2,26 +2,33 @@
**Diagram:** [[TallyFlow-Architecture-Diagram.html]]
## Overview
## Overview (Source-Verified)
TallyFlow is a modular asset tracking platform centered on **TallyFlow Core**, the central web backend and integration hub. All other components synchronize with Core for asset registration, configuration, reporting, and data consistency.
TallyFlow's architecture is centered on **TallyFlow Core**, which serves as the single integration hub and owns the primary data store.
**TallyFlow Assets (Mobile)** is the primary field application for lightweight inventory management, geiger-counter-style seek & find, fast enrollment, zone movements, and shipping workflows.
**Core** consists of:
- Go backend (API layer, business logic, using Echo/gRPC patterns)
- Vue.js 2 web frontend (tallyflow-web) for asset management, reporting, and configuration
- MongoDB database (owned by Core) storing the asset registry, tags, photo metadata, zones, events, and audit history
**TallyFlow Capture** (rebranded from PhotoTag) enables photo documentation by associating images with barcodes, work orders, serial numbers, and other metadata for quality control and visual record-keeping across incoming, in-process, and outgoing inspections.
All other components communicate exclusively through Core's REST + WebSocket APIs.
**TallyFlow Print** handles on-demand Zebra ZPL-compatible label printing and RFID encoding, with optional automatic registration back into Core.
**TallyFlow Assets (Mobile)** is a Flutter application focused on field operations: lightweight inventory, geiger-counter-style seek & find, fast enrollment, zone movements, and shipping workflows. It syncs with Core.
**IoT** provides real-time location, environmental sensor data (temperature, humidity, shock), and fixed RFID reader integration (Impinj, Zebra) via MQTT/HTTP/BLE, feeding live events into Core.
**TallyFlow Capture** (PhotoTag) is implemented as a Go microservice (photomicroservice) that handles photo + barcode association for quality control and visual documentation. It stores photo metadata in its own MongoDB collections but registers assets and events back to Core.
Data is persisted in **MongoDB**, which stores the asset registry, tag events, photo metadata, zones, and full audit history. Bulk onboarding is supported via Excel import. All modules communicate through Core’s REST + WebSocket APIs, enabling unified visibility and waste reduction across manufacturing operations.
**TallyFlow Print** is a Flutter + Rust application that generates Zebra ZPL-compatible labels and RFID encodings, with optional auto-registration into Core.
**IoT** is a Rust-based service (tallyflow-iot) that ingests data from fixed RFID readers (Impinj, Zebra) and environmental sensors, pushing real-time tag events and sensor data to Core.
This structure was verified by inspecting the repositories in `~/src/` (tallyflow-web, photomicroservice, tallyflow-iot, tallyflow_mobile, tallyflow-print, etc.).
## Key Data Flows
- **Assets (Mobile) ↔ Core**: Sync inventory updates, enrollment, and seek/find data
- **Capture ↔ Core**: Photo + barcode metadata and QC records
- **Print → Core**: Print job submission + optional auto-registration
- **IoT → Core**: Real-time tag events and sensor data
- **Core ↔ MongoDB**: Persistent storage of all asset, tag, photo, and event data
- **Excel → Core**: Bulk asset and tag ingestion
- **Assets (Mobile) ↔ Core**: Enrollment, inventory updates, seek/find sync via API
- **Capture → Core**: Photo metadata and QC records
- **Print → Core**: Print jobs and optional asset registration
- **IoT → Core**: Real-time tag/sensor events
- **Core ↔ MongoDB**: Core owns and directly manages all persistent data (assets, photos, zones, history)
- **Core Web UI (Vue.js)**: Operator interface for the full system
This architecture allows flexible deployment — from mobile-only inventory tracking to full IoT + automated capture environments — while keeping Core as the single source of truth.
Core is the only component that directly owns the database. All other modules are clients or data producers that route through Core.