Skip to content

🖥️ Graphical User Interface (GUI) & Control Layout

📌 Project Overview

This folder contains the front-end control systems and operational management consoles for the project infrastructure. The primary service utility leverages the Streamlit Web Framework to expose a centralized maintenance portal, enabling real-time infrastructure auditing, process health verification, and dynamic background process control without requiring direct command-line access.

🏗️ Architecture Role & Port Mapping

In the multi-tier platform layout, this dashboard acts as the orchestration panel for system engineers: * Microservice Lifecycle Manager: Spawns and kills the core ingestion infrastructure programmatically using detached system processes. * Telemetry Monitor: Establishes lightweight socket probes to query internal state layers and pull system queue diagnostics. * Cross-Platform Boundary Handler: Automatically changes execution behaviors between Windows command tables (netstat, taskkill) and Unix utilities (lsof, kill) based on the active host operating system.

🧬 Functional Subsystems & UI Core

1. Process Lifecycle Controller (manage_process)

The orchestration panel starts background services via detached execution states to ensure the core network remains isolated and self-sustaining: * Windows Architecture Boundary: Executes detached pipelines with strict creation constraints (subprocess.CREATE_NEW_PROCESS_GROUP | subprocess.DETACHED_PROCESS), preserving backend server integrity if the Streamlit app is stopped. * Port-Clearing Routine: To prevent port collision faults (Address already in use), the stop sequence identifies and eliminates any lingering processes locked to port 7000 by stripping active process IDs (PIDs).

2. Live Telemetry Pipeline (get_rs_stats)

The app utilizes socket connections to probe the active backend infrastructure using internal administrative protocols: * Sends a standard query signature ({"task_type": "4"}) to request live resource states. * Parses the returned bytes into high-visibility graphical display modules.

🛠️ Visual Metrics Dashboard Reference

When the infrastructure status reads 🟢 ONLINE, the user interface unlocks a 5-column performance evaluation layout:

Display Metric Card Source Mapping Property Functional Tracking Context
Fast Queue (201-300) qi_fast_count Monitors real-time, synchronous client queries waiting for immediate worker execution.
Slow Queue (301-400) qi_slow_count Tracks asynchronous, long-running workflows (e.g., batch processing, analytics).
Live Threads active_events Displays the current number of active thread execution locks in the engine.
Pending Results qo_count Tracks output payloads awaiting collection or routing to local storage.
Task ID Floor last_tid The high-water mark tracking index showing the total number of processed requests.

🚀 Operational Deployment

1. Pre-Execution Verification

Ensure your environment has the required interface frameworks and networking wrappers installed:

pip install streamlit

2. Dashboard Startup

Run the Streamlit web runtime container from the root directory to view the web console layout:

streamlit run gui/tm_gui2.py

(Note: If you followed the clean professional folder naming layout, replace tm_gui2.py with tm_gui.py)

🔄 Auto-Refresh Behavior

When active, the client console implements an automated, self-correcting 3-second cycle interval layout. The dashboard sleeps for 3 seconds before issuing an internal refresh instruction (st.rerun()), keeping the console aligned with backend changes.

🚀 Client Ingestion Terminal (client_view.py)

📌 Subsystem Overview

The Client Terminal provides a user-facing interactive portal built on the Streamlit web layout framework. It serves as an ingestion simulation client that validates, transforms, and dispatches custom operational request payloads (ingredients) over secure TCP sockets (localhost:7000) directly into the active platform routing layers.

🏗️ Architecture Design & State Isolation

The terminal acts as a decoupled traffic generator designed around the core system constraints: * Variable Payload Extraction: Wraps user parameter lists cleanly inside an isolated configuration schema context, standardizing parameters before they cross the wire. * Dynamic Blocking Strategy: Implements smart socket timeout limits. For short-lived operations, it blocks waiting for completion. For long-running batch requests, it handles the connection asynchronously to prevent application freezes. * User Priority Impersonation: Features structural priority overrides, allowing users to toggle between Normal (0), Premium (1), and absolute Developer/Admin (2) processing channels.

🧬 Network Pipeline & Range Routing Matrix

Every button interaction triggers a target routing strategy configured to match explicit architectural tiers:

1. Fast Pathway Simulators (Task Ranges 201-300)

  • Action Point: Run Quick Calc (Type 201)
  • Payload Profile: Dispatches a standard corporate data signature containing initialization keys (company_name, annual_revenue).
  • Execution Flow: Holds socket resources open synchronously. If the Task Manager finishes execution within 15 seconds, the interface prints a completion status and pops up a success layout containing the raw result array.

