DEV Community: Tuğrul Yıldırım

ERP’de herkes her şeyi görmesin: KOBİ için yetki matrisi

Tuğrul Yıldırım — Mon, 02 Nov 2026 09:32:20 +0000

ERP’de herkes her şeyi görmesin: KOBİ için yetki matrisi https://tugrulyildirim.com/erp-crm-yetki-matrisi-kobi/

Retry-Safe Queue Jobs in Laravel: ShouldBeUnique, WithoutOverlapping and Idempotency Keys

Tuğrul Yıldırım — Mon, 02 Nov 2026 07:00:02 +0000

A queue job that runs twice is not a rare edge case. It is the normal behaviour of every queue system you will ever use. Workers get killed during a deploy, a job times out halfway through an HTTP call, a user double-clicks "Send invoice", a scheduler fires while the previous run is still going. Laravel's queue will happily retry for you. The question is whether your job is safe to retry.

In business software the cost of getting this wrong is very concrete: two invoices sent to the same customer, stock decremented twice, a supplier receiving the same purchase order on two emails. This post walks through the toolkit I use to make Laravel jobs retry-safe: dispatching after commit, ShouldBeUnique, the WithoutOverlapping middleware, and an idempotency key that survives crashes.

The problem: "at least once" means "sometimes twice"

Consider a typical job: when an invoice is finalized, send it to an external e-invoicing provider and store the provider's reference.

// The naive version
class SendInvoiceToProvider implements ShouldQueue
{
    use Queueable;

    public function __construct(public Invoice $invoice) {}

    public function handle(): void
    {
        $response = Http::post('https://provider.example/api/invoices', [
            'number' => $this->invoice->number,
            'total' => $this->invoice->total_minor,
        ])->throw();

        $this->invoice->update(['provider_reference' => $response->json('id')]);
    }
}

There are at least four ways this sends the same invoice twice:

Dispatched twice. Two requests (a double-click, a retried HTTP request, an observer and a controller both dispatching) put two copies on the queue.
Processed concurrently. Two workers pick up two copies at the same time.
Retried after a partial success. The provider accepted the invoice, then the worker died (timeout, OOM, deploy) before update() ran. The retry posts again.
Dispatched before commit. The job is queued inside a database transaction, a worker picks it up before the commit, and it sees stale or missing data. The transaction rolls back, but the job has already run.

Each tool below closes one of these gaps. None of them closes all four alone.

Step 1: Dispatch after the transaction commits

If you dispatch inside DB::transaction(), a fast worker can process the job before the data it depends on is committed. Laravel lets you defer the dispatch until all open transactions have committed:

use Illuminate\Support\Facades\DB;

DB::transaction(function () use ($invoice) {
    $invoice->finalize();   // writes rows inside the transaction

    SendInvoiceToProvider::dispatch($invoice)->afterCommit();
});

You can also set after_commit to true on the queue connection in config/queue.php to make this the default. If the transaction rolls back, the job is never dispatched. That alone removes a whole class of "the job ran on data that never existed" bugs.

Step 2: Deduplicate dispatches with `ShouldBeUnique`

Implementing ShouldBeUnique makes Laravel acquire a cache lock keyed by uniqueId() when the job is dispatched. If the lock is already held, the new dispatch is silently ignored. The lock is released when the job completes or fails all its retry attempts.

namespace App\Jobs;

use App\Models\Invoice;
use Illuminate\Contracts\Queue\ShouldBeUnique;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Queue\Queueable;

class SendInvoiceToProvider implements ShouldQueue, ShouldBeUnique
{
    use Queueable;

    /** The number of times the job may be attempted. */
    public $tries = 5;

    /** Release the unique lock after 10 minutes even if the job never finished. */
    public $uniqueFor = 600;

    public function __construct(public Invoice $invoice) {}

    public function uniqueId(): string
    {
        return (string) $this->invoice->id;
    }

    // handle() comes in step 4
}

Two things to know:

Unique jobs need a cache driver that supports atomic locks (redis, memcached, dynamodb, database, file or array), and every server that dispatches must share the same cache. A file cache on three web servers gives you three separate locks.
If you want the lock released as soon as processing starts (so a new dispatch can queue up while the current one runs), implement ShouldBeUniqueUntilProcessing instead.

On Laravel 13 the documentation shows the same options as attributes, for example #[Tries(5)] and #[UniqueFor(600)] on the class. Use whichever style your version's docs show; the behaviour is the same.

Step 3: Serialize processing with `WithoutOverlapping`

ShouldBeUnique guards the dispatch. It does not help when two copies are already on the queue (for example, one was dispatched before you added the interface, or the unique lock expired). For that, use the WithoutOverlapping job middleware, which holds a lock while the job is running:

use Illuminate\Queue\Middleware\WithoutOverlapping;

/**
 * Get the middleware the job should pass through.
 *
 * @return array<int, object>
 */
public function middleware(): array
{
    return [
        (new WithoutOverlapping((string) $this->invoice->id))
            ->releaseAfter(30)   // an overlapping copy is retried in 30 seconds
            ->expireAfter(120),  // the lock expires even if the worker crashes
    ];
}

By default, an overlapping copy is released back onto the queue, and each release counts as an attempt. If the duplicate is useless, call dontRelease() to delete it instead. If two different job classes must not touch the same invoice at once, add ->shared() so the key applies across classes.

Set expireAfter() comfortably above the job's expected runtime. If it is shorter, a slow job loses its lock mid-run and a second copy can start.

Step 4: Make the side effect idempotent

Locks reduce concurrency. They do not fix gap number 3: the provider accepted the invoice, the worker died before saving the reference, and the retry posts again. For that, the job needs to recognise its own previous work. Two layers:

Layer A: check your own state first. If the reference is already stored, there is nothing to do.

Layer B: send a stable idempotency key. Many payment and invoicing APIs accept an Idempotency-Key (or similar) header and return the original result when they see the same key again. Derive it from your data, never from Str::uuid() inside handle(), because a new UUID per attempt defeats the purpose.

