Filter Sorter Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Symfony-Centric Design: The bundle is tightly coupled with Symfony’s ecosystem (e.g., QueryBuilder, ParamConverter, Repository patterns), making it a natural fit for Symfony-based APIs but less flexible for non-Symfony PHP applications (e.g., standalone Laravel, Lumen, or custom MVC frameworks).
• Specification Pattern Alignment: Leverages doctrine-specification, which is a clean abstraction for filtering logic but introduces additional dependency management (e.g., resolving specification classes dynamically).
• API-First Focus: Optimized for RESTful APIs (query string parsing, ParamConverter integration), but web apps would require manual adaptation (e.g., form handling, frontend integration).
• Laravel Incompatibility: High risk due to:
  • Symfony-specific components (QueryBuilder, Repository interfaces).
  • Lack of Laravel service container/dependency injection compatibility.
  • No Eloquent ORM integration (relies on Doctrine).

Integration Feasibility

• Low Feasibility for Laravel:
  • No native support for Laravel’s Eloquent or Query Builder.
  • Manual shimming would be required to adapt Symfony’s QueryBuilder to Laravel’s Builder or Query classes.
  • ParamConverter integration would need custom middleware/route handling (Laravel uses FormRequest or manual parsing).
• Workarounds:
  • Option 1: Rewrite core logic (e.g., filter/sort services) in Laravel-compatible PHP, stripping Symfony dependencies.
  • Option 2: Use as a reference architecture for building a Laravel-specific package (e.g., spatie/laravel-query-builder + custom specs).
• Dependency Risks:
  • doctrine-specification is abandoned (last commit: 2017). May require forks or replacements (e.g., Laravel’s Criteria pattern).
  • No Laravel-specific testing or community support.

Technical Risk

Key Questions

1. Is Symfony interoperability a hard requirement?
   • If no, rewrite or replace with Laravel-native alternatives (e.g., spatie/laravel-query-builder + custom filter logic).
2. Can we tolerate dependency on abandoned packages?
   • If no, fork doctrine-specification or use Laravel’s Criteria pattern.
3. Is API filtering/sorting a priority?
   • If yes, evaluate Laravel packages like beberlei/doctrineextensions (for query filtering) or build a lightweight solution.
4. What’s the effort vs. ROI?
   • For a small project, a custom solution may be faster.
   • For large-scale APIs, consider investing in a Laravel-specific bundle.

Integration Approach

Stack Fit

• Laravel Incompatibility: The bundle is not natively compatible with Laravel due to:
  • Symfony’s QueryBuilder vs. Laravel’s Builder/Query.
  • Service container differences (Symfony’s ContainerInterface vs. Laravel’s Container).
  • Event system (EventDispatcher) and ParamConverter reliance.
• Partial Fit:
  • Filter/Sort Logic: The specification pattern is valuable and can be adapted.
  • Query Parsing: Laravel’s Request object can manually parse query strings (e.g., filter[field]=value).

Migration Path

Compatibility

• Doctrine ORM: The bundle assumes Doctrine. Laravel uses Eloquent, requiring:
  • Query grammar translation (e.g., Doctrine\DBAL → Illuminate\Database).
  • Repository pattern adaptation (Eloquent doesn’t use repositories by default).
• Symfony Components:
  • EventDispatcher: Replace with Laravel’s Events facade.
  • Serializer: Not needed unless using API Platform-like features.
• Query String Parsing:
  • Laravel’s Request can parse filters manually (e.g., request()->query('filter')).

Sequencing

1. Assess Scope:
   • Start with basic filtering/sorting (e.g., where, orderBy).
   • Avoid full Specification pattern if overkill.
2. Prototype Core Logic:
   • Implement a minimal filter/sort service in Laravel.
   • Example:

     class FilterService {
         public function apply(Request $request, Builder $query) {
             if ($request->has('filter')) {
                 $query->where($this->parseFilter($request->filter));
             }
             return $query;
         }
     }
     

3. Integrate with API:
   • Use middleware to apply filters globally.
   • Example:

     public function handle(Request $request, Closure $next) {
         app(FilterService::class)->apply($request, $request->route()->controller);
         return $next($request);
     }
     

4. Replace Bundle Components:
   • Gradually replace FilterQueryManager with Laravel services.
   • Example:

     // Instead of ParamConverter, use:
     $filters = json_decode($request->filter, true);
     $query->where($filters);
     

Operational Impact

Maintenance

• High Ongoing Effort:
  • No Laravel support: Requires custom maintenance for any Symfony-specific updates.
  • Deprecated Dependencies: doctrine-specification may break; forks or replacements needed.
• Testing Overhead:
  • No existing Laravel test suite; manual QA required for edge cases (e.g., nested filters, complex sorts).
• Documentation Gaps:
  • Bundle lacks Laravel-specific guides; internal docs must cover adaptations.

Support

• Community Risk:
  • 0 stars/dependents → No community support or troubleshooting.
  • Last release in 2018 → Likely incompatible with modern PHP/Laravel.
• Vendor Lock-in:
  • Tight coupling to Symfony makes vendor support impossible.
• Fallback Options:
  • Laravel packages like spatie/laravel-query-builder or beberlei/doctrineextensions (if Doctrine is used).

Scaling

• Performance:
  • Specification pattern adds overhead for complex queries (e.g., chained specs).
  • Laravel’s native Builder is optimized for performance; custom adapters may introduce bottlenecks.
• Horizontal Scaling:
  • No inherent issues, but custom query logic must be tested under load.
• Database Impact:
  • Poorly optimized filters/sorts can cause N+1 queries or inefficient joins.

Failure Modes

Ramp-Up

• Learning Curve:
  • Moderate for Symfony devs; steep for Laravel teams unfamiliar with:
    • Specification pattern.
    • Symfony’s QueryBuilder/Repository patterns.
• Onboarding Time:
  • 2–4 weeks for a Laravel team to:
    1. Adapt core logic.
    2. Test edge cases (e.g., nested filters).
    3. Document custom integrations.
• Team Skills Required:
  • PHP/Laravel proficiency.