2. Slow Pathway Simulators (Task Ranges 301-400)

  • Action Point: Bulk Email (Type 301)
  • Payload Profile: Packages long-running automation instructions (e.g., target counts, execution templates).
  • Execution Flow: Dispatches asynchronously. Instantly parses the incoming acknowledgement tracking ID returned by the queue broker without blocking UI workflows.

3. Administrative Operational Hooks (Task Ranges 101-200)

  • Action Point: DB Update (Type 101)
  • Payload Profile: Triggers deep backend storage maintenance requests (e.g., {"db_action": "reindex"}).
  • Execution Flow: Automatically forces a high-priority Developer rank (priority="2"), causing the RS Layer to route the task to index zero (0) of the slow background tracking array.

💾 Decentralized Storage Recovery Pipeline

To handle transient network errors or premature user disconnects, the terminal features a state recovery mechanism: * Sync Routine (Task Type 6): Fires an administrative data collection probe across the platform network. * Nested Mapping Scan: Parses the database recovery arrays (history), loops through the outer response frames, isolates internal system profiles (payload.result.data), and highlights historical results inside the active window.

🚀 Terminal Execution

1. Verification Constraints

Ensure your local Python profile contains the required web rendering core dependencies:

pip install streamlit

2. Terminal Launch Command

Run the system terminal from your main directory workspace:

streamlit run gui/Client3.py

(Note: If you applied our clean naming conventions, target streamlit run gui/client.py instead)

🔄 Multi-Station Flow Monitor (orchestrator_view.py)

📌 Subsystem Overview

The Multi-Station Flow Monitor provides a high-visibility, dual-lane operations dashboard built on Streamlit. By transforming file logs (task_manager.log) into a structured state map, it allows engineers to audit the active workloads of processing engines, trace client interactions, and monitor backend performance intervals without introducing heavy socket querying overhead.

🏗️ Architecture Design & State Recovery

The monitor is structured as a decoupled analytical pipeline built around the following criteria: * Non-Blocking Log Reading: Opens files with explicit errors="ignore" flag sets to prevent runtime script conflicts if an orchestrator instance writes records simultaneously. * Regex-Driven State Processing: Uses deterministic regular expressions to reconstruct distributed process states, tracking tasks from active ingestion down to final submission confirmations. * Dual-Lane Isolation Layout: Segregates metrics into separate display boards to track the Fast Lane and Slow/Dev Lane without cross-contaminating status data.

🧬 Diagnostic Display Infrastructure

1. High-Speed Processing Card (Station 1: Fast Lane)

  • Triggers When: The parser identifies active patterns under [TM-STATION-1].
  • Visual States: Highlights an active tracking card alongside a 60% progress baseline indicator bar. Displays complete confirmation notifications once the network push validation token is detected.

2. Batch-Automation Processing Card (Station 2: Slow Lane)

  • Triggers When: The parser identifies active patterns under [TM-STATION-2].
  • Visual States: Renders an alert panel coupled with a 30% progress metric tracking bar to signal heavy background file alterations or bulk data insertions.

3. Integrated Activity Log Viewport

  • Operation: Performs continuous trailing operations ([-15:]) directly on the base system logger files.
  • Objective: Exposes raw diagnostic logs in an embedded dashboard console, giving engineers instant access to error stack traces or tracking parameters.

🚀 Deployment Operations

1. Dependency Invariants

Ensure your local Python profile contains the required web rendering components:

pip install streamlit

2. Execution Invocation

Launch the monitoring terminal from your master directory location:

streamlit run gui/tm_gui2.py

(Note: If you applied our clean naming conventions, run streamlit run gui/tm_gui.py instead)

⏳ High-Frequency UI Loop Refresh

The frontend application uses an aggressive 1-second auto-refresh cycle (time.sleep(1) followed by st.rerun()). This allows the user interface to respond rapidly to changing background states without causing terminal performance lag.

🖥️ Graphical User Interface (GUI) & Control Layout Portfolio

📌 Project Overview

The gui/ directory contains the graphical orchestration systems, user-facing terminals, and feature-benchmarking consoles for the application platform. Built completely on top of the high-performance Streamlit Web Framework, this unified suite translates distributed, backend socket layers into predictable, real-time interactive panels. This design allows users, developers, and operators to control microservice lifecycles, test structural capacity, and ingest payload rows through intuitive graphical interfaces.

🏗️ Architecture & Script Mapping Layout

The frontend layer is divided into three distinct execution contexts designed around standard user personas:

