DEV Community: Jefferson Silva

The code won’t be your real problem

Jefferson Silva — Sun, 12 Apr 2026 01:55:02 +0000

The business journey of building a developer tool for PHP

Many of us developers are emotionally invested in proportion to our technical knowledge and inversely proportional to our commercial maturity. I was like that. And I had to learn the hard way.

Building software that adds value to the end user is much more about how the person sees you from the other side than about how much you deliver technically. It doesn't matter how innovative your technology is — if you don't convey trust and don't have a minimum level of credibility, nobody will use it. And when your audience is developers, selling becomes even harder, because they're skeptical by nature.

Understand the audience before writing code

Understanding my audience was the first thing I had to do. Who is going to use this? How do I want them to use it? I need a "wow" moment to keep them engaged. And I need them to come back — retention is just as important as acquisition.

I had three fronts to manage from the start:

Understand who my primary user was. In my case, developers who had never set up a debugger or who gave up trying. People living on dd() and var_dump() not by choice, but because there was no accessible alternative.

Drive traffic starting with people I know. Brazil has a large PHP community and speaks my language. Using your own country to validate your product in the hands of people who have no idea how it works, but are curious, is incredibly valuable. It's easier to communicate and express exactly what you feel and what you want to say when you do it in your own language. I validated in Portuguese first. Only then did I go after the real conversion market.

Prepare the product for the market that pays. Tier 1 countries — United States, Canada, United Kingdom, European Union. This audience is more demanding, but by the time I reached them I was already prepared technically and psychologically. The subscription model with a trial exists for these users: they use it, feel it, and decide. If it doesn't deliver, they cancel. Simple. I believe in my product. I use it every day.

Traffic without money

You might be wondering: how do you handle traffic without investment?

The key is using analytics tools to track your audience and publishing in forums, community pages, and relevant spaces. It will grow slowly and organically. But you need to understand something fundamental: to get the users who will pay for your product, you first need the ones who won't. They will bring the ones who pay. And they are the ones who will flood you with bug reports and force you to improve.

I needed to create a connection and build trust with my audience. Having that bridge is essential, no matter how hard it is to build.

The open source engine as a bridge

I created the ddless-engine as an open source project. Not out of idealism. Out of strategy.

The engine is a way for developers to contribute and see how the DDLess motor works for a purpose quite different from the conventional. They can learn how PHP works at a deeper level — Closure::bind, stream wrappers, AST parsing, debug_backtrace — things that modern frameworks abstract away completely.

The open engine does three things: it builds trust (the developer can read every line of code), it attracts contributors, and it works as technical marketing (posts about the engine generate interest in the full product).

Real visibility

Now that we have the product, understand the market, and built the bridge between user and product, we need real visibility to gain traction.

And here comes the question: does your product have the conditions to receive external investment?

In my case, no. The return rate is very low at the start and I did this because I love the PHP community and because I have other projects that need visibility to work. In my case, it's a long-term plan.

But you can also invest your own money to gain more visibility. When you understand the market, that's already half the way. The other half is creating a communication channel that helps you convert. Your ads will target the right audience and that gives you a return proportional to your investment.

The truth nobody talks about

If you're a solo developer like me, you'll have to do everything: code, marketing, support, bureaucracy, design, distribution, certification. And you'll spend hours planning and thinking.

The code won't be anywhere near your real problem.

The real problem is: does anyone know your product exists? Does anyone trust it enough to download it? Does anyone see enough value to pay for it? Does anyone come back after the first time?

If you don't answer these questions before writing the first line of code, you'll build something technically brilliant that nobody uses.

I almost did that. DDLess almost became just another forgotten repository on GitHub. What saved it wasn't the code. It was understanding that the code is just the beginning.

Jefferson Silva is the creator of DDLess, a PHP development workbench. The technical article about building DDLess was featured in PHP Reads Issue #6 by Stefan Priebsch and Sebastian Bergmann.

Open source engine: github.com/behindSolution/ddless-engine
Product: ddless.com

I built a framework to turn Laravel + Livewire apps into desktop & mobile apps using PHP WebAssembly, no Electron, no React Native

Jefferson Silva — Thu, 09 Apr 2026 14:04:14 +0000

Hey everyone,

I've been working on a side project called NativeBlade and wanted to share it with the community.

The idea is simple: take your Laravel + Livewire app and run it as a native desktop or mobile application. No server needed. No Electron. No JavaScript frameworks. Just PHP and Blade.

How it works

Your entire Laravel application gets bundled and runs inside a PHP WebAssembly runtime, wrapped in a https://v2.tauri.app shell. The architecture looks like this:

PHP 8.3 runs in the browser via WebAssembly
Blade templates and Livewire components work as-is
SQLite database persists to IndexedDB (survives app restarts)
Native shell components (header, bottom nav, drawer) render outside the WebView — no flicker during navigation
Native OS features (dialogs, notifications, system tray) work through a bridge

The whole thing started as a weekend experiment: "what if I could just composer require something and turn my Laravel app into a desktop app?"

What it can do

Desktop: Windows, macOS, Linux with native menus and system tray
Mobile: Android & iOS with status bar, safe area, swipe back
External HTTP requests: Http::get() works transparently through a JS bridge — PHP signals what it needs, JavaScript makes the real fetch, PHP re-executes with the cached

response. You can even use NativeBlade::pool() to run multiple requests in parallel via Promise.all()

1,512 built-in icons from https://phosphoricons.com/ — works in both shell components and Blade templates
Hot reload during development via a Vite plugin that watches PHP/Blade files
Offline-first — everything runs client-side, no internet required after install

