Cleaner Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Purpose Alignment: The package (adgoal/cleaner-bundle) is a Symfony wrapper for lamoda/cleaner, designed to clear stale data from databases, queues, or other storage layers. This aligns well with Laravel/PHP applications needing scheduled cleanup (e.g., logs, old records, temporary data) to optimize performance and storage.
• Symfony vs. Laravel Compatibility:
  • Risk: Laravel does not natively support Symfony bundles, requiring adaptation (e.g., via symfony/flex or manual integration).
  • Workaround: The underlying lamoda/cleaner library (PHP-based) could be directly integrated into Laravel, bypassing the bundle layer.
• Key Use Cases:
  • Database table pruning (e.g., DELETE FROM logs WHERE created_at < NOW() - INTERVAL '30 days').
  • Queue/message cleanup (e.g., failed jobs, expired events).
  • File system or cache purging (if extended).

Integration Feasibility

• Core Functionality: The package provides configurable SQL queries for cleanup, which is directly translatable to Laravel’s Eloquent or Query Builder.
• Symfony Dependencies:
  • Dependency Injection (DI): Laravel’s Service Container is compatible but may require manual binding of Symfony-specific services.
  • Configuration: YAML-based config (Symfony) can be replaced with Laravel’s .env or config/cleaner.php.
• Extensibility:
  • Supports multi-table queries and parameterized intervals (e.g., dynamic TTL).
  • Custom cleaners can be added via PHP classes (e.g., for Redis, S3, or custom storage).

Technical Risk

Key Questions

1. Does the application need Symfony-specific features (e.g., EventDispatcher, Profiler)?
   • If no, use lamoda/cleaner directly.
2. Are there existing cleanup mechanisms (e.g., Laravel’s softDeletes, scheduled jobs)?
   • If yes, assess redundancy.
3. What storage layers require cleanup (DB, queues, files, etc.)?
   • Prioritize high-impact tables first.
4. How will cleanup be triggered (cron, Laravel’s scheduler, or manual)?
5. Are there compliance/retention policies (e.g., GDPR, legal holds)?
   • Avoid accidental data deletion.

Integration Approach

Stack Fit

• Laravel Compatibility:
  • Direct Library Use: Prefer lamoda/cleaner (PHP) over the Symfony bundle to avoid DI conflicts.
  • Service Wrapper: Create a Laravel service class to encapsulate cleaner logic:

    class CleanerService {
        public function __construct(private Cleaner $cleaner) {}
        public function pruneLogs(int $days): void {
            $this->cleaner->delete('logs', "created_at < NOW() - ($days || ' days')::interval");
        }
    }
    

• Database Support:
  • Works with PostgreSQL, MySQL, SQLite (via PDO).
  • NoSQL/Redis: Requires custom adapters (not natively supported).
• Queue Systems:
  • Supports Doctrine DBAL (compatible with Laravel’s database layer).
  • For Laravel Queues (Redis, database), extend the library or use queue:prune commands.

Migration Path

1. Assessment Phase:
   • Audit storage layers (DB tables, queues, files) for stale data.
   • Define cleanup rules (e.g., "Delete logs older than 30 days").
2. Proof of Concept (PoC):
   • Test lamoda/cleaner directly in a Laravel app.
   • Example:

     $cleaner = new \Lamoda\Cleaner\DB\Cleaner($pdo);
     $cleaner->delete('failed_jobs', "created_at < NOW() - INTERVAL '7 days'");
     

3. Integration:
   • Option A: Replace Symfony bundle with a Laravel service (recommended).
   • Option B: Use a Symfony microkernel (overkill for most Laravel apps).
4. Automation:
   • Schedule via Laravel’s schedule:run or cron:

     // app/Console/Kernel.php
     $schedule->command('cleaner:run')->dailyAt('2:00');
     

Compatibility

Sequencing

1. Phase 1: Implement DB table cleanup (highest ROI).
2. Phase 2: Extend to queues/files if needed.
3. Phase 3: Add monitoring/logging for cleanup jobs.
4. Phase 4: Optimize queries (e.g., batch deletions, indexes).

Operational Impact

Maintenance

• Pros:
  • Config-driven: Rules defined in config/cleaner.php (easy to modify).
  • No vendor lock-in: Underlying library is lightweight.
• Cons:
  • No active maintenance: Last release in 2020; fork or maintain locally.
  • Documentation gaps: README lacks Laravel-specific examples.
• Recommendations:
  • Add Laravel-specific tests to a fork.
  • Document cleanup rules in a CONTRIBUTING.md.

Support

• Debugging:
  • Use Laravel’s logging to track cleanup jobs:

    \Log::info('Cleanup executed', ['query' => $query, 'affected' => $affectedRows]);
    

  • Rollback strategy: Backup tables before running deletions.
• Community:
  • Limited support; rely on GitHub issues or lamoda/cleaner upstream.
  • Consider Slack/Discord communities for Symfony/Laravel interop.

Scaling

• Performance:
  • Batch deletions: Use LIMIT clauses for large tables (e.g., DELETE FROM logs WHERE ... LIMIT 1000).
  • Indexing: Ensure created_at columns are indexed for faster queries.
• Concurrency:
  • Avoid locks: Set transactional: false unless required.
  • Queue cleanups: Run during low-traffic periods.
• Horizontal Scaling:
  • Cleanup jobs are stateless; can run on any server in a cluster.

Failure Modes

Ramp-Up

• Onboarding:
  • For Developers:
    • 1 hour to understand lamoda/cleaner basics.
    • 2 hours to integrate into Laravel (service wrapper).
  • For Ops:
    • 30 mins to configure cron/Laravel scheduler.
• Training Needs:
  • SQL query safety (avoid DELETE without backups).
  • Monitoring cleanup jobs (e.g., laravel-horizon for queues).
• Documentation:
  • Create a Laravel-specific guide covering:
    • Service setup.
    • Example cleanup rules.
    • Monitoring and rollback procedures.