gui/
├── client_view.py          <-- User Ingestion Terminal (Simulates normal/premium requests)
├── orchestrator_view.py    <-- Flow Monitor (Traces engine logs and task lane states)
└── developer_console.py    <-- Dev Mission Control (Handles dynamic batch testing & benchmarking)

1. Ingestion Communication Invariants

All data interactions across these panels communicate with the core architecture using low-overhead TCP socket streams (localhost:7000) protected by explicit execution boundaries (s.settimeout()).

  • Flat Injection Schema Translation: Interface components dispatch a simplified flat JSON structure containing core input flags (task_type, user_id, priority, ingredients). The RS Layer catches these packets on the wire and automatically normalizes them into the master 3-Tier tracking object block (header, payload, meta).
  • Stream Buffer Buffering Protection: High-volume applications read incoming data inside sequential 4KB or 8KB chunk matrices (s.recv()), reassembling byte arrays securely before compiling data views. This pattern blocks memory drops or string clipping bugs when loading nested JSON logs.

🧬 Subsystem Functional Reference Matrix

Module A: Dev Mission Control (developer_console.py)

Provides system administrators with an advanced control center to run high-throughput stress tests and review background queue metrics.

  • Dynamic Data Micro-Batching: Used to inject immense data pools for performance evaluations. The script generates corporate data mockups, sends metadata blocks, and fragments staff arrays into configurable chunks (e.g., 250 rows per task payload). It marks each chunk with forced developer ranking (priority: "2"), streaming them sequentially into the database.
  • Isolated Fragment Polling (st.fragment): Captures metrics via low-overhead background polling loops that query history markers every 30 seconds. This refreshes data views locally without triggering full application window reloads.
  • Analytical Math Computations: Maps execution records into active Pandas DataFrames, programmatically rendering structural telemetry averages covering the latest 20 background records.

Module B: Ingestion Terminal (client_view.py)

A user-facing portal allowing individuals or client engines to submit functional request payloads into target fast or slow processing channels.

  • Synchronous Fast Pathway Monitoring: For immediate requests (Task Type 201), it blocks connection resources synchronously for up to 15 seconds. If the Task Manager finishes execution inside that window, the terminal pops open a success notification highlighting the output.
  • Asynchronous Disconnect Strategy: For long-running batch items (Task Type 301), the terminal processes confirmations instantly and drops the network pipe immediately to avoid application freezes.
  • Offline State Recovery Hook: Implements an alternative manual data recovery trigger (Task Type 6). If a client drops offline during high-load intervals, this utility queries the storage persistence layer to pull down and restore missing results into the user view.

Module C: Multi-Station Flow Monitor (orchestrator_view.py)

A dashboard built for operations managers to view active data flows, trace processing station bottlenecks, and track background engine health.

  • Reactive Log Parsing: Scans system log records (task_manager.log) using non-blocking file handlers (errors="ignore"), decoupling monitoring workflows from active storage locks.
  • Regex Pattern Mapping: Employs deterministic regex patterns to construct dual-lane status maps (⚡ Station 1: Fast Lane and 🐢 Station 2: Slow Lane), tracking execution paths from raw worker intake down to final confirmations.
  • Activity Console Viewport: Slices and prints the final 15 lines of raw orchestrator tracking logs into a secure, readable terminal window at the bottom of the interface.

🛠️ Unified System Commands & Telemetry Reference

The GUI framework interacts with the background layers by emitting the following explicit administrative task_type instructions:

Command Token Operational Action Initiated Frontend Extraction Mapping
task_type: "4" Requests an infrastructure health check from the queue broker. Renders data grids covering qi_fast_count, qi_slow_count, active_events, and last_tid.
task_type: "5" Polls historical user transaction records from the append-only log files. Compiles metrics into tabular arrays containing task identifiers, execution deltas, and worker profiles.
task_type: "101" Triggers deep backend storage maintenance requests or bulk relational data insertions. Dispatches arrays mapping to BULK_INSERT_COMPANIES or BULK_INSERT_EMPLOYEES.
task_type: "201" Launches a synchronous high-speed execution loop. Extracts the data result object embedded at r["payload"]["result"]["data"].
task_type: "301" Pushes a long-running batch job request. Captures the raw queue registration code returned by the infrastructure layer.

🚀 Deployment Operations

1. Pre-Execution Requirements

Confirm your environment includes the required web rendering and analytics libraries:

pip install streamlit pandas

2. Launching Interfaces

To open any interface component, invoke the Streamlit app runner from your project root directory:

# Launch Dev Mission Control
streamlit run gui/developer_console.py

# Launch the Ingestion Terminal
streamlit run gui/client_view.py

# Launch the Multi-Station Flow Monitor
streamlit run gui/orchestrator_view.py