๐ง Rust Logic Graph
A high-performance reasoning graph framework for Rust with GRL (Grule Rule Language) support. Build complex workflows with conditional execution, topological ordering, and async processing.
โจ Key Features
- ๐ฅ GRL Support - rust-rule-engine v0.14.0 with RETE-UL algorithm (2-24x faster)
- ๐ Topological Execution - Automatic DAG-based node ordering
- โก Async Runtime - Built on Tokio for high concurrency
- โก Parallel Execution - Automatic parallel execution of independent nodes (v0.5.0)
- ๐พ Caching Layer - High-performance result caching with TTL, eviction policies, and memory limits (v0.5.0)
- ๐ง Memory Optimization - Context pooling and allocation tracking (v0.7.0)
- ๐ ๏ธ CLI Developer Tools - Graph validation, dry-run, profiling, and visualization (v0.5.0)
- ๐จ Web Graph Editor - Next.js visual editor with drag-and-drop interface (v0.8.0)
- ๏ฟฝ YAML Configuration - Declarative graph definitions with external config files (v0.8.5)
- ๏ฟฝ๐ Multiple Node Types - RuleNode, DBNode, AINode
- ๐ JSON/YAML Configuration - Simple workflow definitions
- ๐ฏ 98% Drools Compatible - Easy migration from Java
- ๐ Streaming Processing - Stream-based execution with backpressure (v0.3.0)
- ๐๏ธ Database Integrations - PostgreSQL, MySQL, Redis, MongoDB (v0.2.0)
- ๐ค AI/LLM Integrations - OpenAI, Claude, Ollama (v0.2.0)
๐ Quick Start
Installation
[]
= "0.8.5"
# With specific integrations
= { = "0.8.5", = ["postgres", "openai"] }
# With all integrations
= { = "0.8.5", = ["all-integrations"] }
Simple Example
use ;
let grl = r#"
rule "Discount" {
when
cart_total > 100 && is_member == true
then
discount = 0.15;
}
"#;
let mut engine = new;
engine.add_grl_rule?;
๐ข Real-World Case Study: Purchasing Flow System
See a complete production implementation in case_study/ - A full-featured purchasing automation system built with Rust Logic Graph.
๐ System Overview
Problem: Automate purchasing decisions for inventory replenishment across multiple products, warehouses, and suppliers.
Solution: Business rules in GRL decide when/how much to order. Orchestrator executes the workflows.
๐ฏ Two Architecture Implementations
1. Microservices (v4.0) - 7 services with gRPC
- Orchestrator (port 8080) - Workflow coordination
- OMS Service (port 50051) - Order management data
- Inventory Service (port 50052) - Stock levels
- Supplier Service (port 50053) - Supplier information
- UOM Service (port 50054) - Unit conversions
- Rule Engine (port 50055) - GRL business rules
- PO Service (port 50056) - Purchase order management
2. Monolithic (Clean Architecture) - Single HTTP service with dynamic configuration
- Same business logic as microservices (shared GRL rules)
- Single process on port 8080
- Multi-database architecture - 4 separate PostgreSQL databases (oms_db, inventory_db, supplier_db, uom_db)
- YAML-driven workflow - Graph structure defined in
purchasing_flow_graph.yaml - Dynamic field mapping - Config-driven data extraction from context
- Zero hardcoded fields - All field names configurable via YAML
- Direct in-process execution (no network calls)
๐ฅ GRL Business Rules (15 Rules)
rule "CalculateShortage" salience 120 no-loop {
when
required_qty > 0
then
Log("Calculating shortage...");
shortage = required_qty - available_qty;
Log("Shortage calculated");
}
rule "OrderMOQWhenShortageIsLess" salience 110 no-loop {
when
shortage > 0 && shortage < moq && is_active == true
then
Log("Shortage less than MOQ, ordering MOQ");
order_qty = moq;
}
See full rules: purchasing_rules.grl
YAML Configuration (NEW in v0.8.5)
Both Monolithic and Microservices implementations support YAML-based graph configuration:
Monolithic YAML Example (purchasing_flow_graph.yaml):
nodes:
oms_history:
type: DBNode
database: "oms_db" # Multi-database routing
query: "SELECT product_id, avg_daily_demand::float8, trend FROM oms_history WHERE product_id = $1"
inventory_levels:
type: DBNode
database: "inventory_db"
query: "SELECT product_id, available_qty::float8, reserved_qty::float8 FROM inventory WHERE product_id = $1"
rule_engine:
type: RuleNode
description: "Evaluate business rules with dynamic field mapping"
dependencies:
- oms_history
- inventory_levels
- supplier_info
- uom_conversion
field_mappings: # Dynamic field extraction (NEW)
avg_daily_demand: "oms_history.avg_daily_demand"
available_qty: "inventory_levels.available_qty"
lead_time: "supplier_info.lead_time"
moq: "supplier_info.moq"
create_po:
type: RuleNode
dependencies:
- rule_engine
field_mappings:
should_order: "rule_engine.should_order"
recommended_qty: "rule_engine.recommended_qty"
product_id: "supplier_info.product_id"
edges:
- from: oms_history
to: rule_engine
- from: inventory_levels
to: rule_engine
- from: rule_engine
to: create_po
Microservices YAML Example (purchasing_flow_graph.yaml):
nodes:
oms_grpc:
type: DBNode
description: "Fetch order management data via gRPC"
inventory_grpc:
type: DBNode
description: "Fetch inventory levels via gRPC"
rule_engine_grpc:
type: RuleNode
description: "Evaluate business rules"
dependencies:
- oms_grpc
- inventory_grpc
edges:
- from: oms_grpc
to: rule_engine_grpc
- from: inventory_grpc
to: rule_engine_grpc
Benefits:
- โ 70% less code - Graph definition moves from Rust to YAML
- โ No recompile - Change workflows without rebuilding
- โ Dynamic field mapping - Zero hardcoded field names in Rust code
- โ Multi-database routing - Each node specifies its database
- โ Multiple workflows - Easy variants (urgent, standard, approval)
- โ Better readability - Clear, declarative graph structure
- โ Easy testing - Test with different configurations
Usage:
// Monolithic - Default config with multi-database
executor.execute.await?;
// Monolithic - Custom workflow
executor.execute_with_config.await?;
// Microservices - Default config with gRPC nodes
orchestrator.execute.await?;
Key Architecture Differences:
| Feature | Monolithic | Microservices |
|---|---|---|
| Database Access | Direct SQL queries to 4 DBs | gRPC calls to services |
| Field Mapping | YAML field_mappings config |
Hardcoded in gRPC nodes |
| Rule Engine | In-process RuleEngine call | gRPC to rule-engine-service |
| Communication | Function calls | gRPC (network) |
| Graph Executor | PurchasingGraphExecutor |
OrchestratorExecutor |
| Node Types | DynamicDBNode, DynamicRuleNode |
OmsGrpcNode, RuleEngineGrpcNode |
Documentation: See YAML_CONFIGURATION_SUMMARY.md
Microservices Communication Flow
After v0.8.0 refactor, the Orchestrator now uses rust-logic-graph's Graph/Executor pattern to coordinate microservices:
- The Orchestrator receives a purchasing request (HTTP) and creates a Graph with 6 custom gRPC Nodes.
- Each Node wraps a gRPC call to a service:
OmsGrpcNode,InventoryGrpcNode,SupplierGrpcNode,UomGrpcNode,RuleEngineGrpcNode,PoGrpcNode. - The Executor runs the graph in topological order:
- Data Collection Phase (parallel): OMS, Inventory, Supplier, UOM nodes execute simultaneously via gRPC
- Rule Evaluation Phase: RuleEngineGrpcNode waits for all data, then evaluates GRL rules
- Execution Phase: PoGrpcNode creates/sends PO based on rule decisions
- All business logic (decision flags, calculations) comes from GRL rules. The Orchestrator is a pure executor.
Graph Topology:
OMS Node โโโโโ
โ
Inventory โโโโผโโโ RuleEngine Node โโโ PO Node
โ
Supplier โโโโโค
โ
UOM Node โโโโโ
Benefits of Graph/Executor Pattern:
- โ Declarative: Define workflow as nodes + edges instead of imperative code
- โ Parallel Execution: Data nodes run concurrently automatically
- โ Type Safety: Custom Node implementations with Rust's type system
- โ Testable: Each node can be tested in isolation
- โ Consistent: Same pattern used in monolithic and microservices
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
โ CLIENT (HTTP REST) โ
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฌโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
โ POST /purchasing/flow
โผ
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
โ Orchestrator Service (Port 8080) โ
โ โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ โ
โ โ rust-logic-graph Graph Executor โ โ
โ โ โ โ
โ โ Creates Graph with 6 gRPC Nodes: โ โ
โ โ โข OmsGrpcNode โ gRPC to OMS :50051 โ โ
โ โ โข InventoryGrpcNode โ gRPC to Inventory :50052 โ โ
โ โ โข SupplierGrpcNode โ gRPC to Supplier :50053 โ โ
โ โ โข UomGrpcNode โ gRPC to UOM :50054 โ โ
โ โ โข RuleEngineGrpcNode โ gRPC to Rules :50055 โ โ
โ โ โข PoGrpcNode โ gRPC to PO :50056 โ โ
โ โ โ โ
โ โ Graph Topology: โ โ
โ โ OMS โโโโโโโโ โ โ
โ โ Inventory โโผโโ RuleEngine โโโ PO โ โ
โ โ Supplier โโโค โ โ
โ โ UOM โโโโโโโโ โ โ
โ โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ โ
โโโโโโโโโโฌโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
โ
โโโโโโโโโโโโโโโผโโโโโโโโโโโโโโโโโโโฌโโโโโโโโโโโโโโโโโฌโโโโโโโโโโโโโโโ
โ (Parallel) โ (Parallel) โ (Parallel) โ (Parallel) โ
โผ โผ โผ โผ โ
โโโโโโโโโโโโ โโโโโโโโโโโโโโ โโโโโโโโโโโโโโโ โโโโโโโโโโโโโ โ
โOMS :50051โ โInventory โ โSupplier โ โUOM :50054 โ โ
โ โ โ:50052 โ โ:50053 โ โ โ โ
โโข History โ โโข Levels โ โโข Pricing โ โโข Convert โ โ
โโข Demand โ โโข Available โ โโข Lead Time โ โโข Factors โ โ
โโโโโโฌโโโโโโ โโโโโโโฌโโโโโโโ โโโโโโโโฌโโโโโโโ โโโโโโโฌโโโโโโ โ
โ โ โ โ โ
โโโโโโโโโโโโโโโโดโโโโโโโโโโโโโโโโโดโโโโโโโโโโโโโโโโ โ
โ โ
โ Data stored in Graph Context โ
โผ โ
โโโโโโโโโโโโโโโโโโโ โ
โ Rule Engine โ (Port 50055 - gRPC) โ
โ :50055 โ โ
โ โ โ
โ โข GRL Rules โ โข Evaluates 15 rules โ
โ โข Calculations โ โข Returns decision flags โ
โ โข Decision Flagsโ โข NO side effects โ
โโโโโโโโโโฌโโโโโโโโโ โ
โ โ
โ Flags stored in Graph Context โ
โผ โ
โโโโโโโโโโโโโโโโโโโ โ
โ PO Service โ (Port 50056 - gRPC) โ
โ :50056 โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
โ โ
โ โข Create PO โ โข Reads flags from context
โ โข Send to โ โข Executes based on rules
โ Supplier โ โข Email/API delivery
โโโโโโโโโโโโโโโโโโโ
Note: The Rule Engine service returns decision flags and calculations to the Graph Context. The PoGrpcNode then reads these flags from the context to determine whether to create/send the PO.
Where rust-logic-graph is Used
Monolithic App (case_study/monolithic/):
- Uses
Graph,Executor, and customNodeimplementations - Multi-database architecture: 4 separate PostgreSQL databases (oms_db, inventory_db, supplier_db, uom_db)
- Dynamic field mapping: YAML-configured field extraction with zero hardcoded field names
- Config-driven nodes:
DynamicDBNodeandDynamicRuleNoderead behavior from YAML - Database routing via
databasefield in YAML (e.g.,database: "oms_db") - Field mappings via
field_mappingsin YAML (e.g.,avg_daily_demand: "oms_history.avg_daily_demand") RuleEngineServiceacceptsHashMap<String, Value>for complete flexibility- Graph structure defined in
purchasing_flow_graph.yaml - Single process, no network calls
Orchestrator Microservice (case_study/microservices/services/orchestrator-service/):
- Uses
Graph,Executor, and custom gRPCNodeimplementations - 6 gRPC nodes make network calls to remote services
- Same graph topology as monolithic
- Distributed across multiple processes
Rule Engine Service (case_study/microservices/services/rule-engine-service/):
- Uses
RuleEnginefor GRL evaluation - Exposed via gRPC endpoint
- Stateless service (no graph execution)
Other Microservices (OMS, Inventory, Supplier, UOM, PO):
- Standard gRPC services with database access
- Do NOT use rust-logic-graph directly
- Called by Orchestrator's Graph Executor
Architecture Highlights:
Monolithic Clean Architecture:
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
โ HTTP REST API (Port 8080) โ
โ POST /purchasing/flow {product_id} โ
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฌโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
โ
โผ
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
โ PurchasingGraphExecutor (Clean Architecture) โ
โ โ
โ โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ โ
โ โ rust-logic-graph Graph/Executor Engine โ โ
โ โ โ โ
โ โ 1. Load purchasing_flow_graph.yaml โ โ
โ โ 2. Parse nodes + edges + field_mappings โ โ
โ โ 3. Create DynamicDBNode per database config โ โ
โ โ 4. Create DynamicRuleNode with field mappings โ โ
โ โ 5. Execute graph in topological order โ โ
โ โ โ โ
โ โ Graph Topology: โ โ
โ โ oms_history โโโโโโโโโ โ โ
โ โ inventory_levels โโโโผโโโ rule_engine โโโ create_po โ โ
โ โ supplier_info โโโโโโโค โ โ
โ โ uom_conversion โโโโโโ โ โ
โ โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ โ
โโโโโโโโโโโโโโโโฌโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
โ
โโโโโโโโโโโโโโโโโโโโผโโโโโโโโโโโโโโโโโโโฌโโโโโโโโโโโโโโโโโโโฌโโโโโโโโโโโ
โ (Parallel DBs) โ (Parallel DBs) โ (Parallel DBs) โ (Parallel)
โผ โผ โผ โผ โ
โโโโโโโโโโโโโโโโ โโโโโโโโโโโโโโโโ โโโโโโโโโโโโโโโโ โโโโโโโโโโโโโโโโ โ
โ oms_db โ โ inventory_db โ โ supplier_db โ โ uom_db โ โ
โ PostgreSQL โ โ PostgreSQL โ โ PostgreSQL โ โ PostgreSQL โ โ
โ โ โ โ โ โ โ โ โ
โ โข history โ โ โข levels โ โ โข info โ โ โข conversion โ โ
โ โข demand โ โ โข available โ โ โข pricing โ โ โข factors โ โ
โ โข trends โ โ โข reserved โ โ โข lead_time โ โ โ โ
โโโโโโโโฌโโโโโโโโ โโโโโโโโฌโโโโโโโโ โโโโโโโโฌโโโโโโโโ โโโโโโโโฌโโโโโโโโ โ
โ โ โ โ โ
โ Query with โ Query with โ Query with โ Query โ
โ database:"oms" โ database:"inv" โ database:"sup" โ with DB โ
โโโโโโโโโโโโโโโโโโโดโโโโโโโโโโโโโโโโโโดโโโโโโโโโโโโโโโโโโดโโโโโโโโโโ
โ
Data stored in Graph Context
with path notation (e.g., "oms_history.avg_daily_demand")
โ
โผ
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
โ DynamicRuleNode (rule_engine) โ
โ โ
โ YAML field_mappings config: โ
โ โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ โ
โ โ avg_daily_demand: โ โ
โ โ "oms_history.avg_daily_demand" โ โ
โ โ available_qty: โ โ
โ โ "inventory_levels.available_qty" โ โ
โ โ lead_time: โ โ
โ โ "supplier_info.lead_time" โ โ
โ โ ... (9 total mappings) โ โ
โ โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ โ
โ โ
โ extract_rule_inputs() loop: โ
โ โข Reads field_mappings from YAML โ
โ โข Uses get_value_by_path() for parsing โ
โ โข Returns HashMap<String, Value> โ
โ โข ZERO hardcoded field names! โ
โโโโโโโโโโโโโโโโฌโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
โ
โผ
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
โ RuleEngineService (In-Process) โ
โ โ
โ evaluate(HashMap<String, Value>) โ
โ โ
โ โข Loads purchasing_rules.grl โ
โ โข 15 business rules (GRL) โ
โ โข Accepts dynamic HashMap input โ
โ โข No struct, no hardcoded fields โ
โ โข Pure functional evaluation โ
โ โ
โ Rules calculate: โ
โ โ shortage = required_qty - available โ
โ โ order_qty (respects MOQ) โ
โ โ total_amount with discounts โ
โ โ requires_approval flag โ
โ โ should_create_po flag โ
โโโโโโโโโโโโโโโโฌโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
โ
Decision flags returned to Context
โ
โผ
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
โ DynamicRuleNode (create_po) โ
โ โ
โ YAML field_mappings config: โ
โ โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ โ
โ โ should_order: โ โ
โ โ "rule_engine.should_order" โ โ
โ โ recommended_qty: โ โ
โ โ "rule_engine.recommended_qty" โ โ
โ โ product_id: โ โ
โ โ "supplier_info.product_id" โ โ
โ โ ... (6 total mappings) โ โ
โ โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ โ
โ โ
โ โข Reads rule_engine output from context โ
โ โข Dynamic field extraction via YAML โ
โ โข Creates PO if should_order == true โ
โ โข Returns PO JSON or null โ
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
Key Design Principles:
-
Multi-Database Routing - Each node specifies its database in YAML:
oms_history: database: "oms_db" # Routes to oms_db pool -
Dynamic Field Mapping - Zero hardcoded fields in Rust code:
field_mappings: avg_daily_demand: "oms_history.avg_daily_demand"// Code is 100% generic for in &self.field_mappings -
Config-Driven Execution - Graph structure in YAML, not Rust:
executor.execute_with_config?; -
HashMap-Based RuleEngine - Accepts any fields:
Microservices Communication Flow
- Multi-Database Routing (
graph_executor.rs):
// YAML config specifies database per node
oms_history:
database: "oms_db"
query: "SELECT ..."
// Executor routes to correct pool
let pool = self.get_pool;
- Dynamic Field Mapping (
graph_executor.rs):
// YAML config defines field mappings
field_mappings:
avg_daily_demand: "oms_history.avg_daily_demand"
available_qty: "inventory_levels.available_qty"
// Code extracts dynamically (zero hardcoding)
- Config-Driven RuleEngine (
rule_service.rs):
// Accepts HashMap instead of struct - 100% flexible
Web Graph Editor (NEW in v0.8.0)
๐ Online Editor: https://logic-graph-editor.amalthea.cloud/
Try the visual graph editor online - no installation required! Create workflows, define rules, and visualize your logic graphs with drag-and-drop.
CLI Tools (v0.5.0)
# Build the CLI tool
# Validate a graph
# Visualize graph structure
# Profile performance
# Dry-run without execution
Run Examples
# Basic workflow
# GRL rules
# Advanced integration
๐ Documentation
| Document | Description |
|---|---|
| ๐ข Case Study: Purchasing Flow | Real production system with microservices & monolithic implementations |
| ๐ YAML Configuration Guide | Declarative graph configuration with YAML (NEW in v0.8.5) |
| Graph Editor Guide | Visual web-based graph editor with Next.js (NEW in v0.8.0) |
| Memory Optimization Guide | Context pooling and allocation tracking (v0.7.0) |
| CLI Tool Guide | Developer tools for validation, profiling, and visualization (v0.5.0) |
| Cache Guide | Caching layer with TTL and eviction policies (v0.5.0) |
| Migration Guide | Upgrade guide to v0.14.0 with RETE-UL (v0.5.0) |
| Integrations Guide | Database & AI integrations (v0.2.0) |
| GRL Guide | Complete GRL syntax and examples |
| Use Cases | 33+ real-world applications |
| Extending | Create custom nodes and integrations |
| Implementation | Technical details |
๐ฏ Use Cases
Rust Logic Graph powers applications in:
- ๐ฐ Finance - Loan approval, fraud detection, risk assessment
- ๐ E-commerce - Dynamic pricing, recommendations, fulfillment
- ๐ฅ Healthcare - Patient triage, clinical decisions, monitoring
- ๐ญ Manufacturing - Predictive maintenance, QC automation
- ๐ก๏ธ Insurance - Claims processing, underwriting
- ๐ Marketing - Lead scoring, campaign optimization
- โ๏ธ Compliance - AML monitoring, GDPR automation
๐๏ธ Architecture