use Illuminate\Support\Facades\Http;

public function handle(): void
{
    $invoice = $this->invoice->fresh();

    // Layer A: already done on a previous attempt.
    if ($invoice->provider_reference !== null) {
        return;
    }

    // Layer B: same key on every attempt for this invoice.
    $key = "invoice-{$invoice->id}";

    $response = Http::withHeaders(['Idempotency-Key' => $key])
        ->timeout(15)
        ->post(config('services.einvoice.url').'/invoices', [
            'number' => $invoice->number,
            'total' => $invoice->total_minor,
            'currency' => $invoice->currency,
        ])
        ->throw();

    $invoice->update(['provider_reference' => $response->json('id')]);
}

fresh() matters: the serialized model in the payload is a snapshot from dispatch time, and a previous attempt may have updated the row since.

When the provider has no idempotency support

Then you need your own record of what was sent. A small table with a unique key turns "did I already do this?" into a database constraint instead of a hope:

// Migration excerpt
Schema::create('outbound_requests', function (Blueprint $table) {
    $table->id();
    $table->string('idempotency_key')->unique();
    $table->string('status');            // pending, sent
    $table->string('external_id')->nullable();
    $table->timestamps();
});

// Claim the key. Only one attempt can ever insert it.
$claimed = DB::table('outbound_requests')->insertOrIgnore([
    'idempotency_key' => $key,
    'status' => 'pending',
    'created_at' => now(),
    'updated_at' => now(),
]);

if ($claimed === 0) {
    // Someone already claimed it. If it is still "pending", a previous attempt
    // may have crashed mid-call: reconcile with the provider instead of re-sending.
    return;
}

Be honest about the limit here: without provider support there is always a small window between "the remote side accepted" and "I wrote that down". The unique key guarantees you never send twice blindly; the pending rows are the list you reconcile (for example, by looking the invoice up on the provider by its number) before sending again.

Here is the same claim logic as a runnable plain-PHP script with SQLite, simulating a worker that crashes after the remote call and a retry that follows:

<?php
// idempotency_demo.php: run with `php idempotency_demo.php`
$db = new PDO('sqlite::memory:');
$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$db->exec('CREATE TABLE outbound_requests (
    idempotency_key TEXT PRIMARY KEY,
    status TEXT NOT NULL
)');

$remoteCalls = 0;

function attempt(PDO $db, string $key, int &$remoteCalls, bool $crashAfterCall): string
{
    $stmt = $db->prepare('INSERT OR IGNORE INTO outbound_requests (idempotency_key, status) VALUES (?, ?)');
    $stmt->execute([$key, 'pending']);

    if ($stmt->rowCount() === 0) {
        $status = $db->query("SELECT status FROM outbound_requests WHERE idempotency_key = " . $db->quote($key))
            ->fetchColumn();
        return "skipped (already claimed, status: {$status})";
    }

    $remoteCalls++; // the side effect: the HTTP call to the provider

    if ($crashAfterCall) {
        return 'crashed after remote call';
    }

    $db->prepare('UPDATE outbound_requests SET status = ? WHERE idempotency_key = ?')
        ->execute(['sent', $key]);
    return 'sent';
}

echo 'Attempt 1: ', attempt($db, 'invoice-42', $remoteCalls, true), PHP_EOL;
echo 'Attempt 2: ', attempt($db, 'invoice-42', $remoteCalls, false), PHP_EOL;
echo 'Attempt 3: ', attempt($db, 'invoice-43', $remoteCalls, false), PHP_EOL;
echo "Remote calls: {$remoteCalls}", PHP_EOL;

Output:

Attempt 1: crashed after remote call
Attempt 2: skipped (already claimed, status: pending)
Attempt 3: sent
Remote calls: 2

Invoice 42 was sent exactly once despite the retry, and its pending status tells you it needs reconciliation rather than a second send.

Common pitfalls

Treating ShouldBeUnique as "exactly once". It only deduplicates dispatches while the lock is held. Retries of the same job, expired locks and copies already on the queue are not covered.
Unique jobs inside batches. The documentation is explicit: unique job constraints do not apply to jobs within batches.
A cache that isn't shared. Locks live in the cache. Per-server file or array caches mean per-server locks, which means no locks at all in a multi-server setup.
expireAfter() shorter than the job. The lock disappears mid-run and a duplicate starts. Measure your slow cases and leave margin.
Releases eat your attempts. Every WithoutOverlapping release counts as an attempt. With $tries = 3 and a busy key, a job can fail without ever running handle(). Raise $tries, use dontRelease(), or switch to retryUntil() with a time window.
Random idempotency keys. A key generated inside handle() changes on every attempt. Derive it from stable data (invoice ID, plus a version if the invoice can be legitimately re-sent after a correction).
Trusting the serialized model. Call fresh() (or re-query) before deciding whether work is already done.
Dispatching inside transactions. Use afterCommit() or the after_commit connection option, or a rolled-back invoice can still be sent.

Summary

Retry-safety in Laravel is layered, and each layer has a different job:

afterCommit() so the job never runs on uncommitted data.
ShouldBeUnique to drop duplicate dispatches.
WithoutOverlapping so two workers never process the same record at once.
An idempotency check plus a stable key so a retry after a partial success recognises its own work.

The first three are a few lines of configuration. The fourth is the one that actually protects your customers from a second invoice, and it is the one most codebases skip.

Which side effects in your app would hurt the most if a job ran twice, and how are you guarding them today?

Nafaka paketten çıktı, Meclis’in saati işlemeye devam ediyor

Tuğrul Yıldırım — Mon, 02 Nov 2026 06:32:19 +0000

Nafaka paketten çıktı, Meclis’in saati işlemeye devam ediyor https://tugrulyildirim.com/nafaka-yargi-paketi-meclis-takvim/