That's it. Your Laravel app is now a desktop application.

What doesn't work

I want to be upfront about the limitations. Since PHP runs in WebAssembly, there's no real server:

No queues/jobs — no background worker process
No mail — no SMTP from WASM
No MySQL/Postgres — SQLite only
No sessions — uses a built-in state management instead
No cron/scheduling
Http::get() works but through a bridge (not native PHP networking)

It's not meant to replace server-side Laravel. It's for apps that run locally and don't need a backend, think tools, dashboards, utilities, offline apps.

Why I'm sharing this

This started as a learning project and I'd love to get feedback from the PHP community. The codebase touches a lot of interesting areas:

PHP WebAssembly internals
Tauri 2 (Rust-based alternative to Electron)
Livewire's lifecycle inside a non-standard runtime
Bridging sync PHP with async JavaScript

If any of this sounds interesting to you — whether you want to contribute, experiment, or just tell me what I'm doing wrong — I'd appreciate it.

GitHub: https://github.com/NativeBlade/NativeBlade

Happy to answer any questions!

The Technical Journey of Building a PHP Debugger from Scratch

Jefferson Silva — Mon, 30 Mar 2026 14:22:10 +0000

The Origin

I've been working with PHP and Laravel for years. And like every PHP developer, I've been through that classic cycle: install Xdebug, configure xdebug.mode=debug, map paths in PHPStorm, pray that Docker doesn't change the internal network IP, and when it finally works... it's slow. Every request takes seconds longer.

But the real problem was never performance. It was setup. I was working on projects running in Docker via Laravel Sail, others on WSL, some with SSH to staging. Each environment meant a different Xdebug configuration. Network changed? Redo it. Spun up a new container? Remap paths. Switched machines? Start from zero.

The turning point was on a Sunday. I had a production bug in a Laravel project, needed to debug fast, and spent 40 minutes just trying to get Xdebug to connect through Docker. When it finally did, the breakpoint landed on the wrong line because the path mapping was off by one level. At that moment I thought: "This can't be this hard. What if the debugger didn't need any extension at all? What if it was part of the code itself?"

That's how DDLess was born.

Iteration 1: phpdbg

Before instrumenting code, my first idea was to use what already existed. PHP has phpdbg, a built-in interactive debugger. It uses Zend Engine opcodes, it's fast, and it doesn't need an extension. Seemed perfect.

The problem is that phpdbg was designed to be interactive in the terminal. It has no clean communication protocol for integrating with an external UI. To make it work with a graphical interface, I would have to parse its text output, which changes between PHP versions. On top of that, it doesn't work well inside contexts like Laravel Sail or Docker because it needs to be the process entrypoint, and that doesn't work when you have a web server in front.

Within a few hours I realized this path would lead me down a compatibility rabbit hole. I scrapped it.

Iteration 2: Regex and Tokenizer

The next idea was: what if I injected debug calls directly into the PHP code before execution? Something like a ddless_step_check(__FILE__, __LINE__) before each executable line. If PHP ran this modified code, I'd have full control over the execution flow without needing any extension.

The first step was figuring out which lines are "instrumentable," meaning where it makes sense to place a breakpoint. There's no point placing one on a comment, a class declaration, or in the middle of a multiline string.

My first implementation used PHP's token_get_all() to tokenize the code and a state machine with regex to decide where to inject. It worked for simple cases:

$x = 1;           // instrumentable
echo $x;          // instrumentable
if ($x > 0) {     // instrumentable

But the edge cases were endless. Chained method calls across multiple lines:

$query->where('status', 'active')
      ->orderBy('created_at')  // continuation, not a new statement
      ->get();

Heredoc/nowdoc strings with PHP code inside. Multiline arrays where the closing ] was on the next line. elseif that needed special handling because you can't inject a line before an elseif, as it would break the if chain. Same for else, catch, and finally.

It was almost 600 lines of code between ddless_analyze_code_tokens(), ddless_is_safe_to_inject_before(), and several helper functions. And every week a new case would break things. A developer would use a different coding pattern and the instrumentation would generate a syntax error.

I knew I was building on sand. But it worked for a while, and it allowed me to validate that the core idea — code instrumentation combined with file-based IPC — was viable.

See more: https://ddless.com/blog/technical-journey-building-php-debugger

I got tired of dd() and built a visual PHP debugger that doesn't need Xdebug

Jefferson Silva — Tue, 03 Mar 2026 22:39:24 +0000

Hey everyone.

I've been a PHP dev for years and like most of us, I've been living between dd(), var_dump(), and that twice-a-year attempt to configure Xdebug that works for 3 days until Docker rebuilds and breaks everything.

After spending way too many hours debugging with echo where I shouldn't, I decided to build DDLess — a desktop app that does visual debugging for any PHP project without installing an extension, without IDE plugins, without Composer, and without changing a single line of code.

What it does

You open a project, set breakpoints by clicking on a line, send a request, and DDLess pauses right there. Variables, call stack, step in/out/over — all visual, the way it should be.

But it goes beyond just debugging:

Dumppoints — a visual dd(): you pick the line and expressions in the UI, without touching your code. It evaluates, displays the results, and terminates execution.
Task Runner — a REPL with full framework context. Write PHP, run it, see streaming output. With autocomplete for your project's classes, methods, and helpers.
Method Execution — pick any method from any class and test it directly, with auto-scaffolded parameters.
Proxy Mode — selectively intercepts browser requests without changing URLs or using Postman.
CLI Debug — debug artisan commands, PHPUnit, migrations, queue workers. Run .ddless/php-ddless 8001 artisan test and breakpoints just work.
Code Navigation — Ctrl+Click for go-to-definition, file search, and content search across your entire project.

