Doctrine Qb Filter Laravel Package

Product Decisions This Supports

• Build vs. Buy: Avoids reinventing a query filtering wheel for Doctrine ORM, reducing development time and technical debt.
• Feature Expansion: Enables rapid implementation of dynamic filtering in admin panels, search APIs, or reporting tools without tightly coupling to repositories.
• Roadmap Alignment: Supports self-service data exploration for internal tools (e.g., analytics dashboards) or customer-facing APIs (e.g., filtering products by attributes).
• Use Cases:
  • Admin UIs: Filter entities (e.g., users, orders) based on nested/multi-criteria inputs (e.g., task.is_not_null, created_at.gte).
  • APIs: Expose flexible filtering via query params (e.g., /users?filter[task][is_not_null]=true).
  • Legacy Systems: Retrofit filtering to existing Doctrine queries without refactoring repositories.

When to Consider This Package

• Adopt if:

  • Your app uses Doctrine ORM and needs dynamic, declarative filtering (e.g., admin panels, search).
  • You prioritize developer velocity over custom query builder logic.
  • Your filtering logic is simple to moderately complex (e.g., is_null, eq, gt, nested relations).
  • You’re not using repositories (or can bypass them) and prefer a lightweight solution.

• Look elsewhere if:

  • You need advanced aggregations (GROUP BY, HAVING) or full-text search (consider Elasticsearch or Doctrine Extensions).
  • Your filtering requires complex joins or custom SQL (e.g., window functions).
  • You’re using Symfony’s native QueryBuilder heavily and want tighter integration (e.g., DQL paths).
  • Your team prefers type safety over runtime filtering (e.g., GraphQL or API Platform filters).
  • The proprietary license conflicts with open-source policies (though the repo is MIT-like; clarify with maintainer).

How to Pitch It (Stakeholders)

For Executives: "This package lets us add powerful, flexible filtering to our [admin/API] without writing repetitive query logic. For example, instead of manually building queries to find ‘users with tasks,’ we can use a simple array like filter['task']['is_not_null'] = true. This cuts dev time by 30%+ for common filtering use cases, while keeping the system scalable. Low risk—it’s a lightweight, battle-tested wrapper for Doctrine."

For Engineers: *"The doctrine-qb-filter package abstracts away boilerplate for dynamic Doctrine queries. Key benefits:

• No repositories needed: Works directly with entities.
• Supports nested filters: E.g., filter['user']['tasks']['status']['eq'] = 'completed'.
• Symfony-friendly: Integrates with DI and Config components.
• Minimal overhead: ~50 LOC to implement basic filtering.

Tradeoff: Limited to basic conditions (no custom SQL). Ideal for CRUD-heavy apps or admin tools. Example:*

$filter = new FilterRequest();
$filter->filter['created_at']['gte'] = '2023-01-01';
$users = $queryFilter->getResults(User::class, $filter)->items;
```*
*Proposal: Pilot in the [Admin Panel] to replace manual QueryBuilder logic."*