SPK’nın başkanı değişti, hesap verme usulü değişmedi

Tuğrul Yıldırım — Sun, 01 Nov 2026 08:02:21 +0000

SPK’nın başkanı değişti, hesap verme usulü değişmedi https://tugrulyildirim.com/spk-baskan-atama-meclis-hesap/

The Report That Was Off by Three Hours: Timezone Rules for Laravel Business Apps

Tuğrul Yıldırım — Sun, 01 Nov 2026 07:00:01 +0000

On the last Sunday of October, most of Europe moves its clocks back one hour. On 25 October 2026, "today" in Berlin was 25 hours long. If you run business software, that is a good moment to ask a slightly uncomfortable question: do your reports know what day it is?

Mine once didn't. A daily sales report was a few orders short every morning, and those orders showed up in the previous day's total instead. Nothing was lost; it was just in the wrong bucket. It took longer than I'd like to admit to see the pattern: every "missing" order had been placed between midnight and 03:00 local time. The server ran in UTC, the business ran in UTC+3, and the report query asked the database for "today" in UTC.

This post is the set of rules I've used since then. None of them are clever. They just stop the bug from coming back.

The problem: "today" depends on who is asking

The original query looked harmless:

$total = Order::whereDate('created_at', today())->sum('total');

There are two problems here.

today() uses the app timezone. A fresh Laravel 13 app has 'timezone' => 'UTC' in config/app.php. So today() means today in UTC, not today for the person reading the report.
whereDate() compares the stored UTC value's date part. An order placed at 01:30 in Istanbul is stored as 22:30 UTC on the previous day. Its UTC date is yesterday, so it is counted under yesterday.

There is also a performance cost: whereDate() wraps the column in a DATE() call, which usually stops MySQL from using a plain index on created_at.

Rule 1: Store instants in UTC, and say so twice

Keep app.timezone as UTC. Don't change it to your office's timezone "to make reports easier". It makes them easier until you get your first customer in another timezone, or until a timezone with daylight saving time is involved.

Then make the database session agree. Laravel's MySQL connector reads a timezone key from the connection config and runs SET time_zone=... when it connects:

// config/database.php (mysql connection excerpt)
'mysql' => [
    'driver' => 'mysql',
    // ...
    'timezone' => '+00:00',
],

Why bother? MySQL converts TIMESTAMP values from the session time zone to UTC on write and back on read, and it does not convert DATETIME at all. If the server's default timezone is not UTC and you use TIMESTAMP columns, NOW() and your stored values can quietly disagree with what PHP thinks. Pinning the session to +00:00 removes that variable. I use a numeric offset on purpose: named zones like 'UTC' only work if the MySQL timezone tables are loaded, and many servers don't load them.

Rule 2: Convert the boundaries, not the column

Instead of asking the database to turn every row into a local date, turn the local day into a UTC range once, in PHP, and compare the raw column against it.

// app/Support/LocalDayRange.php
namespace App\Support;

use Carbon\CarbonImmutable;

final class LocalDayRange
{
    /**
     * Turn a local calendar day into a half-open UTC range: [start, end).
     *
     * @return array{0: CarbonImmutable, 1: CarbonImmutable}
     */
    public static function for(string $date, string $timezone): array
    {
        $start = CarbonImmutable::createFromFormat('!Y-m-d', $date, $timezone)->startOfDay();
        $end = $start->addDay();

        return [$start->utc(), $end->utc()];
    }
}

Three details matter:

The date is parsed in the target timezone. 25 October in Europe/Istanbul starts at 2026-10-24 21:00:00 UTC.
The end is "start of the next day", not 23:59:59. That makes the range half-open, so nothing at 23:59:59.5 falls through a gap.
addDay() on a local time handles DST. In Europe/Berlin, the range for 25 October 2026 is 25 hours long, which is exactly right. Hardcoding +24 hours would be wrong twice a year.

The report query becomes:

use App\Models\Order;
use App\Support\LocalDayRange;

$day = $request->input('day', now($tz)->toDateString()); // validated as Y-m-d
[$from, $to] = LocalDayRange::for($day, $tz);

$total = Order::query()
    ->where('created_at', '>=', $from)
    ->where('created_at', '<', $to)
    ->sum('total');

Here $tz is the reporting timezone, which brings us to the next rule.

Rule 3: The timezone belongs to a person or a tenant, not the server

"Which timezone is the report in?" should have an answer stored in data. In a single-company app, that's one config value. In a multi-tenant app, it's a column on the tenant (and maybe an override on the user). Store IANA names like Europe/Istanbul, never offsets like +03:00, because offsets don't know about daylight saving rules.

// app/Models/Tenant.php (excerpt)
public function reportingTimezone(): string
{
    return $this->timezone ?: 'UTC';
}

Validate it when it's saved with Laravel's timezone validation rule, so a typo can't break every report for that tenant.

Rule 4: Group by local day in one place

A daily chart needs totals per local day. You have two reasonable options.

Small to medium result sets: fetch the rows for the whole range and group in PHP.

$perDay = Order::query()
    ->where('created_at', '>=', $from)
    ->where('created_at', '<', $to)
    ->get(['created_at', 'total'])
    ->groupBy(fn (Order $order) => $order->created_at->setTimezone($tz)->toDateString())
    ->map(fn ($orders) => $orders->sum('total'));

Large result sets: let the database do it with CONVERT_TZ(created_at, '+00:00', 'Europe/Istanbul'). This needs the MySQL timezone tables to be loaded (mysql_tzinfo_to_sql). Without them, named zones fail and you'll be tempted to use a fixed offset, which is only safe for zones that don't observe DST. If you can't guarantee the tables, compute one UTC range per day with LocalDayRange and run a single query with a CASE per bucket, or pre-aggregate into a daily summary table in a scheduled job.

Rule 5: Not every date is an instant

