Laravel Purity Laravel Package

Product Decisions This Supports

• Self-service data exploration: Enable frontend teams to build dynamic, user-driven filtering/sorting without backend API changes (e.g., admin dashboards, public-facing search).
• API consistency: Standardize filtering/sorting across all Eloquent queries, reducing ad-hoc query logic in controllers.
• Livewire integration: Accelerate development of interactive tables/forms by offloading filtering logic to the package (e.g., SaaS admin panels).
• Roadmap prioritization:
  • Build vs. Buy: Replace custom filter middleware or libraries (e.g., Spatie’s QueryBuilder) if they lack relation support or Livewire integration.
  • Feature parity: Justify investing in frontend tooling (e.g., qs library) to leverage Purity’s query syntax.
• Use cases:
  • Public APIs: Filterable endpoints for e-commerce (e.g., ?filters[price][$gt]=100), SaaS (e.g., ?filters[status][$eq]=active).
  • Internal tools: Dynamic reports (e.g., ?filters[created_at][$between]=2023-01-01,2023-12-31).
  • Legacy migration: Retrofit filtering to existing APIs without rewriting controllers.

When to Consider This Package

Adopt if:

• Your Laravel app uses Eloquent queries and needs consistent, URL-based filtering/sorting (e.g., REST APIs, Livewire components).
• You prioritize developer velocity over fine-grained control (e.g., complex custom filters via raw SQL).
• Your team uses Livewire or plans to build interactive tables with real-time filtering.
• You need relation filtering/sorting (e.g., ?filters[user.name][$contains]=John) without writing custom joins.
• Your frontend team prefers query string parameters (e.g., qs library) over GraphQL-style inputs.

Look elsewhere if:

• You require SQL-level performance optimizations (Purity adds query overhead; benchmark for large datasets).
• Your filters need arbitrary SQL logic (e.g., WHERE date BETWEEN NOW() - INTERVAL '7 days' AND NOW()).
• You’re using non-Eloquent data sources (e.g., raw database connections, external APIs).
• Your project uses GraphQL (consider Laravel GraphQL packages like spatie/laravel-graphql).
• You need multi-tenancy isolation in filters (Purity doesn’t natively support tenant-aware queries).
• Your team lacks PHP/Laravel expertise to debug query generation (Purity’s error messages may be opaque).

How to Pitch It (Stakeholders)

For Executives: "Laravel Purity lets our frontend and backend teams move faster by standardizing how users filter and sort data—whether in APIs, admin dashboards, or public tools. For example, a sales team could search orders by ?filters[customer.name][$contains]=Acme&sort[0]=created_at:desc without backend changes. It’s like adding ‘Ctrl+F’ to every database query, reducing dev time by 30% on features like search, reporting, or user dashboards. The MIT license and active maintenance make it a low-risk bet."

For Engineering Leads: *"This package replaces ad-hoc filter logic in controllers with a declarative, trait-based approach. Key wins:

• Livewire integration: Add filtering to tables in minutes (e.g., Transaction::filter($this->filters)).
• Relation support: Filter/sort by related models (e.g., ?filters[user.role][$eq]=admin) without manual joins.
• Frontend-friendly: Frontend devs use standard query strings (e.g., qs library) to interact with APIs.
• Future-proof: Actively maintained (releases in 2026), with docs and tutorials. Tradeoff: Slight query overhead (~5–10% slower than raw SQL for complex filters). Recommend piloting on a non-critical API first."*

For Developers: *"Swap this:

// Before: Manual filtering in controller
if ($request->has('min_price')) {
    $query->where('price', '>=', $request->min_price);
}

For this:

// After: One line in model
$posts = Post::filter()->get(); // Handles ?filters[price][$gte]=100

• Pros: No more if spaghetti in controllers. Works with Livewire, APIs, and relations.
• Cons: Less control over SQL generation (though you can restrict fields). Benchmark for your use case."*