Add comprehensive architectural analysis documentation for AReaLite vs Core#5
Merged
zhshgmail merged 3 commits intoJul 30, 2025
Merged
Conversation
…s Core Co-authored-by: zhshgmail <126103537+zhshgmail@users.noreply.github.com>
Copilot
AI
changed the title
[WIP] 请帮忙分析下arealite与core的主要区别。可以从example下的sync例子入手,arealite在example下有独立的目录,而example下的其他文件则是core的入口。
请从软件架构的角度分析两者的区别
Add comprehensive architectural analysis documentation for AReaLite vs Core
Jul 30, 2025
zhshgmail
pushed a commit
that referenced
this pull request
Oct 29, 2025
This commit addresses design issues #1-#4 by reorganizing interfaces: ## Changes **1. Moved to api module (proper location for interfaces):** - `QueueAPI` → `areal/api/queue_api.py` - `CacheAPI` → `areal/api/cache_api.py` - `EventType`, `EventContext`, `EventHandler` → `areal/api/event_api.py` - `QueueFilter` → `Filter` in `areal/api/filter_api.py` **2. Created separate queue/cache event handler protocols:** - `QueueEventHandler` + `QueueEventContext` in `areal/api/queue_event_handler.py` - `CacheEventHandler` + `CacheEventContext` in `areal/api/cache_event_handler.py` **3. Simplified event_system.py:** - Now only contains `EventRegistry` class - Imports interfaces from api module - No longer defines protocols **4. Renamed QueueFilter → Filter:** - Generic name since it applies to both queue and cache - Located in api module as proper interface - StalenessFilter now implements Filter protocol ## Why Protocol as superclass? (Answer to #4) Protocol enables **structural subtyping** (duck typing with types): ```python from typing import Protocol class QueueAPI(Protocol): def put(self, item): ... # No need to inherit! class MyQueue: def put(self, item): pass # Type checker accepts this ✓ def foo(q: QueueAPI): q.put(1) foo(MyQueue()) # Works! Structural typing ``` vs ABC (requires inheritance): ```python from abc import ABC class QueueAPI(ABC): ... class MyQueue: # Must inherit from QueueAPI ... ``` **Protocol = Interface without inheritance requirement** ## Remaining Work Still TODO (per user feedback): - Redesign ProximalRecomputer with propagator pattern (#3) - Fix AsyncTaskRunner to require QueueAPI/CacheAPI (#5) - Remove executor._filter_context (#6) - Add CacheFilter or apply Filter to all operations (areal-project#7, areal-project#8) - Fix RemoteInfEngine to not expose queue/cache (areal-project#9) - Merge event_factory into workflow_factory (areal-project#10) - Add vLLM recompute support (areal-project#11) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
zhshgmail
pushed a commit
that referenced
this pull request
Oct 29, 2025
Addresses Issue #5 from user feedback: AsyncTaskRunner should not support both QueueAPI and plain queue.Queue. It should REQUIRE QueueAPI/CacheAPI. Changes: 1. Made output_queue and result_cache REQUIRED parameters (not optional) 2. Typed as QueueAPI and CacheAPI using TYPE_CHECKING 3. Removed default creation logic (no fallback to plain queue.Queue or list) 4. Updated event_factory to pass parameters in correct order 5. Added __future__ annotations for forward references This enforces the Spring @configuration pattern where the factory is responsible for creating and configuring queue/cache instances. AsyncTaskRunner no longer creates defaults - it MUST receive properly configured QueueAPI and CacheAPI implementations. Benefits: - Enforces proper factory pattern - No mixing of plain queue.Queue and QueueAPI - Clearer separation of concerns - Enables future distributed implementations 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR addresses the request to analyze the main differences between AReaLite and Core from a software architecture perspective, using the sync examples as a starting point.
Overview
Added a complete documentation set that provides in-depth architectural analysis of AReaL's two parallel systems:
/arealite/,/examples/arealite/) - Lightweight, AI researcher-friendly framework/realhf/,/training/) - Full-scale distributed system for production trainingKey Findings
The analysis reveals fundamental architectural differences:
Documentation Structure
📋
docs/architecture/README.mdNavigation index with quick access paths for different user types (AI researchers, industrial teams, system engineers).
📊
docs/architecture/final_summary_report.mdExecutive summary with strategic recommendations and clear selection criteria based on team capabilities and project scale.
🔧
docs/architecture/arealite_vs_core_analysis.mdDetailed technical comparison covering:
💻
docs/architecture/code_examples_comparison.mdReal code snippets showing practical differences:
📈
docs/architecture/architecture_diagrams.mdVisual representations using Mermaid diagrams to illustrate system architectures, abstraction layers, and training workflows.
Architecture Insights
AReaLite Example (simple and direct):
Core Example (declarative and complex):
Selection Guidelines
The documentation provides clear decision criteria:
Impact
This analysis helps users make informed architectural decisions and understand the "90% functionality, 10% complexity" philosophy that drives AReaLite's design as the foundation for future AReaL API evolution.
💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.