This is the lesson that saved the most bugs after the first one. Some values are moments in time: created_at, paid_at, shipped_at. Others are calendar dates: an invoice date, a due date, a delivery date promised to a customer, a birthday.

Calendar dates have no timezone. If you store a due date as a datetime at midnight and then convert it to the viewer's timezone, a viewer west of UTC sees it one day early. Store those as DATE columns and cast them as dates:

// app/Models/Invoice.php (excerpt)
protected function casts(): array
{
    return [
        'issued_on' => 'date:Y-m-d',
        'due_on' => 'date:Y-m-d',
        'paid_at' => 'datetime',
    ];
}

The :Y-m-d format matters more than it looks. A plain date cast still serializes to JSON as a full UTC timestamp at midnight (2026-10-25T00:00:00.000000Z), and a frontend that converts it to a western timezone shows the previous day. With date:Y-m-d, the API sends 2026-10-25 and there is nothing to convert.

The naming (_on for dates, _at for instants) is a small habit, but it makes the difference visible in code review.

Rule 6: Convert for display at the edge

Laravel serializes Eloquent dates with Carbon's toJSON(), which produces ISO-8601 strings in UTC, like 2026-10-24T22:30:00.000000Z. Let the API return that and convert only when rendering:

// resources/js/lib/formatLocal.js
export function formatLocal(isoUtc, timeZone, locale = 'en-GB') {
  return new Intl.DateTimeFormat(locale, {
    timeZone,
    dateStyle: 'medium',
    timeStyle: 'short',
  }).format(new Date(isoUtc));
}

// formatLocal('2026-10-24T22:30:00.000000Z', 'Europe/Istanbul') -> '25 Oct 2026, 01:30'
// formatLocal('2026-10-24T22:30:00.000000Z', 'UTC')             -> '24 Oct 2026, 22:30'

Pass the tenant's or user's timezone explicitly rather than relying on the browser's. A manager travelling abroad should still see the company's business day.

Common pitfalls

whereDate() on a UTC column for a local report. It compares UTC dates. Use a half-open UTC range instead.
Ending a day at 23:59:59. Use < start of next day. Fractional seconds exist.
Storing offsets instead of zone names. +03:00 is correct today and wrong the day a country changes its rules or a tenant moves.
Changing app.timezone to fix a report. You'll fix one report and break every timestamp you've already stored.
Scheduling reports in a DST zone. Laravel lets you call ->timezone('Europe/Berlin') on a scheduled task or set schedule_timezone, but the docs warn that during DST changes a task may run twice or not at all. For a daily report, scheduling in UTC and computing the local day inside the job is safer.
Testing only on a server in your own timezone. Write a test for a day with a DST change and for an order placed just after local midnight. Freezing time with $this->travelTo() makes these tests easy.

Summary

The report bug came from one assumption: that "today" is a property of the server. It isn't. It's a property of the reader.

Store instants in UTC, in PHP and in the database session.
Turn a local day into a half-open UTC range and compare the raw column.
Keep the reporting timezone as an IANA name in data.
Group by local day in one place, and know what your database needs to do it.
Keep calendar dates as dates, not midnight timestamps.
Convert for display at the edge, with an explicit timezone.

What's the strangest timezone bug you've shipped, and how long did it take you to notice?

Haftanın ekonomi notları: Dış açık nefes aldı, güven onarılmadı

Tuğrul Yıldırım — Sat, 31 Oct 2026 15:32:14 +0000

Haftanın ekonomi notları: Dış açık nefes aldı, güven onarılmadı https://tugrulyildirim.com/haftanin-ekonomi-notlari-31-ekim-2026/

Sınavsız müdürlüğe süre şartı geldi, mülakat yerinde duruyor

Tuğrul Yıldırım — Sat, 31 Oct 2026 08:02:23 +0000

Sınavsız müdürlüğe süre şartı geldi, mülakat yerinde duruyor https://tugrulyildirim.com/sinavsiz-mudurluk-uc-yil-sarti-sozlu-sinav/

Server-Driven Data Tables with Laravel, Inertia and React: Filters, Sorting and Pagination in the URL

Tuğrul Yıldırım — Sat, 31 Oct 2026 07:00:01 +0000

Every business app eventually grows a table that people live in: products, invoices, suppliers, open orders. The first version is easy. Load everything, render a <table>, maybe add a client-side filter. Then the table hits 40,000 rows, someone asks for "sort by stock, only active items, page 3", and a colleague wants to send that exact view to a manager as a link.

This post shows the pattern I use for server-driven data tables with Laravel, Inertia and React: the server does the filtering, sorting and pagination, and the browser URL is the single source of truth for the table's state.

The problem with client-side tables

Client-side tables break down in three predictable ways:

Data size. Shipping every row to the browser works until it doesn't. Memory use, slow first paint and huge JSON payloads all arrive at once.
Unshareable state. If the filters live only in React state, a refresh or a copied link throws them away.
Two sources of truth. The server knows the real data; the client holds a filtered copy. Totals, counts and "page 4 of 9" drift apart.

The fix is to keep the query on the server and treat the URL (/products?status=active&sort=price&direction=desc&page=2) as the table's state. Inertia makes this pleasant because a GET visit updates the URL and the page props in one step, without you writing an API layer.

Step 1: A controller that only trusts a whitelist

The controller validates every query parameter. This matters most for sorting: a sort column that goes straight from the query string into orderBy() is an injection risk, and even when it isn't, it lets users sort by unindexed columns you never meant to expose.

// app/Http/Controllers/ProductController.php
namespace App\Http\Controllers;

use App\Models\Product;
use Illuminate\Http\Request;
use Illuminate\Validation\Rule;
use Inertia\Inertia;
use Inertia\Response;

class ProductController extends Controller
{
    private const SORTABLE = ['name', 'sku', 'price', 'stock', 'updated_at'];