Why it works everywhere

DDLess doesn't use sockets or PHP extensions. It instruments code at runtime via AST (nikic/PHP-Parser) and uses file-based communication. In practice, this means it works on Local, Docker, WSL, and remote SSH with zero extra configuration. If PHP runs there, DDLess debugs there.

Zero manual path mapping. Zero xdebug.client_host. Zero "it works on his machine but not mine."

Frameworks

Laravel, WordPress, Symfony, Drupal, CakePHP, Slim, or any PHP 7.4+ project. Laravel gets automatic bootstrap. For other frameworks, just point to the entry file and you're good.

Runs on

Windows, macOS (Intel and Apple Silicon), and Linux (AppImage, .deb, .rpm).

This is my solo project, built independently. I use it daily and it's stable.

If you want to try it: ddless.com

Any questions, feedback, or bugs — hit me up here or on Discord.

Your Database Already Has the Answers — You Just Need to Ask

Jefferson Silva — Mon, 09 Feb 2026 04:46:21 +0000

Every Laravel application sits on top of a database full of insights. How many users signed up this month? Which products are underperforming? What's the average order value by region? The data is right there, but getting to it usually means one of two things: writing raw SQL or building custom dashboards that take days to ship.

I built LaraGrep to close that gap — a Laravel package that lets you ask questions about your database in plain English and get real answers back.

The Problem Every Developer Knows

You're in a meeting. The client asks: "How many active subscriptions do we have that are expiring next month?" You know the data exists. You know which tables to join. But to answer that question right now, you'd need to open a terminal, write a query, run it, maybe fix a typo, run it again.

Now multiply that by every stakeholder who needs "just a quick number" from the database. Product managers, sales teams, founders — they all have questions, and the developer becomes the bottleneck.

Some teams build internal dashboards. That works for recurring questions, but not for the ad-hoc ones that come out of nowhere. And maintaining those dashboards is a cost that compounds over time.

What LaraGrep Actually Does

LaraGrep connects to your Laravel application, reads your database schema, and uses AI to translate natural language questions into safe, parameterized SQL queries. But the key difference from other text-to-SQL tools is that it doesn't just generate one query and hope for the best.

It uses an agent loop. The AI executes a query, sees the results, thinks about what it learned, and decides whether to run another query or provide the final answer. This means it can handle questions that require multiple steps — joining data across tables, filtering based on previous results, self-correcting when something unexpected comes back.

Ask "What's our top-selling product category in Q4 compared to Q3?" and the AI might run three or four queries behind the scenes: first to understand the schema, then to pull Q3 numbers, then Q4, then compare. You just see the final answer.

A Data Analyst That Knows Your Schema

Think of LaraGrep as a junior data analyst who has memorized your entire database structure. You describe your tables, columns, relationships, and even provide hints about what JSON columns contain. The AI uses all of that context to write accurate queries.

Table::make('orders')
    ->description('Customer orders with payment status.')
    ->columns([
        Column::id(),
        Column::bigInteger('user_id')->unsigned()->description('FK to users.id'),
        Column::decimal('total', 10, 2)->description('Order total in USD'),
        Column::enum('status', ['pending', 'paid', 'cancelled']),
        Column::json('metadata')
            ->template(['shipping_method' => 'express', 'coupon_code' => 'SAVE20']),
        Column::timestamp('created_at'),
    ])
    ->relationships([
        Relationship::belongsTo('users', 'user_id'),
    ])

The more context you provide, the better the answers get. Column descriptions, enum values, JSON templates — all of it helps the AI understand not just the structure, but the meaning behind your data.

For large databases, you don't even need to define everything manually. Set the schema mode to auto and LaraGrep reads directly from information_schema, pulling table and column comments as descriptions.

Real Use Cases

For client projects: Imagine delivering an admin panel where the client can type "Show me all users who placed more than 3 orders last month but haven't logged in this week" and get an instant answer. No custom report page. No Jira ticket. No waiting.

For your own SaaS: You're debugging a billing issue at 11pm. Instead of writing JOIN queries across five tables, you ask: "Which users on the Pro plan have a failed payment in the last 48 hours and an active subscription?" LaraGrep figures out the joins and filters for you.

For understanding your numbers: Early-stage founders who are technical enough to have a database but don't always have time to query it properly. "What's my MRR?" "What's the churn rate this quarter?" "How does signup-to-first-purchase time compare between organic and paid users?" These questions shouldn't require 20 minutes of SQL each time.

For generating reports: LaraGrep has a query export mode where the AI consolidates all its reasoning into a single optimized SELECT query and hands it back to you — no LIMIT, no memory constraints. You take that query and run it however you want: cursor() for streaming, chunk() for batch processing, pipe it into Laravel Excel. The AI does the thinking, you control the execution.

For recurring reports: The recipe system auto-saves every successful query chain. Found a question you'll ask every Monday? Replay the recipe with fresh data — the AI adjusts date parameters automatically. Wire it to a scheduled job and you have automated reporting without building a single dashboard.

Keep It Local with Ollama

Not every project can send database schemas to external APIs. Healthcare, finance, government contracts — there are legitimate reasons to keep everything on-premises.

LaraGrep works with Ollama out of the box. Point it to your local instance, pick a model, and every query stays on your machine. No data leaves your network. The setup is three environment variables:

LARAGREP_PROVIDER=openai
LARAGREP_API_KEY=ollama
LARAGREP_BASE_URL=http://localhost:11434/v1/chat/completions
LARAGREP_MODEL=qwen3-coder:30b

