Model Filter Laravel Package

Product Decisions This Supports

• API/Backend Feature Development: Enables rapid implementation of search/filter endpoints (e.g., /api/users?filters[name]=John&filters[age][gt]=25) without manual query-building logic.
• Roadmap Prioritization: Justifies investing in reusable filter infrastructure for future projects or scaling existing ones (e.g., e-commerce product catalogs, CRM dashboards).
• Build vs. Buy: Avoids reinventing wheel for common filter patterns (e.g., =, >, <, LIKE, IN, OR/AND grouping) while maintaining flexibility for edge cases.
• Use Cases:
  • Admin panels with dynamic filtering (e.g., "Show active users aged 18–30").
  • Public APIs requiring client-side filtering (e.g., "Filter products by category, price range, or stock status").
  • Complex relationship queries (e.g., "Find orders where customer.name contains 'Smith' AND status is 'shipped'").

When to Consider This Package

• Adopt if:

  • Your Laravel app needs consistent, maintainable filtering across multiple models (e.g., 5+ Eloquent models requiring search).
  • You prioritize developer velocity over ultra-custom solutions (e.g., raw query builders or ad-hoc scopes).
  • Your filters involve relationships (e.g., user.role.name = 'admin') or operator support (age[gt]=18).
  • You’re using Laravel 9–13 and PHP 8.1+ (no polyfill overhead).

• Look elsewhere if:

  • You need full-text search (consider Algolia, Scout, or Laravel’s whereRaw).
  • Your filters require non-SQL logic (e.g., geospatial, custom business rules).
  • You’re locked into Laravel <9 or Lumen <9 (compatibility gaps).
  • Your team prefers declarative filter DSLs (e.g., Spatie’s Query Builder or Filament for admin panels).
  • You need real-time filtering (e.g., WebSocket-driven updates; this is for HTTP requests).

How to Pitch It (Stakeholders)

For Executives:

"This package lets us ship search/filter features 10x faster by standardizing how our backend handles queries like ‘find users aged 25–35 with role X.’ Instead of writing custom SQL or Eloquent scopes for every model, we’ll use a single, reusable trait—reducing dev time and tech debt. For example, an admin panel for user management could support filters like name=John&status[active]=true out of the box, with room to add advanced logic later. It’s lightweight (MIT-licensed), Laravel-native, and future-proofs our API for client-side filtering needs."

For Engineering:

*"Pros:

• DRY: Replace repetitive where() chains with a $filterable allowlist (e.g., ['name', 'role.id']).
• Operator Support: Built-in =, >, <, LIKE, IN, etc., with OR/AND grouping via filters[] array syntax.
• Relationships: Dot notation (e.g., user.role.name) enables nested filtering without manual joins.
• Scaffolding: php artisan make:filter generates a clean class for custom logic (e.g., UserFilter::apply($query)).
• Laravel 13 Ready: No legacy baggage; works with latest Eloquent features.

Trade-offs:

• Not a silver bullet: For geospatial or non-SQL filters, you’ll still need extensions.
• Learning curve: Team must adopt the filters[] namespace convention (v2 breaking change).

Use Case Example:

// Before: Manual query in a controller
$users = User::where('name', 'like', '%John%')
             ->whereHas('role', fn($q) => $q->where('name', 'admin'))
             ->get();

// After: One-liner with filter trait
$users = User::filter(request('filters'))->get();

Ask: Should we prototype this for [X feature] to validate the ROI?"*