    public function index(Request $request): Response
    {
        $filters = $request->validate([
            'search' => ['nullable', 'string', 'max:100'],
            'status' => ['nullable', Rule::in(['active', 'archived'])],
            'sort' => ['nullable', Rule::in(self::SORTABLE)],
            'direction' => ['nullable', Rule::in(['asc', 'desc'])],
            'per_page' => ['nullable', 'integer', Rule::in([10, 25, 50])],
        ]);

        $sort = $filters['sort'] ?? 'updated_at';
        $direction = $filters['direction'] ?? 'desc';

        $products = Product::query()
            ->select(['id', 'name', 'sku', 'price', 'stock', 'status', 'updated_at'])
            ->when($filters['search'] ?? null, function ($query, string $search) {
                $query->where(function ($q) use ($search) {
                    $q->where('name', 'like', "%{$search}%")
                        ->orWhere('sku', 'like', "%{$search}%");
                });
            })
            ->when($filters['status'] ?? null, fn ($query, string $status) => $query->where('status', $status))
            ->orderBy($sort, $direction)
            ->orderBy('id', $direction) // stable tie-breaker
            ->paginate($filters['per_page'] ?? 25)
            ->withQueryString();

        return Inertia::render('Products/Index', [
            'products' => $products,
            'filters' => [
                'search' => $filters['search'] ?? '',
                'status' => $filters['status'] ?? '',
                'sort' => $sort,
                'direction' => $direction,
                'per_page' => (int) ($filters['per_page'] ?? 25),
            ],
        ]);
    }
}

A few details worth calling out:

Rule::in(self::SORTABLE) means the sort column is always one you chose.
The second orderBy('id', ...) is a tie-breaker. Without it, rows with the same price can swap places between pages, and users see the same product on page 2 and page 3.
withQueryString() appends the current query string to the paginator's URLs, so next_page_url keeps the active filters.
The page receives a normalized filters prop, so the frontend never has to guess defaults.

Step 2: One pure function for the next query

The trickiest bug in table UIs is forgetting to reset the page. A user is on page 7, types a search term, and gets an empty table because the filtered result only has two pages. I keep that rule in a tiny pure function, which makes it easy to test without a browser.

// resources/js/lib/tableQuery.js
const FILTER_KEYS = ['search', 'status', 'per_page'];

export function buildQuery(current, patch) {
  const next = { ...current, ...patch };

  // Any filter change invalidates the current page number.
  const filterChanged = FILTER_KEYS.some(
    (key) => key in patch && patch[key] !== current[key],
  );
  if (filterChanged) {
    delete next.page;
  }

  // Keep the URL clean: drop empty values.
  return Object.fromEntries(
    Object.entries(next).filter(
      ([, value]) => value !== '' && value !== null && value !== undefined,
    ),
  );
}

export function nextSort(current, column) {
  if (current.sort !== column) {
    return { sort: column, direction: 'asc' };
  }
  return { sort: column, direction: current.direction === 'asc' ? 'desc' : 'asc' };
}

And a quick test with Node's built-in assert module:

import assert from 'node:assert/strict';
import { buildQuery, nextSort } from './tableQuery.js';

const cur = { search: '', status: 'active', sort: 'name', direction: 'asc', per_page: 25, page: 4 };

// A new search drops the page number
assert.deepEqual(buildQuery(cur, { search: 'bolt' }),
  { search: 'bolt', status: 'active', sort: 'name', direction: 'asc', per_page: 25 });

// Paging keeps the filters
assert.equal(buildQuery(cur, { page: 5 }).page, 5);

// Clearing a filter removes it from the URL
assert.equal('status' in buildQuery(cur, { status: '' }), false);

// Clicking the active column flips the direction
assert.deepEqual(nextSort(cur, 'name'), { sort: 'name', direction: 'desc' });

Step 3: A small hook around `router.get`

Inertia's router.get(url, data, options) performs a GET visit and puts data in the query string. Four options make it feel like a local filter instead of a page load:

preserveState: true keeps component state, so the search input keeps its value while the user is typing.
preserveScroll: true stops the page from jumping to the top on every sort click.
replace: true replaces the current history entry, so typing "steel" doesn't create five Back-button steps.
only: ['products', 'filters'] is a partial reload: the server only needs to return the props that actually change.

// resources/js/hooks/useTableQuery.js
import { useEffect, useRef } from 'react';
import { router } from '@inertiajs/react';
import { buildQuery } from '@/lib/tableQuery';

export function useTableQuery(url, current) {
  const timer = useRef(null);

  useEffect(() => () => clearTimeout(timer.current), []);

  const visit = (patch) => {
    router.get(url, buildQuery(current, patch), {
      preserveState: true,
      preserveScroll: true,
      replace: true,
      only: ['products', 'filters'],
    });
  };

  const visitDebounced = (patch, delay = 300) => {
    clearTimeout(timer.current);
    timer.current = setTimeout(() => visit(patch), delay);
  };

  return { visit, visitDebounced };
}

The debounce is deliberately hand-rolled. It's ten lines, and it avoids pulling in a utility library for one function. The cleanup in useEffect cancels a pending visit if the user navigates away.

Step 4: The page component

// resources/js/Pages/Products/Index.jsx
import { useState } from 'react';
import { useTableQuery } from '@/hooks/useTableQuery';
import { nextSort } from '@/lib/tableQuery';

const COLUMNS = [
  { key: 'name', label: 'Name' },
  { key: 'sku', label: 'SKU' },
  { key: 'price', label: 'Price' },
  { key: 'stock', label: 'Stock' },
  { key: 'updated_at', label: 'Updated' },
];