The trade-off is that local models are less capable than GPT-4o or Claude for complex multi-step reasoning. But for straightforward queries — counts, aggregations, filtered lookups — they work well enough. And for sensitive environments, "good enough locally" beats "perfect in the cloud" every time.

Security by Design

Letting AI write SQL sounds dangerous, and it should — if done carelessly. LaraGrep takes a strict approach:

Only SELECT queries are allowed. Any mutation attempt is rejected before it reaches the database. All values use parameterized bindings — the AI never interpolates user input into raw SQL. Every table reference is validated against the schema you defined — the AI can't query tables you haven't exposed. There's a configurable execution timeout that kills slow queries before they can lock your database. And the agent loop is capped at a maximum number of iterations to prevent runaway API costs.

This doesn't make it zero-risk. You're still exposing read access to data, so protecting the endpoint with authentication middleware is essential. But the attack surface is significantly smaller than giving someone a database GUI.

Getting Started

If you have a Laravel 10+ application and an API key (or Ollama), you can be running in under five minutes:

composer require behindsolution/laragrep
php artisan vendor:publish --tag=laragrep-config
php artisan migrate

Define your tables in the config, set your API key in .env, and send a POST request:

curl -X POST http://localhost/laragrep \
  -H "Content-Type: application/json" \
  -d '{"question": "How many users registered this week?"}'

That's it. The response comes back with a natural language summary and, optionally, the full debug trace showing every query the AI ran.

What This Means for Your Projects

The shift here isn't really about AI writing SQL. It's about making database knowledge accessible to anyone who can describe what they need in words. The developer still controls the schema, the security, the infrastructure. But the barrier to getting answers drops from "know SQL and the schema" to "know what you want to know."

For agencies delivering client projects, this is a feature that adds immediate value without weeks of dashboard development. For SaaS builders, it's a way to stay close to your data without context-switching into a SQL client every time. For teams with non-technical stakeholders, it's one less reason to interrupt the developer.

The data was always there. Now it's easier to reach.

LaraGrep is open source and available on GitHub:
github.com/behindSolution/laragrep

Stars, issues, and pull requests are welcome. If you're using it in a project, I'd love to hear about your experience.

Debugging Laravel Beyond Localhost

Jefferson Silva — Sat, 31 Jan 2026 04:37:33 +0000

Lessons learned from real environments

For years, my debugging workflow looked the same.

Something breaks.

I try to reproduce it locally.

I add logs.

I guess.

Sometimes it works. Most of the time, it doesn’t.

The more my Laravel projects moved to Docker, WSL, staging servers and remote environments, the more obvious one thing became:

Most bugs don’t happen on localhost.

This article is about what breaks when we rely too much on local debugging, and what changes when we start debugging real execution instead.

The debugging illusion

Local debugging gives us a sense of control.

Same machine.

Same IDE.

Same database snapshot.

But production and QA don’t look like that.

Different environment variables.

Different data.

Different timing.

Different infrastructure.

The bug you are chasing is rarely caused by “wrong syntax”.

It’s caused by state.

And state is almost always environment-dependent.

Why local debugging breaks down

Local debugging tools are great. Until they aren’t.

Here are the most common failure points I kept hitting:

PHP extensions that don’t work well with Docker or WSL
Network ports blocked or misconfigured
Debuggers tightly coupled to IDEs
Only one developer able to debug at a time
Debugging tied exclusively to HTTP requests

None of these are “tool bugs”.

They are assumptions baked into the workflow.

The assumption is simple:

If I can reproduce it locally, I can debug it.

But real-world bugs don’t respect that assumption.

Debugging real execution

At some point, I stopped asking:

“How do I reproduce this locally?”

And started asking:

“How do I inspect what is actually running?”

That shift changes everything.

Real execution means:

Real environment variables
Real data
Real filesystem
Real configuration
Real side effects

Instead of guessing, you observe.

Instead of reproducing, you inspect.

Debugging becomes less about stepping through lines and more about understanding state.

Executing methods instead of reproducing requests

Another realization came shortly after.

Most bugs don’t live in controllers.

They live in:

services
domain logic
jobs
listeners
helpers
edge-case conditionals

Yet we keep trying to debug them through HTTP requests.

Why?

HTTP is often the worst entry point for debugging:

authentication
middleware
CSRF
cookies
headers
external dependencies

So instead of reproducing requests, I started executing methods directly.

Run the service.

Pass the input.

Inspect the state.

Pause execution.

No browser.

No fake requests.

No infrastructure gymnastics.

Just code, running where it actually matters.

A different approach to debugging

These experiences led me to a different mental model:

Debug at runtime, not at the VM level
Observe execution, don’t simulate it
Isolate sessions per developer
Avoid network dependencies when possible
Treat HTTP as optional, not mandatory

The goal is not to replace existing tools, but to cover the gap they were never designed for.

Remote environments.

QA servers.

Production-safe inspection.

Multi-developer workflows.

What this unlocks

Once you stop relying on localhost as the source of truth, new possibilities open up:

Debug QA without changing infrastructure
Inspect production safely, with isolation and timeouts
Debug jobs and services without traffic
Let multiple developers debug the same server independently
Spend less time reproducing and more time understanding

Debugging stops being a fight against the environment.

It becomes a conversation with it.

Final thoughts

Debugging is not about tools.

It’s about truth.

The closer you are to the real execution, the fewer assumptions you need to make.

That insight eventually led me to build DDLess, a runtime execution debugger designed for real Laravel environments.

Not as a replacement for local tools, but as a complement when local debugging stops being enough.

If you’ve ever thought “this bug only happens outside my machine”, you already understand the problem.

The rest is just changing how you approach it.