๐ฅ GRL Example
rule "HighValueLoan" salience 100 {
when
loan_amount > 100000 &&
credit_score < 750
then
requires_manual_review = true;
approval_tier = "senior";
}
rule "AutoApproval" salience 50 {
when
credit_score >= 700 &&
income >= loan_amount * 3 &&
debt_ratio < 0.4
then
auto_approve = true;
interest_rate = 3.5;
}
๐ Performance
- RETE-UL Algorithm: Advanced pattern matching with unlinking (v0.14.0)
- 2-24x Faster: Than v0.10 at 50+ rules
- 98% Drools Compatible: Easy migration path
- Async by Default: High concurrency support
- Parallel Execution: Automatic layer-based parallelism
- Smart Caching: Result caching with TTL and eviction policies
๐งช Testing & CLI Tools
# Run all tests
# Build CLI tool
# Validate graph
# Visualize graph structure
# Profile performance
# Dry-run execution
Test Results: โ 32/32 tests passing
Learn more about CLI tools โ
๐ฆ Project Status
Version: 0.8.5 (Latest) Status: Production-ready with YAML configuration, web graph editor, and real-world case study
What's Working
- โ Core graph execution engine
- โ RETE-UL algorithm (v0.14.0) - 2-24x faster
- โ Three node types (Rule, DB, AI)
- โ Topological sorting
- โ Async execution
- โ JSON I/O
- โ Database integrations (PostgreSQL, MySQL, Redis, MongoDB)
- โ AI integrations (OpenAI, Claude, Ollama)
- โ Streaming processing with backpressure and chunking
- โ Parallel execution with automatic layer detection
- โ Caching layer with TTL, eviction policies, memory limits (v0.5.0)
- โ Memory optimization with context pooling (v0.7.0)
- โ CLI Developer Tools - validate, profile, visualize, dry-run (v0.5.0)
- โ Web Graph Editor - Next.js visual editor with drag-and-drop (v0.8.0)
- โ Production Case Study - Purchasing flow with microservices & monolithic (v0.8.0)
- โ YAML Configuration - Declarative graph definitions (v0.8.5)
- โ Stream operators (map, filter, fold)
- โ Comprehensive documentation
Roadmap
- Streaming processing (v0.3.0) - COMPLETED โ
- Parallel node execution (v0.4.0) - COMPLETED โ
- Caching layer (v0.5.0) - COMPLETED โ
- CLI Developer Tools (v0.5.0) - COMPLETED โ
- RETE-UL upgrade (v0.5.0) - COMPLETED โ
- Memory Optimization (v0.7.0) - COMPLETED โ
- Web Graph Editor (v0.8.0) - COMPLETED โ
- Production Case Study (v0.8.0) - COMPLETED โ
- YAML Configuration (v0.8.5) - COMPLETED โ
- GraphQL API (v0.9.0)
- Production release (v1.0.0)
See ROADMAP.md for details
๐ค Contributing
Contributions welcome! Please:
- Fork the repository
- Create your feature branch
- Write tests for new features
- Submit a pull request
๐ Examples
| Example | Description | Lines |
|---|---|---|
simple_flow.rs |
Basic 3-node pipeline | 36 |
advanced_flow.rs |
Complex 6-node workflow | 120 |
grl_rules.rs |
GRL rule examples | 110 |
grl_graph_flow.rs |
GRL + Graph integration | 140 |
postgres_flow.rs |
PostgreSQL integration | 100 |
openai_flow.rs |
OpenAI GPT integration | 150 |
streaming_flow.rs |
Streaming with backpressure | 200 |
parallel_execution.rs |
Parallel node execution | 250 |
CLI Tool Examples (v0.5.0)
| File | Description |
|---|---|
examples/sample_graph.json |
Linear workflow with 5 nodes |
examples/cyclic_graph.json |
Graph with cycle for testing |
examples/sample_context.json |
Sample input data |
See CLI_TOOL.md for usage examples
๐ Why Rust Logic Graph?
vs. Traditional Rule Engines
- โ Async by default - No blocking I/O
- โ Type safety - Rust's type system
- โ Modern syntax - GRL support
- โ Graph-based - Complex workflows
vs. Workflow Engines
- โ Embedded - No external services
- โ Fast - Compiled Rust code
- โ Flexible - Custom nodes
- โ Rule-based - Business logic in rules
๐ Changelog
v0.8.5 (2025-11-20) - YAML Configuration Release
New Features:
- ๐ YAML Configuration Support - Declarative graph definitions
- Load graph structure from YAML files instead of hardcoded
GraphConfigmodule for parsing YAML configurations- Support for both JSON and YAML formats
- 70% code reduction in graph executors
- See YAML Configuration Guide
- ๐ง Enhanced Graph Executor API
execute()- Use default configurationexecute_with_config(config_path)- Load custom YAML config- Dynamic node registration from config
- ๐ Multiple Workflow Support
- Standard flow (full process)
- Simplified flow (skip optional steps)
- Urgent flow (fast-track)
- Easy to create custom workflows
- ๐๏ธ Monolithic Clean Architecture (NEW)
- Multi-database architecture with 4 PostgreSQL databases
- Dynamic field mapping via YAML configuration
- Zero hardcoded field names in code
- Database routing per node via config
field_mappingsfor flexible data extractionRuleEngineServiceacceptsHashMap<String, Value>- Config-driven
DynamicDBNodeandDynamicRuleNode
- ๐ Comprehensive Documentation
- YAML configuration guide with examples
- Before/After comparison showing improvements
- Multiple workflow examples
- Integration guides for both architectures
- Clean architecture patterns documentation
Improvements:
- Monolithic and Microservices both support YAML configs
- Reduced boilerplate code by 70% in executors
- Better separation of concerns (config vs. code)
- Easier testing with multiple configurations
- No recompilation needed for workflow changes
- Complete flexibility in field naming and mapping
Examples:
# Monolithic with multi-database
nodes:
oms_history:
database: "oms_db"
query: "SELECT ..."
rule_engine:
field_mappings:
avg_daily_demand: "oms_history.avg_daily_demand"
// Dynamic field extraction (no hardcoding)
let inputs = self.extract_rule_inputs;
rule_service.evaluate?; // HashMap<String, Value>
Compatibility:
- All tests passing
- API backward compatible
- Existing hardcoded graphs still work
v0.8.0 (2025-11-20) - Web Editor & Production Case Study Release
New Features:
- ๐จ Web Graph Editor - Next.js visual editor with drag-and-drop
- Online version: https://logic-graph-editor.amalthea.cloud/
- React Flow-based graph visualization
- Real-time node editing and validation
- Export/import JSON workflows
- See Graph Editor Guide
- ๐ข Production Case Study - Complete purchasing flow system
- Microservices architecture (7 services with gRPC)
- Monolithic architecture (single HTTP service)
- 15 GRL business rules for purchasing decisions
- Kubernetes deployment manifests
- Docker Compose for local development
- Shared GRL rules proving portability
- See Case Study Documentation
Improvements:
- Updated README with case study section
- Added online graph editor link
- Comprehensive production examples
Compatibility:
- All tests passing
- API backward compatible
v0.5.0 (2025-11-06) - Performance & Developer Tools Release
Breaking Changes:
- โก Upgraded rust-rule-engine from v0.10 โ v0.14.0
- Now uses RETE-UL algorithm (2-24x faster)
- Better memory efficiency
- Improved conflict resolution
- See Migration Guide
New Features:
- ๐ ๏ธ CLI Developer Tools (
rlgbinary)- Graph validation with comprehensive checks
- Dry-run execution mode
- Performance profiling with statistics
- ASCII graph visualization
- See CLI Tool Guide
- ๐พ Caching Layer - High-performance result caching
- TTL-based expiration
- Multiple eviction policies (LRU, LFU, FIFO)
- Memory limits and statistics
- See Cache Guide
- โก Parallel Node Execution - Automatic detection and parallel execution
- Layer detection algorithm using topological sort
- Concurrent execution within layers
- Parallelism analysis and statistics
- ๐ ParallelExecutor - New executor with parallel capabilities
- ๐ New Examples - CLI examples and test graphs
- โ 32 Tests - Comprehensive test coverage
Improvements:
- Updated documentation with CLI tools, caching, and migration guides
- Performance benchmarking utilities
- Example graph files for testing
Compatibility:
- All 32 tests passing
- API is backward compatible (100%)
- Performance: 2-24x faster rule matching
v0.3.0 (2025-11-03) - Streaming & Performance Release
New Features:
- ๐ Streaming Processing - Stream-based node execution
- Backpressure handling with bounded channels
- Large dataset support with chunking
- Stream operators (map, filter, fold, async map)
- ๐ New Example -
streaming_flow.rswith 6 demonstrations - โ 8 New Tests - Streaming module testing
Performance:
- Processed 10,000 items in chunks
- ~432 items/sec throughput with backpressure
v0.2.0 (2025-11-02) - Integrations Release
New Features:
- ๐๏ธ Database Integrations - PostgreSQL, MySQL, Redis, MongoDB
- ๐ค AI/LLM Integrations - OpenAI GPT-4, Claude 3.5, Ollama
- ๐ Integration Examples -
postgres_flow.rs,openai_flow.rs - ๐ INTEGRATIONS.md - Comprehensive integration guide
- ๐๏ธ Feature Flags - Optional dependencies for integrations
v0.1.0 (2025-11-01) - Initial Release
Core Features:
- ๐ง Core graph execution engine
- ๐ฅ GRL (Grule Rule Language) integration
- ๐ Topological sorting
- โก Async execution with Tokio
- ๐ Three node types (Rule, DB, AI)
- ๐ JSON I/O for graphs
- ๐ 4 working examples
- โ 6/6 tests passing
๐ License
MIT License - see LICENSE for details.
๐ Links
- Repository: https://github.com/KSD-CO/rust-logic-graph
- rust-rule-engine: https://crates.io/crates/rust-rule-engine
- Documentation: docs/
- Issues: GitHub Issues
๐ฅ Authors
James Vu - Initial work
๐ Acknowledgments
Built with:
- rust-rule-engine v0.14.0 - GRL support with RETE-UL
- Tokio - Async runtime
- Petgraph - Graph algorithms
- Serde - Serialization
- Clap - CLI framework
โญ Star us on GitHub if you find this useful! โญ
Documentation โข Examples โข Use Cases โข YAML Config Guide