export default function Index({ products, filters }) {
  const current = { ...filters, page: products.current_page };
  const { visit, visitDebounced } = useTableQuery('/products', current);
  const [search, setSearch] = useState(filters.search);

  const onSearch = (event) => {
    setSearch(event.target.value);
    visitDebounced({ search: event.target.value });
  };

  return (
    <div>
      <div className="toolbar">
        <input type="search" value={search} onChange={onSearch} placeholder="Search name or SKU" />
        <select value={filters.status} onChange={(e) => visit({ status: e.target.value })}>
          <option value="">All statuses</option>
          <option value="active">Active</option>
          <option value="archived">Archived</option>
        </select>
      </div>

      <table>
        <thead>
          <tr>
            {COLUMNS.map((col) => (
              <th key={col.key}>
                <button type="button" onClick={() => visit(nextSort(filters, col.key))}>
                  {col.label}
                  {filters.sort === col.key && (filters.direction === 'asc' ? ' ▲' : ' ▼')}
                </button>
              </th>
            ))}
          </tr>
        </thead>
        <tbody>
          {products.data.length === 0 && (
            <tr>
              <td colSpan={COLUMNS.length}>No products match these filters.</td>
            </tr>
          )}
          {products.data.map((p) => (
            <tr key={p.id}>
              <td>{p.name}</td>
              <td>{p.sku}</td>
              <td>{p.price}</td>
              <td>{p.stock}</td>
              <td>{new Date(p.updated_at).toLocaleDateString()}</td>
            </tr>
          ))}
        </tbody>
      </table>

      <nav className="pager">
        <button
          type="button"
          disabled={!products.prev_page_url}
          onClick={() => visit({ page: products.current_page - 1 })}
        >
          Previous
        </button>
        <span>
          Page {products.current_page} of {products.last_page} ({products.total} results)
        </span>
        <button
          type="button"
          disabled={!products.next_page_url}
          onClick={() => visit({ page: products.current_page + 1 })}
        >
          Next
        </button>
      </nav>
    </div>
  );
}

Notice that only the search box has local state. Everything else (status, sort, page) is read straight from props, which come from the URL. That is the whole point: refresh the page, paste the link in a chat, or hit Back, and the table shows exactly the same view.

Pagination uses current_page, last_page, total, prev_page_url and next_page_url, which are all part of Laravel's paginator JSON. If you prefer numbered page links, the paginator's URLs already include your filters thanks to withQueryString().

Common pitfalls

Sorting by user input. Never pass $request->sort to orderBy() without a whitelist. Validation with Rule::in() is the cheapest guard you'll ever write.
Forgetting the tie-breaker. Sorting by a non-unique column without a secondary id sort gives unstable pagination. Users notice duplicates and "missing" rows long before you do.
Not resetting the page. Any filter change should drop page. Put the rule in one function and test it.
preserveState off for search. Without it, component state is reset on every visit, so the search box's local value is overwritten while the user is still typing.
History spam. Without replace: true, every debounced keystroke becomes a history entry and the Back button becomes useless.
LIKE '%term%' on big tables. A leading wildcard can't use a normal B-tree index. It's fine for a few thousand rows; for larger tables, consider full-text search or a dedicated search engine before users feel the slowdown.
Leaking columns. paginate() serializes whatever you selected. Use an explicit select() (or an API resource) so internal fields don't end up in page props.

Summary

A server-driven table in Laravel and Inertia comes down to a few habits:

The URL is the state. Filters, sort and page live in the query string.
The controller validates everything and whitelists sortable columns.
A pure buildQuery() function owns the rules, like resetting the page on filter changes, and is unit-tested.
A small hook wraps router.get with preserveState, preserveScroll, replace and only.
Stable sorting with an id tie-breaker keeps pagination honest.

No data-grid library, no separate API, and every view of your table is a link you can share.

What do you reach for first when a table outgrows the client: a hand-rolled pattern like this, or a full data-grid package?

Turizm geliri rekor, turist sayısı düşüşte: Fiyatla büyümenin sınırı

Tuğrul Yıldırım — Fri, 30 Oct 2026 15:32:12 +0000

Turizm geliri rekor, turist sayısı düşüşte: Fiyatla büyümenin sınırı https://tugrulyildirim.com/turizm-geliri-rekor-turist-azaliyor/

Gemini 4 Carbon: En güçlü model önce savunmacıya gidiyor

Tuğrul Yıldırım — Fri, 30 Oct 2026 09:32:19 +0000

Gemini 4 Carbon: En güçlü model önce savunmacıya gidiyor https://tugrulyildirim.com/gemini-4-carbon-kademeli-erisim-fiyat/

Building an RFQ Approval Matrix in Laravel Without Hardcoded Thresholds

Tuğrul Yıldırım — Fri, 30 Oct 2026 07:00:01 +0000

Every procurement tool starts with a simple rule: "purchases over 10,000 need a manager's approval." Six months later the rule looks like this: over 10,000 needs the department head, over 50,000 also needs finance, IT hardware always needs the IT lead, and anything in a foreign currency is compared after conversion. If those rules live in if statements inside a controller, every policy change becomes a deploy.

This post walks through how I model an approval matrix for RFQs (requests for quotation) in Laravel so the rules live in data, the workflow lives in one service, and two people clicking "Approve" at the same second cannot corrupt the state.

The problem

An RFQ in a typical business app goes through a few stages: a requester drafts it, suppliers send quotes, the requester picks a winning quote, and then the selection has to be approved before it turns into a purchase order.

The approval part is where things usually break:

Thresholds are hardcoded. Changing 10,000 to 15,000 needs a developer.
Steps are implicit. Nobody can answer "who still needs to approve RFQ #482?" without reading code.
Concurrency is ignored. Two approvers act at once, both read "1 step left", and the RFQ is marked approved twice or skips a step.
Re-quotes are forgotten. A supplier revises the price upward after approval, and the old approval silently still counts.

Let's fix all four.

Step 1: Store rules as rows, not code

An approval rule says: for RFQs in this amount range (and optionally this category), this role must approve, at this step.

// database/migrations/2026_10_23_000001_create_approval_rules_table.php
use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

