Filter Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Purpose Alignment: The austral/filter-bundle appears to be a query builder/mapper for filtering data, likely designed to integrate with the Austral framework (a PHP/Symfony-based ecosystem). If the product is built on Symfony/Laravel (or a similar stack), this bundle could streamline:
  • Dynamic query filtering (e.g., API request filtering, admin panels, or search functionality).
  • Consistent data transformation between layers (e.g., DTOs, API responses, or database queries).
  • Reusable filter logic (e.g., pagination, sorting, or complex nested filters).
• Symfony vs. Laravel Compatibility:
  • The bundle is Symfony-centric (given its Bundle suffix and dependencies on austral/* bundles). Laravel does not natively support Symfony bundles, but bridging is possible via:
    • Symfony Bridge (e.g., symfony/bridge or spatie/symfony-laravel).
    • Standalone Filter Logic: Extracting the core filtering logic (e.g., Mapper/Builder classes) and adapting them to Laravel’s Query Builder or Eloquent.
  • Risk: Tight coupling to Symfony’s EventDispatcher, DependencyInjection, or FormComponent may require refactoring.

Integration Feasibility

• Core Features:
  • Filter Builder: Likely provides a fluent API for constructing queries (e.g., Filter::where()->orWhere()->apply()).
  • Mapper: Transforms filtered results into structured data (e.g., DTOs, API responses).
  • Integration with Austral Tools/Form Bundles: Depends on austral/tools-bundle and austral/form-bundle, which may introduce additional dependencies (e.g., custom validation, form handling).
• Laravel Adaptation:
  • Option 1: Partial Adoption – Use only the filter logic (e.g., a Filter class) without Symfony’s DI/Events.
  • Option 2: Full Bundle Integration – Requires Symfony + Laravel interop (e.g., using symfony/console for CLI tools or spatie/laravel-symfony).
  • Option 3: Rewrite – Reimplement the bundle’s logic in Laravel-native code (highest effort, lowest risk).

Technical Risk

Key Questions

1. Business Justification:
   • Does the product need dynamic filtering beyond Laravel’s built-in tools (e.g., where(), scope())?
   • Are there existing solutions (e.g., spatie/laravel-query-builder, baum/baum) that could be evaluated first?
2. Architectural Impact:
   • Would integrating Symfony components bloat the Laravel app? (e.g., autoloading, DI complexity).
   • Can the bundle’s mapper functionality be replaced with Laravel’s resources or DTOs?
3. Team Expertise:
   • Does the team have Symfony experience to debug integration issues?
   • Is there bandwidth to maintain a fork or adapt the codebase?
4. Alternatives:
   • Compare against:
     • Laravel-native: spatie/laravel-query-builder, baum/baum, laravel-excel (for filtering exports).
     • Generic PHP: ash-alliance/php-filter, league/filter-operator.
5. Long-Term Viability:
   • Is the austral ecosystem actively maintained? (Check GitHub activity, Packagist updates.)
   • Would a custom solution (e.g., a FilterService) be more sustainable?

Integration Approach

Stack Fit

• Laravel Compatibility:

  • Direct Integration: Not feasible due to Symfony’s Bundle structure.
  • Hybrid Approach:
    • Use the bundle’s core logic (e.g., Filter/Mapper classes) as standalone libraries.
    • Replace Symfony dependencies with Laravel equivalents:
      • EventDispatcher → Laravel’s Events system.
      • FormComponent → Laravel’s FormRequest or Validator.
      • DependencyInjection → Laravel’s ServiceContainer.
  • Example Stack:

    Symfony Component	Laravel Equivalent
    EventDispatcher	Illuminate\Support\Facades\Event
    FormComponent	Illuminate\Http\Request
    DependencyInjection	Laravel’s IoC Container
    Twig (if used)	Laravel’s Blade or Inertia

• Recommended Path:

  1. Extract Core Logic: Isolate the FilterBuilder and Mapper classes from the bundle.
  2. Create Laravel Packages: Wrap extracted logic in Laravel-compatible packages (e.g., vendor/package-filter).
  3. Gradual Adoption: Start with API filtering, then expand to admin panels or exports.

Migration Path

1. Assessment Phase (1–2 weeks):
   • Fork the repository and strip Symfony dependencies.
   • Test core functionality (e.g., filtering, mapping) in a Laravel sandbox.
   • Benchmark performance vs. alternatives (e.g., spatie/laravel-query-builder).
2. PoC Phase (2–3 weeks):
   • Implement a minimal viable filter (e.g., for a /products API endpoint).
   • Compare with Laravel’s native where() or scope() methods.
3. Integration Phase (3–4 weeks):
   • Replace Symfony-specific code with Laravel equivalents.
   • Publish as a private/composer package for internal use.
4. Full Adoption (Ongoing):
   • Roll out to high-priority modules (e.g., admin dashboards, search).
   • Monitor for performance regressions or edge cases.

Compatibility

• PHP 8.0–8.2: Fully compatible with Laravel 9/10.
• Database: Assumes Doctrine DBAL (Symfony’s default). Laravel uses Eloquent/Query Builder.
  • Workaround: Use Doctrine DBAL as a bridge or translate queries to Eloquent.
• Form Handling: If the bundle relies on austral/form-bundle, consider:
  • Laravel’s FormRequest for validation.
  • spatie/laravel-form-tools for complex forms.
• Event System: Replace Symfony events with Laravel’s Events facade.

Sequencing

1. Phase 1: API Filtering
   • Use the bundle’s FilterBuilder to handle GET request parameters (e.g., ?sort=name&limit=10).
   • Integrate with Laravel’s Route Model Binding or API Resources.
2. Phase 2: Admin Panel
   • Adapt the Mapper for data transformation in admin interfaces (e.g., Laravel Nova or Filament).
3. Phase 3: Export/Reporting
   • Extend filtering to Excel/PDF exports (e.g., laravel-excel).
4. Phase 4: Real-Time Filtering
   • If using Livewire/Inertia, adapt the bundle’s logic for frontend filtering.

Operational Impact

Maintenance

• Pros:
  • MIT License: No legal restrictions.
  • Lightweight Core: If stripped of Symfony dependencies, maintenance should be low.
• Cons:
  • Fork Risk: If upstream changes break compatibility, the fork must be maintained.
  • Undocumented Features: Minimal docs may lead to hidden dependencies.
• Mitigation:
  • Contribute Upstream: Engage with the austral team to improve Laravel compatibility.
  • Automated Testing: Add PHPUnit tests for critical filter scenarios.
  • **Deprec