A minimal DSL for mapping query parameters to composable filter functions in Elixir/Ecto/Phoenix applications.
Filterable is an Elixir library that provides a domain-specific language (DSL) for transforming HTTP query parameters into composable filter functions. It simplifies building dynamic, parameter-driven queries in Phoenix controllers, Ecto models, or standalone modules, promoting clean separation of filtering logic from business logic.
Elixir developers building web applications with Phoenix and Ecto who need to handle complex filtering from query parameters, as well as developers working on pure Elixir projects requiring parameter-driven data filtering.
Developers choose Filterable for its minimal, framework-agnostic DSL that offers composable filters, extensive configuration options, and Ecto helpers, enabling maintainable filtering logic without external dependencies, inspired by Ruby's has_scope.
Filtering from incoming params in Elixir/Ecto/Phoenix with easy to use DSL.
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Supports configurable parameter names, default values, and type casting with @options like param and cast, as shown in examples for mapping multiple or nested parameters.
Filters are built to be combined, enabling complex query construction from multiple parameters while keeping filtering logic separate from business logic, inspired by Ruby's has_scope.
Includes macros for field filtering, pagination, limiting, and ordering, reducing boilerplate code in Ecto models, as demonstrated with paginateable and orderable examples.
Works with Phoenix controllers, Ecto models, or pure Elixir projects without external dependencies, offering versatility for different use cases.
Each filter requires explicit definition with @options, which can be cumbersome for applications with many simple field-based filters, adding initial setup overhead.
While Ecto helpers cover basics, complex queries involving multiple joins or custom SQL expressions may require manual work outside the DSL, limiting out-of-the-box functionality.
Casting to atoms requires a predefined list to prevent memory leaks, adding complexity and potential runtime errors if the list is incomplete or mismanaged.