return new class extends Migration
{
    public function up(): void
    {
        Schema::create('approval_rules', function (Blueprint $table) {
            $table->id();
            $table->string('category')->nullable();          // null = any category
            $table->unsignedBigInteger('min_amount');         // minor units, base currency
            $table->unsignedBigInteger('max_amount')->nullable(); // null = no upper limit
            $table->string('approver_role');
            $table->unsignedTinyInteger('step');
            $table->boolean('active')->default(true);
            $table->timestamps();
        });

        Schema::create('rfq_approvals', function (Blueprint $table) {
            $table->id();
            $table->foreignId('rfq_id')->constrained()->cascadeOnDelete();
            $table->unsignedTinyInteger('step');
            $table->string('approver_role');
            $table->foreignId('approved_by')->nullable()->constrained('users');
            $table->timestamp('approved_at')->nullable();
            $table->unsignedBigInteger('approved_amount')->nullable();
            $table->timestamps();

            $table->unique(['rfq_id', 'step', 'approver_role']);
        });
    }
};

Two decisions matter here:

Amounts are integers in minor units (cents, kuruş). Floats and money do not mix; 0.1 + 0.2 is not 0.3.
Amounts are in a base currency. When an RFQ is submitted, convert the selected quote once and store both the converted amount and the rate you used. Approvals are evaluated against that snapshot, not against today's exchange rate.

Step 2: Make the status explicit with a backed enum

PHP 8.1+ backed enums plus Eloquent's enum casting give you a status that cannot hold a typo.

// app/Enums/RfqStatus.php
namespace App\Enums;

enum RfqStatus: string
{
    case Draft = 'draft';
    case Quoting = 'quoting';
    case PendingApproval = 'pending_approval';
    case Approved = 'approved';
    case Rejected = 'rejected';

    /** @return array<int, self> */
    public function allowedTransitions(): array
    {
        return match ($this) {
            self::Draft => [self::Quoting],
            self::Quoting => [self::PendingApproval],
            self::PendingApproval => [self::Approved, self::Rejected, self::Quoting],
            self::Approved, self::Rejected => [],
        };
    }

    public function canTransitionTo(self $next): bool
    {
        return in_array($next, $this->allowedTransitions(), true);
    }
}

// app/Models/Rfq.php (excerpt)
use App\Enums\RfqStatus;

protected function casts(): array
{
    return [
        'status' => RfqStatus::class,
    ];
}

Notice PendingApproval → Quoting. That is the re-quote path, and it matters later.

Step 3: Resolve the required steps in one place

The matrix resolver takes an amount and a category and returns the steps that apply. Keeping it pure (no database writes, no HTTP) makes it trivial to test.

// app/Services/ApprovalMatrix.php
namespace App\Services;

use App\Models\ApprovalRule;
use Illuminate\Support\Collection;

class ApprovalMatrix
{
    /**
     * @return Collection<int, ApprovalRule>
     */
    public function requiredSteps(int $amount, ?string $category): Collection
    {
        return ApprovalRule::query()
            ->where('active', true)
            ->where('min_amount', '<=', $amount)
            ->where(fn ($q) => $q->whereNull('max_amount')->orWhere('max_amount', '>=', $amount))
            ->where(fn ($q) => $q->whereNull('category')->orWhere('category', $category))
            ->orderBy('step')
            ->get()
            ->unique(fn (ApprovalRule $rule) => $rule->step.'|'.$rule->approver_role)
            ->values();
    }
}

When the requester submits the selected quote, you materialize those rules into rfq_approvals rows. From that moment on, the RFQ carries its own checklist. If someone edits the rules table tomorrow, RFQs already in flight keep the rules they were submitted under, which is what auditors expect.

// app/Actions/SubmitRfqForApproval.php
namespace App\Actions;

use App\Enums\RfqStatus;
use App\Models\Rfq;
use App\Services\ApprovalMatrix;
use DomainException;
use Illuminate\Support\Facades\DB;

class SubmitRfqForApproval
{
    public function __construct(private ApprovalMatrix $matrix) {}

    public function handle(Rfq $rfq): void
    {
        DB::transaction(function () use ($rfq) {
            $rfq = Rfq::whereKey($rfq->getKey())->lockForUpdate()->firstOrFail();

            if (! $rfq->status->canTransitionTo(RfqStatus::PendingApproval)) {
                throw new DomainException("RFQ {$rfq->id} cannot be submitted from {$rfq->status->value}.");
            }

            $steps = $this->matrix->requiredSteps($rfq->base_amount, $rfq->category);

            $rfq->approvals()->delete(); // clean slate on re-submission

            foreach ($steps as $rule) {
                $rfq->approvals()->create([
                    'step' => $rule->step,
                    'approver_role' => $rule->approver_role,
                ]);
            }

            $rfq->status = $steps->isEmpty() ? RfqStatus::Approved : RfqStatus::PendingApproval;
            $rfq->save();
        });
    }
}

Step 4: Approve without race conditions

This is the part most implementations get wrong. The approval action must:

lock the RFQ row so two approvals are serialized,
only allow the lowest open step to be approved,
block the requester from approving their own RFQ,
record the amount that was approved,
flip the RFQ to Approved only when no open steps remain.

// app/Actions/ApproveRfqStep.php
namespace App\Actions;

use App\Enums\RfqStatus;
use App\Models\Rfq;
use App\Models\User;
use DomainException;
use Illuminate\Support\Facades\DB;

class ApproveRfqStep
{
    public function handle(Rfq $rfq, User $approver): void
    {
        DB::transaction(function () use ($rfq, $approver) {
            $rfq = Rfq::whereKey($rfq->getKey())->lockForUpdate()->firstOrFail();

            if ($rfq->status !== RfqStatus::PendingApproval) {
                throw new DomainException('RFQ is not waiting for approval.');
            }

            if ($rfq->requested_by === $approver->id) {
                throw new DomainException('Requesters cannot approve their own RFQ.');
            }

            $open = $rfq->approvals()->whereNull('approved_at')->orderBy('step')->get();
            $currentStep = $open->min('step');

            $slot = $open
                ->where('step', $currentStep)
                ->first(fn ($a) => $approver->hasRole($a->approver_role));

            if ($slot === null) {
                throw new DomainException('You have no open approval on the current step.');
            }

            $slot->update([
                'approved_by' => $approver->id,
                'approved_at' => now(),
                'approved_amount' => $rfq->base_amount,
            ]);

            if ($open->count() === 1) {
                $rfq->status = RfqStatus::Approved;
                $rfq->save();
            }
        }, attempts: 3);
    }
}