https://ddless.com

Build Complete REST APIs in Minutes

Jefferson Silva — Thu, 15 Jan 2026 04:38:45 +0000

Every Laravel developer knows the drill: create a model, write a controller, define routes, add validation, implement filtering, pagination, sorting... rinse and repeat for every single entity in your application.

What if I told you there's a better way?

I've been working on Laravel Query Gate, a package that transforms how you build APIs. Instead of writing repetitive boilerplate code, you declare what you want — and Query Gate handles the rest.

Let me show you how I built a complete blog API with Posts, Comments, Categories, Tags, Authentication, Custom Actions, and API Versioning — all without writing a single controller.

The Problem We All Face

Here's what a typical Laravel API setup looks like:

// PostController.php - Just ONE of many controllers you'll write
class PostController extends Controller
{
    public function index(Request $request)
    {
        $query = Post::query();

        if ($request->has('status')) {
            $query->where('status', $request->status);
        }
        if ($request->has('category_id')) {
            $query->where('category_id', $request->category_id);
        }
        if ($request->has('author')) {
            $query->whereHas('author', fn($q) => $q->where('name', 'like', "%{$request->author}%"));
        }
        // ... 20 more filters

        if ($request->has('sort')) {
            // parsing logic...
        }

        return $query->paginate($request->per_page ?? 15);
    }

    public function store(Request $request)
    {
        $validated = $request->validate([
            'title' => 'required|string|max:255',
            'content' => 'required|string',
            // ... more rules
        ]);

        return Post::create($validated);
    }

    // update(), destroy(), show()... you get the idea
}

Now multiply this by every model in your application. It's exhausting.

The Query Gate Way

Here's the same functionality with Laravel Query Gate:

// app/Models/Post.php
class Post extends Model
{
    use HasQueryGate;

    public static function queryGate(): QueryGate
    {
        return QueryGate::make()
            ->alias('posts')
            ->middleware(['auth:sanctum'])
            ->filters([
                'status' => ['string', 'in:draft,published,archived'],
                'category_id' => 'integer',
                'author.name' => ['string', 'max:100'],
                'created_at' => 'date',
            ])
            ->allowedFilters([
                'status' => ['eq', 'in', 'neq'],
                'category_id' => ['eq', 'in'],
                'author.name' => ['like'],
                'created_at' => ['gte', 'lte', 'between'],
            ])
            ->select(['id', 'title', 'slug', 'status', 'created_at', 'author.name'])
            ->sorts(['created_at', 'title'])
            ->actions(fn ($actions) => $actions
                ->create(fn ($action) => $action
                    ->validations([
                        'title' => ['required', 'string', 'max:255'],
                        'content' => ['required', 'string'],
                    ])
                )
                ->update()
                ->delete()
            );
    }
}

That's it. No controller. No routes. No repetitive code.

Query Gate automatically gives you:

GET    /query/posts              → List with filters, sorting, pagination
GET    /query/posts/{id}         → Show single post
POST   /query/posts              → Create post
PATCH  /query/posts/{id}         → Update post
DELETE /query/posts/{id}         → Delete post

Real-World Example: A Complete Blog API

I built a complete example project to showcase what Query Gate can do. Here's what's included:

1. Advanced Filtering

Filter by any field with operators like eq, neq, like, in, between, gt, gte, lt, lte:

# Posts published in 2024
GET /query/posts?filter[published_at][between]=2024-01-01,2024-12-31

# Posts by specific tags
GET /query/posts?filter[tag_slugs][in]=laravel,php

# Posts with 1000+ views, sorted by popularity
GET /query/posts?filter[views_count][gte]=1000&sort=views_count:desc

2. Relationship Filtering

Query through relationships using dot notation:

# Posts by author name
GET /query/posts?filter[author.name][like]=John

# Comments on published posts
GET /query/comments?filter[post.status][eq]=published

3. Custom Actions

Need more than CRUD? Define custom actions:

// app/Actions/QueryGate/Posts/PublishPost.php
class PublishPost extends AbstractQueryGateAction
{
    public function action(): string
    {
        return 'publish';
    }

    public function handle($request, $model, array $payload)
    {
        $model->update([
            'status' => 'published',
            'published_at' => now(),
        ]);

        return ['message' => 'Post published!', 'post' => $model];
    }

    public function authorize($request, $model): ?bool
    {
        return $request->user()->can('update', $model);
    }
}

Now you have:

POST /query/posts/1/publish

The example includes actions for: Publish, Unpublish, Archive, Feature, Unfeature, Duplicate posts and Approve, Reject, Mark as Spam comments.

4. API Versioning (Yes, Built-In!)

Evolve your API without breaking existing clients:

QueryGate::make()
    ->version('2024-01-01', function (QueryGate $gate) {
        $gate->filters(['title' => 'string', 'status' => 'string'])
             ->select(['id', 'title', 'status']);
    })
    ->version('2025-01-01', function (QueryGate $gate) {
        $gate->filters([
            'title' => 'string',
            'status' => 'string',
            'views_count' => 'integer',  // New in 2025!
            'author.name' => 'string',   // New in 2025!
        ])
        ->select(['id', 'title', 'status', 'views_count', 'author.name']);
    });

Clients choose their version:

GET /query/posts -H "X-Query-Version: 2024-01-01"

And there's a changelog endpoint:

GET /query/posts/__changelog

5. Automatic OpenAPI Documentation

Query Gate generates OpenAPI/Swagger docs automatically:

GET /query/docs      → Interactive documentation UI
GET /query/docs.json → OpenAPI JSON spec

No manual documentation. It's always in sync with your code.

Quick Start

