Parser Laravel Package

Technical Evaluation

Architecture fit: Laravel's synchronous request lifecycle conflicts with amphp/parser's async/streaming design. Integration requires explicit async runtime (e.g., Swoole/RoadRunner) – standard FPM deployments would face fundamental incompatibilities.
Integration feasibility: Viable only for isolated streaming use cases (e.g., large file processing, WebSocket data), but requires wrapping Laravel's sync code in Amp's event loop, breaking middleware/session/database transaction assumptions.
Technical risk: High. Low adoption (149 stars) and sparse Laravel-specific usage examples increase uncertainty. Potential conflicts with Laravel's synchronous database connections and session handling could cause subtle bugs.
Key questions: How does it handle Laravel's database transactions? Does it work with queue workers? What PHP version constraints exist? Are there documented Laravel integrations?

Integration Approach

Stack fit: Only suitable for projects already using async PHP runtimes (Swoole/RoadRunner). Standard Laravel deployments would require full-stack re-architecture.
Migration path: Start with a single non-critical streaming feature (e.g., CSV processing without memory overhead). Use Amp's async streams to parse data incrementally, then feed results into Laravel models via isolated service classes.
Compatibility: Requires PHP 8.1+ (matches Laravel 10+), but must verify Symfony component compatibility. Amp's async streams may conflict with Laravel's synchronous stream wrappers.
Sequencing: Phase 1: POC in a dedicated async service for one streaming task. Phase 2