lockForUpdate() inside DB::transaction() is the documented Laravel approach for pessimistic locking: the second approver's query waits until the first transaction commits, then reads the updated state. The attempts: 3 argument tells Laravel to retry the closure if the database reports a deadlock.

hasRole() here stands for whatever your authorization layer provides (a package, a roles relation, or a Gate). Keep the check inside the transaction so it is evaluated against the locked state.

Step 5: Invalidate approvals on re-quote

If the winning supplier revises their price, the approvals are no longer valid for the new number. The simplest safe rule: any change to the selected quote's amount sends the RFQ back to Quoting, and re-submission rebuilds the checklist (that is why SubmitRfqForApproval deletes old approval rows).

// app/Observers/QuoteObserver.php (excerpt)
public function updated(Quote $quote): void
{
    $rfq = $quote->rfq;

    if ($quote->wasChanged('amount')) {
        if ($rfq->selected_quote_id === $quote->id
            && $rfq->status === RfqStatus::PendingApproval) {
            $rfq->status = RfqStatus::Quoting;
            $rfq->save();
        }
    }
}

Because approved_amount is stored on each approval row, you also get a cheap audit check: an approved RFQ whose base_amount differs from any approved_amount is a red flag worth alerting on.

Common pitfalls

Overlapping ranges. If one rule covers 0–10,000 and another 10,000–50,000 for the same role, an RFQ of exactly 10,000 matches both. Pick one convention (for example, max_amount is inclusive and the next range starts at max_amount + 1) and validate rules on save so ranges for the same role and category never overlap.
Using lockForUpdate() outside a transaction. The lock is released as soon as the statement finishes, so it protects nothing. Always wrap it.
Evaluating the matrix at approval time. Rules change. Materialize them at submission and approve against the snapshot.
Converting currency on the fly. Store the rate used at submission. Otherwise an RFQ can cross a threshold overnight because the exchange rate moved.
Letting the UI decide the step. The client can send "approve step 2" while step 1 is open. The server must pick the lowest open step itself.
Self-approval through a second role. A requester who is also a department head should still not approve their own RFQ. Check identity, not just role.

Summary

A maintainable RFQ approval flow comes down to four ideas:

Rules are data (approval_rules), not if statements.
Each RFQ gets a materialized checklist (rfq_approvals) at submission time.
Approvals run inside a transaction with a row lock, always against the lowest open step.
A price change resets the flow, and every approval records the amount it approved.

None of this needs a workflow engine. An enum, two tables, and two small action classes cover most procurement teams I have seen.

How do you handle approval rules in your apps: rows in a table, a config file, or a full workflow engine?

15 yaş sınırı doğru, belirtecin kaydı kurala bağlanmalı

Tuğrul Yıldırım — Fri, 30 Oct 2026 06:32:15 +0000

15 yaş sınırı doğru, belirtecin kaydı kurala bağlanmalı https://tugrulyildirim.com/yas-dogrulama-belirtec-kayit-kurali/

DEV Community: Tuğrul Yıldırım

ERP’de herkes her şeyi görmesin: KOBİ için yetki matrisi

Retry-Safe Queue Jobs in Laravel: ShouldBeUnique, WithoutOverlapping and Idempotency Keys

The problem: "at least once" means "sometimes twice"

Step 1: Dispatch after the transaction commits

Step 2: Deduplicate dispatches with ShouldBeUnique

Step 3: Serialize processing with WithoutOverlapping

Step 4: Make the side effect idempotent

When the provider has no idempotency support

Common pitfalls

Summary

Nafaka paketten çıktı, Meclis’in saati işlemeye devam ediyor

SPK’nın başkanı değişti, hesap verme usulü değişmedi

The Report That Was Off by Three Hours: Timezone Rules for Laravel Business Apps

The problem: "today" depends on who is asking

Rule 1: Store instants in UTC, and say so twice

Rule 2: Convert the boundaries, not the column

Rule 3: The timezone belongs to a person or a tenant, not the server

Rule 4: Group by local day in one place

Rule 5: Not every date is an instant

Rule 6: Convert for display at the edge

Common pitfalls

Summary

Haftanın ekonomi notları: Dış açık nefes aldı, güven onarılmadı

Sınavsız müdürlüğe süre şartı geldi, mülakat yerinde duruyor

Server-Driven Data Tables with Laravel, Inertia and React: Filters, Sorting and Pagination in the URL

The problem with client-side tables

Step 1: A controller that only trusts a whitelist

Step 2: One pure function for the next query

Step 3: A small hook around router.get

Step 4: The page component

Common pitfalls

Summary

Turizm geliri rekor, turist sayısı düşüşte: Fiyatla büyümenin sınırı

Gemini 4 Carbon: En güçlü model önce savunmacıya gidiyor

Building an RFQ Approval Matrix in Laravel Without Hardcoded Thresholds

The problem

Step 1: Store rules as rows, not code

Step 2: Make the status explicit with a backed enum

Step 3: Resolve the required steps in one place

Step 4: Approve without race conditions

Step 5: Invalidate approvals on re-quote

Common pitfalls

Summary

15 yaş sınırı doğru, belirtecin kaydı kurala bağlanmalı

Step 2: Deduplicate dispatches with `ShouldBeUnique`

Step 3: Serialize processing with `WithoutOverlapping`

Step 3: A small hook around `router.get`