Laravel DSQL

What the package does

Laravel DSQL provides;

• A declarative query schema (per model or endpoint) defining:
  • Which columns/relationships can be selected, filtered, or sorted
  • Allowed operators (=, like, between, in)
  • Type hints (string, numeric, date, boolean, etc)
• A parser and executor that turns structured input into:
  • A constrained query on your models
  • With correct joins / relations / where clauses applied
• A safe “query DSL” for clients (UI or API consumers) without giving them raw SQL powers.

The goal is to keep all query logic and safety rules in code, while letting frontends build rich filtering/search/sort experiences dynamically.

Typical use cases

This package is useful when you want:

• A flexible, filterable listing (eg admin tables, reporting pages) driven by user-selected filters and sorting.
• A public API where clients can express complex queries (filters, ranges, nested AND/OR) but you don’t want to expose your DB or write a new controller for every combination.
• A centralised definition of “what can be queried” for a given resource, so security and performance constraints live in one place rather than scattered across controllers.

Instead of building ad-hoc if ($request->has('status')) { ... } chains everywhere, you describe the allowed query, and DSQL applies it.

High-level workflow

The typical flow looks like:

1. Define a query schema for a model/resource;
   • Allowed fields, operators, and sorts
   • Optional limits / defaults.
2. Accept a structured query from a request:
   • JSON body
   • Query string
   • Or a server-side-constructed array
3. Pass the schema + input into DSQL:
   • It validates against your schema
   • Translates into a Laravel query
4. Execute the query
   • Get the results, paginate, export, etc.

This keeps your controllers thin: they mostly define “which schema” and hand the input to the package.

Key features at a glance

Example: Dynamic filtering for an index view

A typical controller method might look like this:

public function index(Request $request)
{ 
  // 1. Get user input from the request.
  $input = $request->input('search');
  
  // 2. Apply the input to the query object.
  $query = AdvancedSearch::apply(
    query: User::query(),
    input: $input
  );
  
  // 3. Return the results of the database query.
  return UserResource::collection(
    $query->paginate()
  );
}

public function index(Request $request)
{ 
  // 1. Get user input from the request.
  $input = $request->input('search');
  
  // 2. Apply the input to the query object.
  $query = AdvancedSearch::apply(
    query: User::query(),
    input: $input
  );
  
  // 3. Return the results of the database query.
  return UserResource::collection(
    $query->paginate()
  );
}

On the frontend, you can collect the ‘search’ parameter from a UI that either builds a query string interactively, or directly expose a text input for a query to enter structured queries, instead of custom endpoints for every combination.

Why I built it

This package grew out of the same repeated pain:

• Complex filterable tables and reporting endpoints turning into massive, brittle controller methods.
• API consumers wanting richer querying semantics without exposing raw SQL or backing yourself into a maintenance corner.
• A desire to keep constraints, types, allowed relations, and operators in code, while letting clients express “what they want” in a small, predictable DSL.

Laravel DSQL is the layer between “user-controlled filtering” and “actual database queries”, giving you control and safety without sacrificing flexibility.

Where it fits in your stack

Use laravel-dsql when:

• You need dynamic, user-driven querying over data.
• You care about security and performance constraints on those queries.
• You want one place to define the query capabilities of a resource, instead of re-implementing filter logic everywhere.

It’s not an ORM replacement, not a reporting engine, and not a full analytics platform – it’s a pragmatic, Laravel-native way to safely turn structured user query input into real queries.