Want to try it? Here's how to get started:

Install the Package

composer require behindsolution/laravel-query-gate

Add the Trait to Your Model

use BehindSolution\LaravelQueryGate\Traits\HasQueryGate;
use BehindSolution\LaravelQueryGate\Support\QueryGate;

class Post extends Model
{
    use HasQueryGate;

    public static function queryGate(): QueryGate
    {
        return QueryGate::make()
            ->alias('posts')
            ->filters(['title' => 'string', 'status' => 'string'])
            ->allowedFilters(['title' => ['like'], 'status' => ['eq']])
            ->actions(fn ($a) => $a->create()->update()->delete());
    }
}

Register in Config

// config/query-gate.php
'models' => [
    App\Models\Post::class,
],

Done. You now have a fully functional REST API.

Try the Example Project

Clone the complete example to see everything in action:

git clone git@github.com:behindSolution/LQG-example.git
cd LQG-example
composer install
cp .env.example .env
php artisan key:generate
php artisan migrate --seed
php artisan serve

Import the included Postman collection and start exploring.

Why I Built This

I was tired of writing the same code over and over. Every project needed:

Filtering logic
Sorting logic
Pagination
Validation
Authorization checks
API versioning (if you're lucky)
Documentation (if you have time)

Query Gate handles all of this declaratively. You focus on your business logic, not boilerplate.

What's Next?

GitHub Repository - Star it if you find it useful!
Example Project - Full blog API demo
Documentation - Complete guide

Have questions or feedback? Drop a comment below or open an issue on GitHub. I'd love to hear how you're using Query Gate in your projects!

If this saved you some time, consider giving the repo a star. It helps more developers discover the project.

🔥 Laravel Query Gate v1.2.0 is AWESOME

Jefferson Silva — Tue, 06 Jan 2026 03:48:51 +0000

API versioning is one of those topics everyone talks about…
and almost everyone implements in a painful way.

Multiple controllers.
Duplicated logic.
Hidden conditionals.
Broken clients.

Laravel Query Gate v1.2.0 introduces a different approach:

Version your API behavior at the query layer.

No boilerplate.
No magic.
No surprises.

🎯 The Problem With Traditional API Versioning

Most APIs evolve like this:

You change filters

You remove fields

You add sorting

You break someone’s integration

Even when using /v1/users and /v2/users, the real problem remains:

👉 Query behavior changes are scattered across the codebase.

Laravel Query Gate v1.2.0 centralizes this.

🧠 The Key Idea

Clients define the version they want:

X-Query-Version: 2026-01-05

The same endpoint adapts its behavior safely.

GET /query/users

No duplicated controllers.
No branching logic in services.

🧾 Built-in Changelog (Yes, Really)

Every versioned query automatically exposes a changelog endpoint:

GET /query/users/__changelog

Example response:

{
  "model": "App\\Models\\User",
  "alias": "users",
  "default": "2026-01-06",
  "active": "2026-01-05",
  "versions": [
    {
      "version": "2026-01-05",
      "changes": []
    },
    {
      "version": "2026-01-06",
      "changes": [
        "Removed filter: created_at",
        "Removed operator: created_at.gte",
        "Removed operator: created_at.lte",
        "Removed operator: created_at.between",
        "Removed select: created_at",
        "Added sort: name",
        "Added sort: email",
        "Added sort: created_at"
      ]
    }
  ]
}

This means:

Instant API transparency

Easier debugging

Clear communication with frontend and integrations

🧩 The Code That Makes It Happen

Here’s a real example using Laravel Query Gate v1.2.0:

public static function queryGate(): QueryGate
{
    return QueryGate::make()
        ->alias('users')

        ->version('2026-01-05', function (QueryGate $qg) {
            return $qg->filters([
                'name' => 'string',
                'email' => 'email',
                'created_at' => 'date',
            ])
            ->allowedFilters([
                'name' => ['like'],
                'email' => ['eq', 'like'],
                'created_at' => ['gte', 'lte', 'between'],
            ])
            ->select(['id', 'name', 'email', 'created_at']);
        })

        ->version('2026-01-06', function (QueryGate $qg) {
            return $qg->filters([
                'name' => 'string',
                'email' => 'email',
            ])
            ->allowedFilters([
                'name' => ['like'],
                'email' => ['eq', 'like'],
            ])
            ->sorts(['name', 'email', 'created_at'])
            ->select(['id', 'name', 'email']);
        });
}

What changed between versions?

created_at filter removed

Operators removed safely

Sorting added

Select fields adjusted

Old clients keep working

New clients get improvements

💡 Why This Is Powerful

Laravel Query Gate v1.2.0 gives you:

Explicit API contracts per version

Safe evolution without fear

One source of truth for queries

Less human error

Cleaner codebases

It treats API evolution as a first-class concern, not an afterthought.

🌐 Learn More

This is just one of the features.

👉 https://laravelquerygate.com

If you care about:

Maintainable APIs

Predictable behavior

Laravel-native solutions

You’ll feel right at home.

Feedback, ideas, and real-world edge cases are always welcome 🚀

Stop Writing CRUD Controllers

Jefferson Silva — Sun, 28 Dec 2025 04:27:43 +0000

Building APIs shouldn't mean writing the same CRUD controllers over and over. Laravel Query Gate turns your Eloquent models into powerful, secure APIs through simple configuration.

The Problem

How many times have you written something like this?

class UserController extends Controller
{
    public function index(Request $request)
    {
        $query = User::query();

        // Filter by email
        if ($request->has('email')) {
            $query->where('email', 'like', '%' . $request->email . '%');
        }

        // Filter by creation date
        if ($request->has('created_after')) {
            $query->where('created_at', '>=', $request->created_after);
        }

        // Filter by status
        if ($request->has('status')) {
            $query->where('status', $request->status);
        }

        // Sort
        $sortBy = $request->get('sort_by', 'created_at');
        $sortOrder = $request->get('sort_order', 'desc');
        $query->orderBy($sortBy, $sortOrder);

        // Paginate
        return $query->paginate($request->get('per_page', 15));
    }
}

Now multiply that by every model in your application. Add validation. Add security checks. Add caching. Add eager loading for relations. The boilerplate grows exponentially.

The Solution

// config/query-gate.php

use BehindSolution\LaravelQueryGate\Support\QueryGate;

return [
    'models' => [
        App\Models\User::class => QueryGate::make()
            ->middleware(['auth:sanctum'])
            ->filters([
                'email' => 'email',
                'created_at' => 'date',
                'status' => 'in:active,inactive,pending',
            ])
            ->allowedFilters([
                'email' => ['like'],
                'created_at' => ['gte', 'lte'],
                'status' => ['eq'],
            ])
            ->cache(60),
    ],
];

That's it. Now you have a fully functional, secure API endpoint:

GET /query?model=App\Models\User
    &filter[email][like]=%@gmail.com
    &filter[created_at][gte]=2024-01-01
    &filter[status][eq]=active
    &sort=created_at:desc
    &per_page=50

Key Features

Alias

Keep the name short.

return [

    'models' => [
        App\Models\User::class => QueryGate::make()
            ->alias('users')
            ->middleware(['auth:sanctum'])
            ->filters([
                'email' => 'email',
                'created_at' => 'date',
                'status' => 'in:active,inactive,pending',
            ])
            ->allowedFilters([
                'email' => ['like'],
                'created_at' => ['gte', 'lte'],
                'status' => ['eq'],
            ])
            ->cache(60),
    ],
];

Expose pretty REST-like routes (e.g. /query/users, /query/users/{id}) in addition to the canonical query-string

🔍 Powerful Filtering

Support for multiple operators out of the box:

->filters([
    'price' => 'numeric',
    'title' => 'string',
    'published_at' => 'date',
])
->allowedFilters([
    'price' => ['eq', 'lt', 'lte', 'gt', 'gte', 'between'],
    'title' => ['like'],
    'published_at' => ['eq', 'between'],
])

Available operators: eq, neq, lt, lte, gt, gte, like, in, between

🔗 Relation Filtering with Dot Notation

Filter through relationships seamlessly:

->filters([
    'posts.title' => 'string',
    'posts.comments.author.name' => 'string',
])
->allowedFilters([
    'posts.title' => ['like'],
    'posts.comments.author.name' => ['eq'],
])

GET /query?model=App\Models\User
    &filter[posts.title][like]=%Laravel%
    &filter[posts.comments.author.name][eq]=John

🔒 Security First

Whitelist everything. No surprises.

->middleware(['auth:sanctum', 'throttle:60,1'])
->filters(['email' => 'email']) // Only these fields can be filtered
->allowedFilters(['email' => ['eq']]) // Only these operators allowed
->select(['id', 'name', 'email']) // Only these fields returned
->query(fn($q, $request) => 
    $q->where('tenant_id', $request->user()->tenant_id)
)

Integrate with Laravel Policies:

->policy('view') // Uses your existing policy
// or
->authorize(fn($request, $model) => 
    $request->user()->isAdmin() || 
    $model->user_id === $request->user()->id
)

⚡ Smart Caching

Cache responses automatically with intelligent invalidation:

->cache(60, 'users-index')

The cache key includes:

Model class
All filters
Sort parameters
Pagination settings
Authenticated user ID

Cache is automatically cleared after create, update, or delete operations.

🔧 Raw Filters for Complex Cases

Need custom logic? No problem:

->filters(['full_name' => 'string'])
->rawFilters([
    'full_name' => fn($builder, $operator, $value, $column) =>
        $builder->whereRaw(
            "CONCAT(first_name, ' ', last_name) LIKE ?",
            ["%{$value}%"]
        ),
])

You keep the validation and whitelisting, but control the query logic.

📝 Optional CRUD Operations

Enable create, update, and delete when needed:

->actions(fn($actions) => $actions
    ->create(fn($action) => $action
        ->validations([
            'name' => 'required|string|max:255',
            'email' => 'required|email|unique:users',
        ])
        ->policy('create')
    )
    ->update(fn($action) => $action
        ->validations([
            'name' => 'sometimes|string|max:255',
            'email' => 'sometimes|email|unique:users,email',
        ])
    )
    ->delete(fn($action) => $action
        ->authorize(fn($req, $model) => 
            $req->user()->isAdmin()
        )
    )
)

Endpoints:

POST   /query?model=App\Models\User          # Create
PATCH  /query/{id}?model=App\Models\User     # Update
DELETE /query/{id}?model=App\Models\User     # Delete

🎯 Flexible Pagination

Choose what fits your use case:

->paginationMode('cursor')  // For infinite scroll
->paginationMode('classic') // Standard page-based (default)
->paginationMode('none')    // Return everything

📊 Column Selection

Reduce payload size by selecting only needed fields:

->select(['id', 'name', 'email', 'posts.title'])

Primary and foreign keys are automatically included for proper relation hydration.

Real-World Examples

Multi-tenant SaaS

App\Models\Project::class => QueryGate::make()
    ->middleware(['auth:sanctum', 'tenant.isolate'])
    ->query(fn($q, $request) => 
        $q->where('tenant_id', $request->user()->tenant_id)
    )
    ->filters([
        'status' => 'in:planning,active,completed,archived',
        'created_at' => 'date',
        'members.user_id' => 'integer',
    ])
    ->allowedFilters([
        'status' => ['eq', 'in'],
        'created_at' => ['between'],
        'members.user_id' => ['eq'],
    ])
    ->cache(300)
    ->actions(fn($actions) => $actions
        ->create(fn($action) => $action
            ->validations([
                'name' => 'required|string|max:255',
                'description' => 'nullable|string',
            ])
            ->handle(function($request, $model, $payload) {
                $model->fill($payload);
                $model->tenant_id = $request->user()->tenant_id;
                $model->save();
                return $model;
            })
        )
        ->update()
        ->delete()
    ),

E-commerce Product Catalog

App\Models\Product::class => QueryGate::make()
    ->query(fn($q) => $q
        ->selectRaw('products.*, AVG(reviews.rating) as avg_rating')
        ->leftJoin('reviews', 'reviews.product_id', '=', 'products.id')
        ->groupBy('products.id')
    )
    ->filters([
        'category_id' => 'integer',
        'price' => 'numeric',
        'tags.slug' => 'string',
        'in_stock' => 'boolean',
    ])
    ->allowedFilters([
        'category_id' => ['eq', 'in'],
        'price' => ['between', 'lte', 'gte'],
        'tags.slug' => ['in'],
        'in_stock' => ['eq'],
    ])
    ->select(['id', 'name', 'price', 'avg_rating', 'image_url'])
    ->cache(600),

Analytics Dashboard

App\Models\Order::class => QueryGate::make()
    ->middleware(['auth:sanctum', 'role:admin'])
    ->query(fn($q) => $q
        ->selectRaw('
            DATE(created_at) as date,
            COUNT(*) as total_orders,
            SUM(total) as revenue,
            AVG(total) as average_order_value
        ')
        ->groupBy('date')
    )
    ->filters([
        'created_at' => 'date',
        'status' => 'in:pending,completed,cancelled,refunded',
    ])
    ->allowedFilters([
        'created_at' => ['between', 'gte', 'lte'],
        'status' => ['eq', 'in'],
    ])
    ->paginationMode('none')
    ->cache(1800, 'orders-analytics'),

Installation

composer require behindsolution/laravel-query-gate

Optionally publish the config:

php artisan vendor:publish --tag=query-gate-config

When to Use Query Gate

✅ Perfect for:

Admin dashboards
Internal tools
BI/Analytics integrations
Mobile app backends
Rapid prototyping
Reports and data exports

❌ Not ideal for:

Public APIs with complex business logic
Operations requiring multi-step workflows
Cases where you need fine-grained control over every query
GraphQL (use Laravel Lighthouse instead)

Security Best Practices

Always authenticate: Use ->middleware(['auth:sanctum'])
Whitelist explicitly: Only expose models you intend to
Restrict operators: Don't allow all operators on all fields
Validate inputs: Use ->filters() with validation rules
Apply rate limiting: Protect against abuse
Scope by tenant: Use ->query() for multi-tenant isolation
Use policies: Integrate with your existing authorization

// ✅ Good
->filters(['email' => 'email'])
->allowedFilters(['email' => ['eq']])
->middleware(['auth:sanctum', 'throttle:60,1'])

// ❌ Bad
->filters(['email' => 'string'])
->allowedFilters(['email' => ['eq', 'neq', 'like', 'in']]) // Too permissive
// No middleware!

Performance Considerations

Query Gate delegates to Laravel's Eloquent, so standard optimization practices apply:

Use eager loading in ->query() to avoid N+1:

   ->query(fn($q) => $q->with(['posts', 'comments']))

Add database indexes for filtered/sorted columns
Enable caching for expensive queries:

   ->cache(3600)

Limit pagination size:

   // config/query-gate.php
   'pagination' => [
       'per_page' => 25,
       'max_per_page' => 100,
   ],

Use cursor pagination for large datasets:

   ->paginationMode('cursor')

Comparison with Alternatives

Feature	Query Gate	Custom Controllers	GraphQL	API Platform
Setup Time	5 minutes	Hours	Days	Days
Laravel Native	✅	✅	❌	❌
Learning Curve	Low	None	High	High
Flexibility	High	Total	Medium	Medium
Auto Validation	✅	Manual	✅	✅
Caching	✅	Manual	❌	❌

FAQ

Q: Does this replace controllers?

A: No. Use Query Gate for standard CRUD + filtering. Create controllers for complex business logic.

Q: Is it production-ready?

A: Yes. It uses Laravel's core components (Eloquent, Validator, Policies, Cache). When configured properly, it's as secure as any Laravel API.

Q: Can I customize the query logic?

A: Absolutely. Use ->query(), ->rawFilters(), ->authorize(), and ->handle() callbacks for full control.

Q: How does it handle relationships?

A: Via dot notation in filters and select. Query Gate automatically handles joins and eager loading.

Q: What about multi-tenancy?

A: Use ->query() to scope by tenant or apply tenant isolation middleware.

Conclusion

Laravel Query Gate solves a specific problem: eliminating boilerplate for standard CRUD operations. It's not trying to replace controllers or be a full GraphQL alternative.

It's a tool that saves you time on the 80% of straightforward cases, while giving you complete escape hatches for the 20% that need custom logic.

Try it in your next Laravel project. Your future self will thank you for not writing another paginated, filtered, sorted CRUD controller.

Links:

Requirements:

PHP 8.2+
Laravel 9, 10, 11, or 12

Have you used Query Gate? Share your experience in the comments! Found a bug or have a feature request? Open an issue on GitHub.