DEV Community: A0mineTV

One interface, eight job sources: designing a connector pipeline that doesn't fight you

A0mineTV — Tue, 15 Sep 2026 13:36:12 +0000

I built DevRadar as a personal dashboard to track developer job offers across the French market. Nothing fancy — a Laravel app, a few dozen offers a day, one user (me). But it pulls from eight very different sources: a government API with OAuth2, two HTML pages I scrape by hand, a couple of official REST APIs, an RSS feed, and — most recently — a mailbox full of job-alert emails.

Those sources have almost nothing in common at the transport level. What they do have in common is what happens after the data arrives: turn it into a job offer, figure out if we've seen it before, save it, keep a record of the sync. That's the part worth designing well, because it's the part every future source has to go through.

This post walks through how that pipeline is built — two files, SynchronizeSourceAction and PersistOfferAction, plus the small set of types that connect them — and why the design paid for itself the day I added a source that isn't even a network request.

The shape of the problem

Here's the connector list as it stands in docs/job-sources.md:

Source	Transport
France Travail	REST API, OAuth2 client credentials
Adzuna	REST API, app key
Free-Work	HTML listing page → JSON-LD on detail pages
HelloWork	HTML "métier" pages → JSON-LD + an inline analytics blob
WeLoveDevs	HTML page with a full Algolia search response embedded server-side
We Work Remotely	RSS
Jooble	IMAP — reading the user's own job-alert emails

Every one of these needs different auth, different pagination, different error modes, different parsing. A malformed HTML page, an empty RSS feed, and an IMAP connection timeout are not remotely the same failure — but by the time the data reaches persistence, none of that should matter anymore.

So the pipeline draws one hard line: a connector's only job is to produce a list of NormalizedOffer DTOs. Everything before that line is source-specific and lives in app/Sync/Connectors/. Everything after it is source-agnostic and lives in app/Actions/Sync/.

The contract

interface Connector
{
    public function driver(): string;

    /** @throws InvalidConnectorConfigurationException */
    public function validateConfiguration(Source $source): void;

    /** @throws ConnectorFetchException */
    public function fetch(Source $source, ?string $cursor = null): ConnectorPage;
}

That's the whole interface. fetch() returns a ConnectorPage:

final class ConnectorPage
{
    public function __construct(
        public readonly array $offers,       // list<NormalizedOffer>
        public readonly ?string $nextCursor = null,
        public readonly bool $hasMorePages = false,
    ) {}
}

A source with no real pagination (most of the HTML ones) just always returns hasMorePages: false. A source with cursor-based pagination (the APIs) hands back whatever token means "continue from here" — a page number, an offset, an API-specific cursor string. The orchestrator doesn't care which; it just keeps asking until hasMorePages is false.

And every offer that comes out the other end, regardless of source, is the same shape:

final class NormalizedOffer
{
    public function __construct(
        public readonly ?string $externalId = null,
        public readonly ?string $title = null,
        public readonly ?string $company = null,
        public readonly ?string $location = null,
        public readonly ?string $contractType = null,   // raw string — mapped later
        public readonly ?string $remoteStatus = null,    // raw string — mapped later
        public readonly ?int $salaryMinimum = null,
        public readonly array $technologies = [],
        public readonly ?CarbonImmutable $publishedAt = null,
        public readonly array $rawPayload = [],
        public readonly array $evidence = [],
        public readonly ?float $extractionConfidence = null,
        // ...
    ) {}
}

Two things worth calling out, because they're the two rules that keep eight connectors from turning into eight slightly-different dialects:

Every field is nullable, and a connector must leave it null when the source doesn't provide it — never guess. If Jooble's alert email doesn't give me a job description, description stays null. It doesn't get padded with the title, it doesn't get inferred from the company name. An empty field is honest data; a guessed field is a bug waiting to surface three steps downstream.

Contract type and remote policy are passed as raw strings, not enums. A connector doesn't decide whether "CDI" or "temps plein" means ContractType::Cdi — it just hands over whatever text the source gave it, and a shared mapper does the classification:

final class OfferFieldMapper
{
    public static function mapContractType(?string $raw): ?ContractType
    {
        $needle = self::normalize($raw); // fold accents, lowercase, collapse whitespace

        return match (true) {
            str_contains($needle, 'cdi'), str_contains($needle, 'temps plein') => ContractType::Cdi,
            str_contains($needle, 'freelance'), str_contains($needle, 'independant') => ContractType::Freelance,
            str_contains($needle, 'alternance'), str_contains($needle, 'apprentissage') => ContractType::Alternance,
            // ...
            default => null,
        };
    }
}

This one function is why an HTML connector scraping French badges ("✅ CDI") and a REST API returning employmentType: FULL_TIME both end up with the same ContractType::Cdi — one vocabulary, one place it's defined, zero connectors reimplementing it.

The orchestrator: `SynchronizeSourceAction`

This is the part that runs a sync from start to finish, and it's deliberately boring:

final class SynchronizeSourceAction
{
    public function execute(Source $source): SyncRun
    {
        $lock = Cache::lock("sync:source:{$source->id}", 600);
        if (! $lock->get()) {
            throw new SourceSyncInProgressException(/* ... */);
        }

        try {
            return $this->synchronize($source);
        } finally {
            $lock->release();
        }
    }

    private function synchronize(Source $source): SyncRun
    {
        $connector = $this->registry->resolve($source);
        $connector->validateConfiguration($source);

        $cursor = null;
        $seenOfferIds = [];

        do {
            $page = $connector->fetch($source, $cursor);

            foreach ($page->offers as $dto) {
                $persisted = $this->persistOffer->execute($source, $dto);
                $seenOfferIds[] = $persisted->offerId;
            }

            $cursor = $page->nextCursor;
        } while ($page->hasMorePages && $cursor !== null);

        $this->expireStaleOffers($source, $seenOfferIds);
        // ...record a SyncRun with stats, return it
    }
}

Three decisions here are doing more work than the line count suggests:

A per-source lock, not a global one. Two syncs of the same source can't overlap (no point double-fetching the same French Travail search), but syncing eight sources in parallel is completely fine, because they never touch each other's lock key.

The Connector is resolved from a registry keyed by a driver string stored on the Source row, not hardcoded per source. Adding source #9 means writing a class and adding one line to config/connectors.php — nothing about SynchronizeSourceAction changes, ever.

Stale-offer expiry is a side effect of "what did we see this run," not a separate job. Every offer ID that came back from persistOffer->execute() goes into $seenOfferIds. After the loop, anything this source owns that's still marked New but wasn't in that set gets flipped to Expired. No offer is ever deleted — a posting that's gone from the source just stops being active, and if it comes back next run, PersistOfferAction un-expires it automatically. This assumes a connector returns its complete current listing every run, which is true for all eight sources today; a delta-only API would need a different reconciliation strategy, and that's written down as a known limitation rather than quietly assumed away.

The interesting part: `PersistOfferAction`

Deduplication across eight independently-scraped sources is the part that could have turned into a mess, so it's worth showing the actual decision tree. OfferDeduplicator::findMatch() checks four signals, in order of how much they can be trusted:

// Level 1 — same source, same external id → definitely the same offer
$offer = Offer::where('source_id', $source->id)->where('external_id', $externalId)->first();
if ($offer) return new OfferMatch($offer, strong: true);

// Level 2 — identical canonical URL, any source → definitely the same offer
$offer = Offer::where('canonical_url', $canonicalUrl)->first();
if ($offer) return new OfferMatch($offer, strong: true);

// Level 3 — same content fingerprint (title+company+description hash) → *probably*
$offer = Offer::where('content_hash', $contentHash)->first();
if ($offer) return new OfferMatch($offer, strong: false);

// Level 4 — same title+company(+location) → *probably*
// ...

The strong flag is the whole trick. Levels 1 and 2 are exact evidence — the same job board can't hand you two different external IDs for one posting, and two sources publishing the identical canonical URL are, by construction, the same listing. Those get merged: the existing row is updated in place.

Levels 3 and 4 are signals, not proof. A title/company/location match could easily be two different postings for the same role at the same company, published a week apart. So a non-strong match never merges automatically — it creates a new offer row and tags it possible_duplicate_of for manual review. I'd rather show a false-positive "possible duplicate" once in a while than silently collapse two distinct job postings into one and lose data.

From there, PersistOfferAction branches into exactly three outcomes:

No match → create. Straightforward insert, technologies attached, done.
Strong match, same source owns it → update. Title, salary, description, everything gets refreshed. If the offer had expired and reappeared in the feed, its status flips back to New — but a manual decision (favorited, archived, ignored) is never touched by an automated sync.
Strong match, a different source owns it → enrich, don't overwrite. This is the one that surprised me the most when I first wrote it. If Adzuna and Free-Work both list the same posting and Free-Work saw it first, Adzuna's copy doesn't overwrite Free-Work's data — it only fills in fields Free-Work left null. The owning source's data always wins; a later source can only patch gaps, never clobber.

private function enrichForeignOffer(Offer $offer, NormalizedOffer $dto): void
{
    $gaps = array_filter([
        'company' => $dto->company,
        'salary_min' => $dto->salaryMinimum,
        'location' => $dto->location,
        // ...
    ], fn ($value) => $value !== null);

    foreach ($gaps as $attribute => $value) {
        if ($offer->{$attribute} === null) {
            $offer->{$attribute} = $value;
        }
    }

    $offer->save();
}

Where it got tested for real: adding a source that isn't a network request

Every connector I described above does the same thing at the transport level: send an HTTP request, get a response, parse it. Then I wanted to add Jooble — a French job aggregator — as a source. The catch: their site sits behind a Cloudflare bot challenge on every page (including robots.txt-adjacent ones), and their terms of service explicitly prohibit automated crawlers. Their official API exists but is out of scope for how I wanted to use it here.

What Jooble does do is email me job alerts, because I subscribed to one like anyone would. So instead of an HTTP connector, I wrote one that reads a mailbox over IMAP:

final class JoobleEmailConnector implements Connector
{
    public function __construct(
        private readonly MailboxContract $mailbox,
        private readonly JoobleEmailParser $parser,
    ) {}

    public function fetch(Source $source, ?string $cursor = null): ConnectorPage
    {
        $messages = $this->mailbox->fetchUnseenMessages(
            config('connectors.jooble_email.max_messages_per_sync'),
            JoobleEmailParser::SENDER_DOMAIN,
        );

        $offers = [];
        foreach ($messages as $message) {
            if (! $this->parser->supports($message)) {
                continue; // not a Jooble email — leave it unread for another parser
            }

            $offers = [...$offers, ...$this->parser->parse($message)];
            $this->mailbox->markProcessed($message);
        }

        return new ConnectorPage(offers: $offers, nextCursor: null, hasMorePages: false);
    }
}

This is still just a Connector. SynchronizeSourceAction doesn't know or care that fetch() opened an IMAP session instead of an HTTP one. PersistOfferAction doesn't know or care that the NormalizedOffers it's deduplicating came from parsing <span class="tag"> badges in an HTML email instead of a JSON-LD block. The entire sync pipeline — locking, pagination, stale-offer expiry, the four-level dedup, junior/senior classification — is exactly as much code as it was before this source existed: zero new lines.

The IMAP "unread flag" turned out to be a nice fit for the cursor concept too — a message only gets flagged \Seen once it's been successfully parsed, so "what's new since last time" falls out of the mailbox itself instead of needing a persisted cursor. (I did get this wrong on the first pass: fetching "the first N unread messages" without filtering by sender first meant a mailbox with 30,000 unread emails buried the ~450 Jooble ones completely. The fix was filtering server-side, over IMAP, before applying the limit — a good reminder that "unread" and "relevant" are not the same predicate, and testing against realistic mailbox contents rather than a couple of fixtures would have caught it sooner.)

What I'd tell someone building this from scratch

Draw the abstraction boundary at the data, not the transport. "Fetch and parse" is where sources genuinely differ; "decide if this is a new offer" is where they don't. Put the interface exactly on that seam.
Nullable-by-default DTOs make "we don't know" a real, representable state, instead of a temptation to guess. It costs you some ?string noise; it saves you from a parser inventing data three months later when nobody remembers it did.
Not all duplicate signals deserve the same trust, and conflating them is how you either merge two different jobs into one or spam yourself with false duplicates. Give strong evidence the power to merge and weak evidence only the power to flag.
The real test of an abstraction is adding something that doesn't fit the mold you designed it around. For me that was a mailbox instead of an HTTP client. If your interface survives that with zero changes to the orchestrator, it was drawn in the right place.

Structuring a Laravel Project with Repositories and Services (Without Over-Engineering)

A0mineTV — Mon, 06 Apr 2026 14:40:03 +0000

A while ago, I wrote about using repositories and services in Laravel.

At the time, the goal was simple: keep controllers cleaner and move logic to dedicated layers.

I still agree with that idea.

But with more experience, I would structure that article differently today.

Because in Laravel, there is always a risk when talking about architecture:

we can improve code organization, but we can also over-engineer very quickly.

Laravel already gives us a lot out of the box:

Eloquent
Form Requests
API Resources
Route model binding
Events and jobs
A powerful service container

So the real question is not:

“Should I always use repositories and services?”

It is:

“At what point do these layers actually make my code easier to maintain ?”

That is the angle of this rewritten article.

I want to show a more practical version of the repository + service approach:

controllers for HTTP concerns
services for business rules and orchestration
repositories for data access only when that logic becomes worth isolating

Why I would revisit the original approach

A lot of repository pattern tutorials in Laravel follow the same structure:

a generic BaseRepository
CRUD methods like find, create, update, delete
a service that mostly forwards calls to the repository
a controller that becomes a little cleaner

At first glance, that seems fine.

But after building more real-world features, I think there is one important nuance:

if a repository is only a thin wrapper around Eloquent, it often adds indirection more than value.

And if the service layer only forwards method calls one by one, it is not really a business layer either.

That does not mean repositories and services are bad.

It means they become useful when they have a clear responsibility.

That is the version I would recommend today.

When this structure is actually useful

I would not add repositories and services to every small Laravel CRUD app.

For a very simple feature, using Eloquent directly in a controller can be acceptable, especially early on.

This structure becomes much more useful when:

query logic is reused in several places
business rules start growing
writes involve multiple actions or side effects
controllers are getting too large
you want better testability around domain logic
you want to separate “how data is stored” from “what the app should do”

So this is not about turning every Laravel project into enterprise architecture.

It is about introducing structure when it starts paying for itself.

The main issue with generic BaseRepository examples

In my opinion, the biggest weakness in many examples is the generic BaseRepository.

You often see something like this:

interface BaseRepositoryInterface
{
    public function getAll();
    public function findById($id);
    public function create(array $attributes);
    public function update($id, array $attributes);
    public function delete($id);
}

And then a base implementation shared by every model.

The problem is that this often ends up duplicating what Eloquent already does very well.

Even worse, the abstraction starts leaking quickly:

sooner or later you need custom queries
then you add model-specific methods
then the “generic” abstraction stops being generic anyway

So instead of starting from a generic repository, I now prefer starting from a feature-oriented repository.

That means the interface should reflect real application needs, not just CRUD verbs.

A more practical Laravel structure

For a medium-sized Laravel app, I like something close to this:

app/
├── Http/
│   ├── Controllers/
│   │   └── Api/
│   │       └── PostController.php
│   ├── Requests/
│   │   ├── StorePostRequest.php
│   │   └── UpdatePostRequest.php
│   └── Resources/
│       └── PostResource.php
├── Models/
│   └── Post.php
├── Repositories/
│   ├── Contracts/
│   │   └── PostRepositoryInterface.php
│   └── EloquentPostRepository.php
├── Services/
│   └── PostService.php
└── Providers/
    └── AppServiceProvider.php

This keeps each responsibility clear without creating too many layers.

Step 1: create a repository contract around the feature

Instead of a generic base repository, let’s define a contract that reflects what the feature actually needs.

<?php

declare(strict_types=1);

namespace App\\Repositories\\Contracts;

use App\\Models\\Post;
use Illuminate\\Contracts\\Pagination\\LengthAwarePaginator;

interface PostRepositoryInterface
{
    public function paginatePublished(int $perPage = 15): LengthAwarePaginator;

    public function findById(int $id): ?Post;

    public function create(array $attributes): Post;

    public function update(Post $post, array $attributes): Post;

    public function delete(Post $post): bool;
}

A few details are intentional here:

findById() is clearer than a very generic find()
update() receives a Post instance, not only an id
delete() also receives the model instance, which fits Eloquent better

This is already more expressive than a generic CRUD shell.

Step 2: implement the repository with Eloquent

<?php

declare(strict_types=1);

namespace App\\Repositories;

use App\\Models\\Post;
use App\\Repositories\\Contracts\\PostRepositoryInterface;
use Illuminate\\Contracts\\Pagination\\LengthAwarePaginator;

final class EloquentPostRepository implements PostRepositoryInterface
{
    public function paginatePublished(int $perPage = 15): LengthAwarePaginator
    {
        return Post::query()
            ->where('is_published', true)
            ->latest()
            ->paginate($perPage);
    }

    public function findById(int $id): ?Post
    {
        return Post::query()->find($id);
    }

    public function create(array $attributes): Post
    {
        return Post::query()->create($attributes);
    }

    public function update(Post $post, array $attributes): Post
    {
        $post->update($attributes);

        return $post->refresh();
    }

    public function delete(Post $post): bool
    {
        return (bool) $post->delete();
    }
}

This repository stays simple, but it already has real value:

query logic is centralized
data access is kept out of controllers
the contract can be mocked in service tests
implementation details can evolve later without touching other layers

Step 3: put real business logic in the service layer

This is the part where I changed my mind the most over time.

I no longer think a service should exist just to forward calls to the repository.

If a service does not make decisions, orchestrate actions, or apply business rules, it may not be worth having.

Here is a more useful service:

<?php

declare(strict_types=1);

namespace App\\Services;

use App\\Models\\Post;
use App\\Repositories\\Contracts\\PostRepositoryInterface;
use Illuminate\\Contracts\\Pagination\\LengthAwarePaginator;
use Illuminate\\Support\\Facades\\DB;
use Illuminate\\Support\\Str;

final class PostService
{
    public function __construct(
        private readonly PostRepositoryInterface $posts,
    ) {
    }

    public function listPublished(int $perPage = 15): LengthAwarePaginator
    {
        return $this->posts->paginatePublished($perPage);
    }

    public function create(array $data): Post
    {
        return DB::transaction(function () use ($data): Post {
            $payload = [
                'title' => $data['title'],
                'content' => $data['content'],
                'slug' => Str::slug($data['title']),
                'is_published' => $data['is_published'] ?? false,
            ];

            return $this->posts->create($payload);
        });
    }

    public function update(Post $post, array $data): Post
    {
        return DB::transaction(function () use ($post, $data): Post {
            $payload = [
                'title' => $data['title'],
                'content' => $data['content'],
                'is_published' => $data['is_published'] ?? $post->is_published,
            ];

            if ($post->title !== $data['title']) {
                $payload['slug'] = Str::slug($data['title']);
            }

            return $this->posts->update($post, $payload);
        });
    }

    public function delete(Post $post): bool
    {
        return $this->posts->delete($post);
    }
}

Now the service has a real purpose:

preparing the payload
generating the slug
centralizing write rules
wrapping write operations in transactions

That is the type of service layer I find useful in Laravel.

Step 4: move validation to Form Requests

If you want thinner controllers, moving validation out of them is one of the easiest wins.

<?php

declare(strict_types=1);

namespace App\\Http\\Requests;

use Illuminate\\Foundation\\Http\\FormRequest;

final class StorePostRequest extends FormRequest
{
    public function authorize(): bool
    {
        return true;
    }

    public function rules(): array
    {
        return [
            'title' => ['required', 'string', 'max:255'],
            'content' => ['required', 'string'],
            'is_published' => ['sometimes', 'boolean'],
        ];
    }
}

And for updates, I would usually create a dedicated UpdatePostRequest.

That keeps each action explicit and prevents “one giant request class” from growing over time.

Step 5: use API Resources for response formatting

When building JSON APIs, I also prefer keeping response transformation out of controllers.

<?php

declare(strict_types=1);

namespace App\\Http\\Resources;

use Illuminate\\Http\\Request;
use Illuminate\\Http\\Resources\\Json\\JsonResource;

final class PostResource extends JsonResource
{
    public function toArray(Request $request): array
    {
        return [
            'id' => $this->id,
            'title' => $this->title,
            'slug' => $this->slug,
            'content' => $this->content,
            'is_published' => $this->is_published,
            'created_at' => $this->created_at,
        ];
    }
}

That becomes especially useful when:

your API grows
fields need conditional exposure
you want stable response formatting
you want to avoid repeating transformation logic everywhere

Step 6: keep the controller focused on HTTP

At this point, the controller becomes much easier to read.

<?php

declare(strict_types=1);

namespace App\\Http\\Controllers\\Api;

use App\\Http\\Controllers\\Controller;
use App\\Http\\Requests\\StorePostRequest;
use App\\Http\\Resources\\PostResource;
use App\\Models\\Post;
use App\\Services\\PostService;
use Illuminate\\Http\\JsonResponse;
use Illuminate\\Http\\Request;
use Illuminate\\Http\\Resources\\Json\\AnonymousResourceCollection;

final class PostController extends Controller
{
    public function __construct(
        private readonly PostService $postService,
    ) {
    }

    public function index(Request $request): AnonymousResourceCollection
    {
        $perPage = (int) $request->integer('per_page', 15);

        return PostResource::collection(
            $this->postService->listPublished($perPage)
        );
    }

    public function store(StorePostRequest $request): PostResource
    {
        $post = $this->postService->create($request->validated());

        return new PostResource($post);
    }

    public function show(Post $post): PostResource
    {
        return new PostResource($post);
    }

    public function destroy(Post $post): JsonResponse
    {
        $this->postService->delete($post);

        return response()->json([
            'message' => 'Post deleted successfully.',
        ]);
    }
}

This is the kind of controller I like seeing in Laravel projects.

It reads almost like a checklist:

validate the request
call the service
return the response

No heavy query logic.
No business rules scattered in actions.
No response formatting noise.

Step 7: bind the repository in the service container

Now we bind the interface to the implementation.

<?php

declare(strict_types=1);

namespace App\\Providers;

use App\\Repositories\\Contracts\\PostRepositoryInterface;
use App\\Repositories\\EloquentPostRepository;
use Illuminate\\Support\\ServiceProvider;

final class AppServiceProvider extends ServiceProvider
{
    public function register(): void
    {
        $this->app->bind(PostRepositoryInterface::class, EloquentPostRepository::class);
    }
}

This is one of the reasons the pattern becomes interesting:

you code against a contract, while Laravel resolves the concrete implementation for you.

That makes later changes easier, such as:

replacing the implementation
decorating it with caching
mocking it in tests

What is improved compared to the older version

Here is what I would consider a real improvement over the more classic repository/service article style.

1. The repository is not generic for the sake of being generic

The repository is tied to a feature and exposes meaningful methods.

That makes the abstraction easier to justify.

2. The service contains actual business logic

It is not just a pass-through layer.

It prepares payloads, manages transactions, and centralizes behavior.

3. The controller is smaller for the right reasons

Not because logic disappeared into random files, but because each concern moved to the right place.

4. The code becomes easier to test

You can:

feature test the controller
unit test the service with a mocked repository
integration test the repository against the database

That testing split feels much more natural.

When I would not use repositories and services

I think this part is just as important.

I would probably avoid this structure when:

the feature is tiny
it is a quick prototype
Eloquent already expresses the logic clearly enough
there is no meaningful business logic yet
abstraction would only create extra files and extra indirection

Laravel is already expressive.

Sometimes the cleanest code is simply a small controller using Eloquent responsibly.

That is why I now see repositories and services as tools, not defaults.

Final thoughts

I still think repositories and services can improve a Laravel codebase a lot.

But today, I would frame it differently:

the goal is not to “add architecture”.

The goal is to make responsibilities obvious.

A good balance often looks like this:

controllers handle HTTP
Form Requests handle validation
services handle business rules and orchestration
repositories handle data access when it is worth isolating
Resources shape API responses

That is usually enough structure to keep a Laravel application clean without making it unnecessarily complex.

And honestly, that is the sweet spot I try to aim for now.

How I Built a Support Ticket MCP Server in Laravel

A0mineTV — Tue, 31 Mar 2026 18:57:32 +0000

Model Context Protocol is much easier to understand when it is attached to a real workflow.

In my Laravel project, I wanted a support-focused MCP server that could do three concrete things:

create a support ticket
read a ticket from a resource URI
generate a polished summary that is ready to send to a customer or teammate

Instead of building a generic demo, I kept the scope narrow and useful. The result is a local support MCP server powered by laravel/mcp, with one tool, one resource, and one prompt working together as a small support system.

Why this is a good MCP use case

A lot of MCP examples stop at "here is a tool that returns some JSON." That is fine for learning the API, but it does not show why the protocol is interesting.

Support workflows are a better fit because they combine three different kinds of interaction:

an action that changes state,
a resource that can be fetched again later,
a prompt that turns raw operational data into something a human can actually use.

That maps cleanly to MCP:

Tool: create the ticket.
Resource: fetch the ticket by identifier.
Prompt: transform the ticket into a professional summary.

This separation is what I like most about the approach. The AI client does not need custom knowledge about my Laravel app. It only needs to know which MCP capabilities are available.

Registering the server in Laravel

The first step in my project was registering a local MCP server in routes/ai.php:

use App\Mcp\Servers\SupportServer;
use Laravel\Mcp\Facades\Mcp;

Mcp::local('support', SupportServer::class);

That gives the app a dedicated MCP entry point for support operations. I also have a separate CRM server in the same project, which keeps responsibilities isolated instead of pushing every AI capability into one giant surface area.

Defining the support server

The server itself is intentionally small. Its job is to compose capabilities, not to hold business logic. In app/Mcp/Servers/SupportServer.php, I register the three pieces that make the workflow useful:

class SupportServer extends Server
{
    protected array $tools = [
        CreateTicketTool::class,
    ];

    protected array $resources = [
        TicketResource::class,
    ];

    protected array $prompts = [
        SummarizeTicketPrompt::class,
    ];
}

That structure is one of the reasons Laravel feels comfortable here. The framework already encourages small classes with clear responsibilities, and laravel/mcp fits that style well.

The ticket creation tool

The first capability I needed was a way for an AI client to create a support ticket safely.

In app/Mcp/Tools/CreateTicketTool.php, the tool validates three inputs:

title
description
priority

It then creates the ticket and returns a structured response with the fields an agent actually needs next:

return Response::structured([
    'id' => $ticket->id,
    'title' => $ticket->title,
    'status' => $ticket->status,
    'priority' => $ticket->priority,
]);

This is an important detail. I do not want the tool to return a blob of unstructured text when the next step may depend on the new ticket ID. MCP tools are much more useful when they return predictable data that another step can consume immediately.

I also defined the schema explicitly. That gives the client a machine-readable contract instead of forcing it to guess the arguments:

public function schema(JsonSchema $schema): array
{
    return [
        'title' => $schema->string()->required(),
        'description' => $schema->string()->required(),
        'priority' => $schema->string()
            ->enum(['low', 'medium', 'high'])
            ->default('medium'),
    ];
}

For support workflows, this matters a lot. Validation rules are not just a backend concern anymore. They become part of the interface between your Laravel app and the AI client.

The ticket resource

Creating a ticket is only half of the story. Once the ticket exists, an agent should be able to retrieve it again without calling a mutation tool.

That is where the resource comes in. In app/Mcp/Resources/TicketResource.php, the resource receives a ticket identifier, loads the record, and returns a readable text representation:

return Response::text(
    "Ticket #{$ticket->id}\n".
    "Titre: {$ticket->title}\n".
    "Statut: {$ticket->status}\n".
    "Priorité: {$ticket->priority}\n\n".
    "Description:\n{$ticket->description}"
);

I like this pattern because it makes the ticket easy to reuse in multiple contexts:

an assistant can read it before answering a user
another prompt can summarize it
a human can inspect the output without decoding JSON

This is a small design choice, but it makes the system more composable. A tool changes state. A resource exposes state. Keeping those responsibilities separate leads to cleaner MCP surfaces.

The prompt that turns raw data into a ready-to-send summary

The third piece is the one that makes the demo feel like a real support workflow rather than a CRUD exercise.

In app/Mcp/Prompts/SummarizeTicketPrompt.php, I created a prompt that takes:

a tone
the raw ticket_text

The prompt then instructs the model to return a structured support summary covering:

the problem
the impact
the suggested priority
the next action.

Here is the core idea:

return [
    Response::text(
        "You are a support assistant. Summarize the ticket below in a {$tone} tone. ".
        "Return: problem, impact, suggested priority, next action."
    )->asAssistant(),
    Response::text($ticket_text),
];

This is the part many teams skip. They expose data, but they do not shape the final output. In support, the final wording matters:

internal teams may want concise operational summaries
customer-facing teams may want a more professional tone
some situations need a friendlier message without losing the technical facts.

Packaging that as an MCP prompt means the formatting logic is reusable instead of being reinvented in every client.

Why I like this architecture

What I ended up with is not a huge system. It is a very small one. That is exactly why it works well.

Each MCP primitive has a clear role:

the tool creates the record,
the resource exposes the record,
the prompt transforms the record into communication.

That separation makes the project easier to extend. If I want to go further, I already know the next logical steps:

add a tool to update ticket status,
expose a resource for recent tickets,
create prompts for escalation notes or customer replies,
connect the same support server to external AI clients.

Laravel gives me the application structure, validation, and persistence patterns I already trust. MCP adds a clean interface layer on top of that.

Final thoughts

The main lesson from this project is that MCP becomes much more compelling when you model a real workflow instead of isolated demo commands.

In my Laravel app, the support server is useful because it does three connected things well:

it creates a ticket with validated input,
it lets the client read that ticket back as a resource,
it provides a prompt that converts raw ticket data into a professional summary.

That is enough to move from "AI can call my backend" to "AI can participate in a support flow with clear boundaries."

If you are experimenting with laravel/mcp, I would strongly recommend starting with a narrow domain like support, sales handoff, onboarding, or incident triage. Pick one workflow, then model it with one tool, one resource, and one prompt. You will learn much more than you would from a generic demo.

If I keep iterating on this project, the next step will be turning this support server into a fuller ticket operations layer with richer resources and multi-step support actions. But even in its current form, it already shows why Laravel and MCP fit together so naturally.

PHP 8.5: The Changes That Really Matter in Everyday Development

A0mineTV — Wed, 25 Mar 2026 19:09:06 +0000

PHP 8.5 brings a solid mix of language improvements, practical extension updates, and deprecations worth cleaning up before PHP 9.0.

It is not a flashy release built around one massive headline feature. Instead, it improves day-to-day developer experience in a lot of useful places: cleaner data transformations, better URL handling, nicer debugging, a few welcome standard library additions, and a clearer path away from old legacy patterns.

In this article, I want to focus on what actually matters when writing and maintaining PHP code: what you can start using right away, what deserves attention during migration, and which changes are most useful in real-world projects.

The pipe operator makes transformations easier to read

One of the most visible additions in PHP 8.5 is the pipe operator, |>.

Its purpose is simple: pass the result of one expression into the next one from left to right. That makes chained transformations much easier to read than deeply nested function calls.

<?php

$title = '  PHP 8.5 Released  ';

$slug = $title
    |> trim(...)
    |> strtolower(...)
    |> (fn($value) => str_replace(' ', '-', $value));

echo $slug; // php-8.5-released

This is especially nice for string processing, array transformations, or small data-cleaning pipelines.

The biggest benefit is readability. You read the code in the same order it runs.

One thing to keep in mind: functions that need multiple arguments, like str_replace(), will often require a small closure.

The new URI extension is one of the most useful additions

PHP 8.5 also introduces a built-in URI extension.

This is a big deal because URL handling in many projects still relies on a mix of parse_url(), string concatenation, and custom helpers. That usually works until it does not.

The new API gives PHP a cleaner and more structured way to work with URIs and URLs.

<?php

use Uri\Rfc3986\Uri;

$uri = new Uri('https://example.com/blog/php-8-5');

$updated = $uri
    ->withPath('/blog/php-8-5/comments')
    ->withQuery('page=2&sort=recent');

echo $updated->toString();
// https://example.com/blog/php-8-5/comments?page=2&sort=recent

That makes a lot of sense in apps dealing with pagination, canonical URLs, crawlers, API clients, or SEO tooling.

It is one of those additions that will probably save more bugs than it gets credit for.

Small new functions that remove a lot of noise

PHP 8.5 also adds several small functions and APIs that reduce boilerplate.

Among the most useful are:

array_first()
array_last()
get_error_handler()
get_exception_handler()
Locale::isRightToLeft()
locale_is_right_to_left()
IntlListFormatter
FILTER_THROW_ON_FAILURE

Here is a simple example with array_first() and array_last():

<?php

$items = ['PHP', 'Laravel', 'Vue'];

var_dump(array_first($items)); // PHP
var_dump(array_last($items));  // Vue

And here is one with FILTER_THROW_ON_FAILURE:

<?php

try {
    $email = filter_var(
        'vincent@@example.com',
        FILTER_VALIDATE_EMAIL,
        FILTER_THROW_ON_FAILURE
    );
} catch (Throwable $e) {
    echo 'Invalid email';
}

None of these changes are huge on their own.

But together, they make code a little more direct and a little less repetitive, which is exactly the kind of improvement that ages well.

`#[\NoDiscard]` helps prevent silent mistakes

Another interesting addition is the #[\NoDiscard] attribute.

It allows you to mark a function whose return value should not be ignored.

That is especially useful for transformation functions where forgetting to use the returned value is usually a bug.

<?php

#[\NoDiscard]
function normalizeEmail(string $email): string
{
    return strtolower(trim($email));
}

$email = normalizeEmail('  Vincent.Capek@Example.COM  ');

PHP 8.5 also introduces the (void) cast so you can explicitly ignore a return value when that is intentional.

This makes intent clearer and helps distinguish real mistakes from deliberate choices.

Fatal errors are more useful now

PHP 8.5 improves debugging by adding stack traces to fatal errors.

This sounds small, but in practice it is a very welcome quality-of-life improvement.

When something crashes badly, getting more context immediately can save time, especially in larger apps or older codebases where tracking the source of a fatal error can be annoying.

It is one of those improvements you do not think about until the moment you need it.

Practical extension improvements you will actually notice

PHP 8.5 also includes several useful updates across built-in extensions.

A few stand out more than others in day-to-day work.

DOM gets `outerHTML`

Dom\Element::$outerHTML is finally available.

That is great for scraping, HTML cleanup, testing, or any tool that manipulates markup.

<?php

$doc = Dom\HTMLDocument::createFromString(
    '<article class="post"><h1>Hello</h1></article>'
);

$article = $doc->querySelector('article.post');

echo $article->outerHTML;

`getimagesize()` improves support for modern formats

PHP 8.5 improves getimagesize() support for HEIF, HEIC, and SVG.

That is genuinely useful for uploads, media libraries, CMS features, and portfolio-like projects where modern image formats show up more often.

Partitioned cookies are now supported

Cookies and sessions now support the partitioned flag.

This matters more in modern browser environments where third-party cookie behavior has become stricter.

cURL exposes more diagnostic information

PHP 8.5 adds more details to curl_getinfo().

That helps when debugging outgoing HTTP requests, proxies, authentication behavior, or connection timing.

`mail()` reports failures more honestly

If you still use mail() in some environment, PHP 8.5 improves error reporting around sendmail failures.

That does not modernize mail(), but it does make it less opaque.

The deprecations are not scary, but they are worth cleaning up

PHP 8.5 also deprecates a number of old patterns.

Most of them are not difficult to fix, but they are exactly the sort of things that can sit around in a codebase for years if ignored.

Some of the most important ones are:

case; instead of case: in switch
non-canonical casts like (boolean), (integer), (double)
backticks as an alias for shell_exec()
__sleep() and __wakeup() in favor of __serialize() and __unserialize()
using null as an array offset or in array_key_exists()
incrementing non-numeric strings with ++
legacy functions like curl_close(), imagedestroy(), finfo_close(), xml_parser_free(), mysqli_execute(), and socket_set_timeout()

Here is a simple before-and-after example:

Before:

<?php

$value = (boolean) $input;
$output = `ls -la`;

switch ($status) {
    case 'draft';
        echo 'draft';
        break;
}

After:

<?php

$value = (bool) $input;
$output = shell_exec('ls -la');

switch ($status) {
    case 'draft':
        echo 'draft';
        break;
}

These are not dramatic changes, but they are good signals.

They push PHP code toward more consistency and away from old habits that are either confusing, unnecessary, or easy to misuse.

What I would prioritize first in a real migration

If I were upgrading a real project to PHP 8.5, I would focus on three things first.

1. Try the features that can simplify real code

The pipe operator and the new URI extension are the two most interesting practical additions to experiment with right away.

They can make everyday code cleaner without needing a big architectural change.

2. Clean up easy deprecations early

Things like (boolean), backticks, case;, or legacy close/free functions are usually simple to fix and easy to detect with a global search.

3. Check extension-related behavior where it matters

If your app handles HTML, images, outgoing HTTP requests, or more advanced cookie behavior, PHP 8.5 has changes worth testing directly.

That is where the most practical wins are.

Final thoughts

PHP 8.5 is not the kind of release that tries to reinvent the language.

Instead, it improves the everyday experience of writing PHP.

The pipe operator improves readability. The URI extension fills a long-standing gap. The new functions remove little bits of friction. Debugging gets better. Extension updates feel grounded in real use cases. And the deprecations help nudge codebases toward cleaner patterns.

That makes PHP 8.5 a very solid release.

Not because it changes everything, but because it improves the places where developers spend time every day.

Learning Buffalo by Building a Small Helpdesk App in Go

A0mineTV — Tue, 24 Mar 2026 18:27:08 +0000

When people talk about Go web development, the conversation often jumps straight to minimal stacks: net/http, a router, a query builder, a templating choice, and then a lot of glue code.

That approach is great when you want total control.

But sometimes, you want a more complete web framework experience — something that gives you a structured project layout, routing, templates, models, migrations, forms, and a development workflow that feels closer to Laravel or Rails.

That is exactly why I wanted to explore Buffalo.

To make it concrete, I built a small example project called HelpDesk Lite, a simple support app with users, tickets, and comments:

GitHub repo: https://github.com/VincentCapek/helpdesk_lite

In this article, I want to show how Buffalo works in practice through this project, what the developer experience feels like, and what I learned along the way.

Why Buffalo ?

Buffalo is interesting because it is not just "a router plus a few helpers".

It gives you a full web application structure for Go:

actions for request handling
models for database entities
Pop for ORM-style database work and migrations
Plush for server-side templates
a CLI that helps you run, build, and manage the app

If you are coming from frameworks like Laravel, Rails, or even Symfony, the mental model feels familiar — but you still write Go.

That mix is what makes Buffalo appealing.

The Example: HelpDesk Lite

To learn Buffalo properly, I did not want a “hello world” project. I wanted a small app with enough moving parts to exercise the framework.

So I used this structure:

users
tickets
comments

The idea is simple:

a user can create a support ticket
tickets have a title, description, status, priority, and category
users can add comments to a ticket
there is also an admin entry point in the app

This kind of project is perfect for learning because it touches most of the things you expect in a real web app:
routing, CRUD, validation, relational data, templates, and tests.

What a Buffalo Project Feels Like

One of the first things I liked about Buffalo is that the project layout pushes you toward a clean separation of concerns.

In this app, the important folders are easy to understand:

actions/ → request handlers
models/ → structs and validation
migrations/ → schema changes
templates/ → Plush views
config/ → application setup
cmd/app/ → application entry point

That is a big part of the Buffalo experience:
instead of deciding everything from scratch, you start with conventions.

For small and medium-sized applications, that is a real productivity boost.

Routing: Very Easy to Read

In Buffalo, routes are straightforward.

For a helpdesk app, the route tree is very readable:

app.GET("/", HomeHandler)

app.GET("/tickets", TicketsIndex)
app.GET("/tickets/new", TicketsNew)
app.POST("/tickets", TicketsCreate)

app.GET("/tickets/{ticket_id}", TicketsShow)
app.GET("/tickets/{ticket_id}/edit", TicketsEdit)
app.PUT("/tickets/{ticket_id}", TicketsUpdate)
app.DELETE("/tickets/{ticket_id}", TicketsDestroy)

app.POST("/tickets/{ticket_id}/comments", CommentsCreate)

app.GET("/admin", AdminDashboard)

If you are used to MVC frameworks, this feels natural immediately.

It also makes the request flow easy to follow:
URL → action → model/database → template.

Actions: The Core of the Request Flow

The actions/ folder is where the app logic starts to feel real.

A very typical Buffalo action looks like this:

get the database transaction from the context
bind request data into a struct
validate the data
save it with Pop
either render a template again on failure or redirect on success

That pattern appears again and again in a Buffalo app.

For example, creating a ticket or comment follows the same idea:

c.Bind(...) to map form data into a struct
Validate(...) or ValidateAndCreate(...)
tx.Create(...) to persist
c.Render(...) for validation errors
c.Redirect(...) after success

I like this because it keeps actions explicit.
Nothing feels too magical.
You can read the code top to bottom and understand the full lifecycle of the request.

Pop: Database Work Without Too Much Boilerplate

Buffalo uses Pop for database access and migrations.

For a project like HelpDesk Lite, that feels like a nice middle ground:

simpler than hand-writing everything with raw SQL
less heavy than some ORMs that hide too much
integrated well into the Buffalo workflow

In practice, you work with your models as Go structs, and Pop helps you:

query data
create/update/delete rows
validate models
manage migrations

That was especially useful for ticket and comment creation because the code stays readable.

A request can bind data into a struct, validate it, save it, then redirect — all in a very compact way.

Migrations: A Good Workflow Once You Understand the Rules

Buffalo migrations are powered by Pop, and you can write them with Fizz or raw SQL.

For this project, the migrations created tables like:

users
tickets
comments

One thing that is important to understand early:
only proper migration files are executed by Pop.

So files like these are valid:

20260318102228_create_tickets.up.fizz
20260318102228_create_tickets.down.fizz

But a standalone file like schema.sql is not treated as a migration by soda migrate.

That was a useful lesson.

Another practical point:
once a migration is marked as applied, changing its content later does not magically re-run it.
If you want to evolve the schema, create a new migration.

That is standard migration discipline, but Buffalo/Pop makes you feel it very quickly.

Plush Templates: Familiar, but You Need to Respect the Context

Buffalo uses Plush for templates.

If you already know server-side template engines, Plush is easy to pick up:
you print values, loop through collections, and render HTML with embedded logic.

What I liked:

templates stay readable
forms are easy to build
rendering is tightly integrated with actions

What I learned the hard way:
your template only sees what you explicitly put into the context.

If a template uses ticket.Title, the action must provide ticket with c.Set("ticket", ticket) before rendering.

That sounds obvious, but it is one of those details that teaches you how Buffalo thinks:
templates are not magically connected to your action state.
You pass the data they need, explicitly.

That is actually a good thing.
It keeps the rendering layer predictable.

Validation and Error Rendering

One part I found especially educational was validation handling.

The pattern is simple:

validate the model
if there are errors, put them into the context
re-render the form with a 422
if validation passes, save and redirect

This makes form handling very clear.

It also reinforces a classic web application pattern:
render on failure, redirect on success.

That kind of flow is where Buffalo feels very comfortable.

Running the App

The basic local workflow is straightforward.

Run migrations:

soda migrate -e development -d

Then start the app:

buffalo dev

And Buffalo handles the development loop.

One useful detail:
if you use SQLite, make sure your Buffalo binary actually includes SQLite support.
I ran into that while testing the project.
buffalo dev and soda are not always built the same way, so environment setup matters.

That was a good reminder that frameworks improve workflow, but understanding the tooling still matters.

What I Like About Buffalo

After building this helpdesk example, here is what stood out to me.

1. It gives Go a more “full-stack framework” feel

A lot of Go web stacks are intentionally minimal.
Buffalo is more opinionated, and that is exactly its value.

You get a real application structure instead of assembling everything manually.

2. The request flow is easy to understand

Routes, actions, models, templates, redirects:
everything follows a clear pattern.

3. Pop and migrations are practical

For CRUD-style applications, Pop feels productive without becoming too abstract.

4. The framework teaches discipline

Buffalo makes some mistakes very visible:

missing context variables in templates
incorrect migration assumptions
validation/rendering mistakes
SQLite setup issues in the CLI tooling

That might sound annoying at first, but it helps you understand the framework faster.

Building a Simple Notes REST API with Go and Fiber

A0mineTV — Mon, 16 Mar 2026 13:55:23 +0000

When learning a new web framework, I like to avoid huge starter kits and focus on something small, useful, and easy to reason about.

That is exactly why I built a notes REST API with Go and Fiber. The goal was not to create a production-ready SaaS, but to understand the pieces that matter when starting with Fiber: routing, handlers, middleware, error handling, and a clean project structure.

Why Fiber ?

Fiber is attractive because it gives you a very approachable developer experience while still feeling fast and lightweight. It is inspired by Express, but built for Go, and it keeps the routing and middleware story simple enough that you can focus on your API design instead of fighting the framework.

For this project, I wanted something that would let me practice the basics of a REST API without adding unnecessary complexity. So instead of starting with a database, authentication, migrations, and Docker, I began with an in-memory notes store and a simple layered structure. That let me focus on the request flow first.

Project structure

One thing I did not want was a single main.go file with everything inside it. Even for a small API, separating concerns makes the code easier to read and evolve.

This is the structure I used:

fiber-notes/
├── main.go
├── handlers/
├── middleware/
├── models/
├── routes/
└── storage/

main.go wires the application together, the handlers contain the HTTP logic, routes register endpoints, models define the data shape, storage handles persistence, and middleware contains reusable request logic like logging.

Bootstrapping the Fiber app

The application setup is intentionally small. I create the Fiber app, initialize the memory store, inject it into the handler, register middleware, then mount the notes routes under /api.

app := fiber.New()

store := storage.NewMemoryStore()
noteHandler := handlers.NewNoteHandler(store)

app.Use(recover.New())
app.Use(middleware.SimpleLogger())

app.Get("/", func(c fiber.Ctx) error {
    return c.JSON(fiber.Map{
        "message": "Hello, World!",
        "status":  "ok",
    })
})

api := app.Group("/api")
routes.RegisterNoteRoutes(api, noteHandler)

log.Fatal(app.Listen(":3000"))

Defining the model

The notes API only needs one model, and that simplicity is part of the exercise.

type Note struct {
    ID        int       `json:"id"`
    Title     string    `json:"title"`
    Content   string    `json:"content"`
    CreatedAt time.Time `json:"created_at"`
    UpdatedAt time.Time `json:"updated_at"`
}

This gives the API enough structure to feel real without becoming noisy. The current repo uses Title, Content, and timestamps, which already makes the responses clearer than a minimal { id, text } example.

Adding an in-memory store

To keep the project focused on Fiber itself, I used an in-memory store rather than a database. The store keeps notes in a map[int]models.Note, tracks the next ID, and uses sync.RWMutex so reads and writes stay safe. It exposes methods like List, GetById, Create, Update, and Delete.

That choice was useful for two reasons.

First, it made the project easier to understand. Second, it made the handler layer cleaner because the HTTP code does not need to care about how notes are stored. It only calls the store interface.

Here is the kind of constructor I used:

func NewMemoryStore() *MemoryStore {
    return &MemoryStore{
        notes:  make(map[int]models.Note),
        nextId: 1,
    }
}

And here is the interface the handlers depend on:

type NoteStore interface {
    List() []models.Note
    GetById(id int) (models.Note, error)
    Create(title, body string) models.Note
    Update(id int, title, body string) (models.Note, error)
    Delete(id int) error
}

That separation makes it easy to replace the memory store later with SQLite or PostgreSQL without rewriting the handlers.

Registering routes

Once the API group is created, the routes become straightforward:

func RegisterNoteRoutes(api fiber.Router, noteHandler *handlers.NoteHandler) {
    notes := api.Group("/notes")

    notes.Get("/", noteHandler.ListNotes)
    notes.Get("/:id", noteHandler.GetByID)
    notes.Post("/", noteHandler.Create)
    notes.Put("/:id", noteHandler.Update)
    notes.Delete("/:id", noteHandler.Delete)
}

This gives a clean REST shape:

GET /api/notes/
GET /api/notes/:id
POST /api/notes/
PUT /api/notes/:id
DELETE /api/notes/:id

Writing the handlers

The handlers are where Fiber starts to feel pleasant. Each method receives a fiber.Ctx, reads route params or request bodies, validates input, calls the store, and returns JSON.

Here is the create handler pattern:

func (h *NoteHandler) Create(c fiber.Ctx) error {
    if !c.HasBody() {
        return fiber.NewError(fiber.StatusBadRequest, "request body is required")
    }

    var input CreateNoteInput
    if err := c.Bind().Body(&input); err != nil {
        return fiber.NewError(fiber.StatusBadRequest, "invalid input")
    }

    input.Title = strings.TrimSpace(input.Title)
    input.Content = strings.TrimSpace(input.Content)

    if input.Title == "" {
        return fiber.NewError(fiber.StatusBadRequest, "title is required")
    }

    note := h.store.Create(input.Title, input.Content)

    return c.Status(fiber.StatusCreated).JSON(fiber.Map{
        "message": "note created successfully",
        "data":    note,
    })
}

There are a few things I like here.

c.Bind().Body(&input) keeps request parsing readable. strings.TrimSpace gives quick input cleanup. And fiber.NewError(...) makes invalid states explicit.

For route parameters, I convert the id with strconv.Atoi(c.Params("id")). If the value is invalid, the handler returns a 400 Bad Request. If the note is not found, it returns a 404 Not Found. That small distinction already makes the API feel much more correct.

Adding middleware

I also wanted the project to include middleware from day one, because middleware is one of the best ways to understand how requests flow through Fiber.

The repo includes a simple custom logger:

func SimpleLogger() fiber.Handler {
    return func(c fiber.Ctx) error {
        start := time.Now()

        err := c.Next()
        status := c.Response().StatusCode()

        log.Printf("%s %s %d %s", c.Method(), c.Path(), status, time.Since(start))

        return err
    }
}

This logs the HTTP method, path, status code, and execution time. It is small, but it already makes the server feel more like a real API. Alongside that, I added recover.New() so panics are intercepted and forwarded through Fiber’s error pipeline.

Why this project was useful

The biggest value of this project was not the notes domain itself. It was the repetition of the same backend fundamentals in a small space:

structure the app
register routes
parse JSON
validate input
return proper status codes
isolate storage from HTTP logic
add middleware early

Because the project stays small, each layer remains easy to inspect. And because the app still performs real CRUD operations, it feels much closer to real backend work than a “Hello World” example.

Where to go next

This version uses in-memory storage on purpose, which means data disappears when the server restarts. That is fine for learning, but the natural next steps are:

add SQLite or PostgreSQL
write unit tests for the store and handlers
add request validation
introduce JWT authentication
add pagination and filtering
dockerize the app

That progression turns a simple learning project into a stronger backend foundation without changing the core structure too much.

Final thoughts

Fiber made this project enjoyable because it stayed out of the way. I could focus on HTTP concepts, project structure, and clean handler logic instead of spending too much time wiring infrastructure.

For anyone learning Go web development, building a small CRUD API like this is a great way to move from toy examples to something more realistic. And starting with notes is enough to learn the framework without getting buried in domain complexity.

Building a Clean REST API in Go — No Frameworks, No Fuss

A0mineTV — Sat, 14 Mar 2026 15:36:12 +0000

Go's standard library is powerful enough to build a production-ready REST API without reaching for a framework. In this post, we'll walk through a small but well-structured Notes API that covers all CRUD operations — and the architectural decisions behind it.

What we're building

A simple API to manage notes, with five routes:

Method	Path	Description
`POST`	`/notes`	Create a note
`GET`	`/notes`	List all notes
`GET`	`/notes/{id}`	Get a note by ID
`PUT`	`/notes/{id}`	Update a note
`DELETE`	`/notes/{id}`	Delete a note

Project structure

notes-api/
├── cmd/api/          # Entry point
├── internal/
│   ├── httpapi/      # HTTP handlers
│   ├── note/         # Model, service, storage interface
│   └── storage/      # In-memory implementation

Three distinct layers: HTTP, business logic, and storage. Each one
knows nothing about the others except through interfaces.

The model

type Note struct {
    ID        int64     `json:"id"`
    Title     string    `json:"title"`
    Content   string    `json:"content"`
    CreatedAt time.Time `json:"created_at"`
    UpdatedAt time.Time `json:"updated_at"`
}

Simple and flat. Timestamps are managed by the service, not by the caller.

The storage interface

type Store interface {
    Create(ctx context.Context, n Note) (Note, error)
    List(ctx context.Context) ([]Note, error)
    GetByID(ctx context.Context, id int64) (Note, error)
    Update(ctx context.Context, id int64, title, content string) (Note, error)
    Delete(ctx context.Context, id int64) error
}

Defining a Store interface in the note package (not in storage) is a key decision: the business logic owns the contract, and the storage implementation satisfies it. This makes swapping backends (PostgreSQL, Redis, etc.) trivial later.

The service layer

var ErrInvalidTitle = errors.New("invalid title")
var ErrNotFound = errors.New("not found")

func (s *Service) Create(ctx context.Context, title, content string) (Note, error) {
    if title == "" {
        return Note{}, ErrInvalidTitle
    }
    now := time.Now()
    n := Note{
        Title:     title,
        Content:   content,
        CreatedAt: now,
        UpdatedAt: now,
    }
    return s.store.Create(ctx, n)
}

The service is where business rules live. Here it validates that the title is non-empty and stamps the timestamps before delegating to the store. Typed sentinel errors (ErrInvalidTitle, ErrNotFound) let the HTTP layer map them to the right status codes without leaking implementation details.

The in-memory storage

type MemoryStorage struct {
    mu     sync.RWMutex
    notes  []note.Note
    nextID int64
}

A slice protected by a sync.RWMutex. Read operations (List, GetByID) use RLock to allow concurrent reads; write operations use Lock for exclusive access. Note that the returned slice from List is a copy — so callers can't accidentally mutate the internal state:

func (s *MemoryStorage) List(ctx context.Context) ([]note.Note, error) {
    s.mu.RLock()
    defer s.mu.RUnlock()

    out := make([]note.Note, len(s.notes))
    copy(out, s.notes)
    return out, nil
}

The HTTP handler

Routing is done with the standard http.ServeMux. Two handler functions cover
all five routes:

func (h *Handler) Register(mux *http.ServeMux) {
    mux.HandleFunc("/notes", h.handleNotes)
    mux.HandleFunc("/notes/", h.handleNoteByID)
}

/notes handles GET (list) and POST (create). /notes/ catches everything
with an ID suffix and dispatches on the method:

func (h *Handler) handleNoteByID(w http.ResponseWriter, r *http.Request) {
    id, err := parseIDFromPath(r.URL.Path)
    if err != nil {
        http.Error(w, "Invalid note ID", http.StatusBadRequest)
        return
    }
    switch r.Method {
    case http.MethodGet:
        h.getNote(w, r, id)
    case http.MethodPut:
        h.updateNote(w, r, id)
    case http.MethodDelete:
        h.deleteNote(w, r, id)
    default:
        http.Error(w, "Method not allowed", http.StatusMethodNotAllowed)
    }
}

Service errors are translated to HTTP status codes in one place:

func handleServiceError(w http.ResponseWriter, err error) {
    switch {
    case errors.Is(err, note.ErrInvalidTitle):
        http.Error(w, "Invalid title", http.StatusBadRequest)
    case errors.Is(err, note.ErrNotFound):
        http.Error(w, "Note not found", http.StatusNotFound)
    default:
        http.Error(w, "Internal server error", http.StatusInternalServerError)
    }
}

Wiring it all together

func main() {
    store := storage.NewMemoryStore()
    service := note.NewService(store)
    handler := httpapi.NewHandler(service)

    mux := http.NewServeMux()
    handler.Register(mux)

    log.Println("Server is running on port 8080")
    if err := http.ListenAndServe(":8080", mux); err != nil {
        log.Fatal(err)
    }
}

Three lines of wiring. Each dependency is injected explicitly — no globals, no service locators.

Try it out

go run ./cmd/api

# Create
curl -X POST http://localhost:8080/notes \
  -H "Content-Type: application/json" \
  -d '{"title": "Hello", "content": "World"}'

# List
curl http://localhost:8080/notes

# Get
curl http://localhost:8080/notes/1

# Update
curl -X PUT http://localhost:8080/notes/1 \
  -H "Content-Type: application/json" \
  -d '{"title": "Updated", "content": "New content"}'

# Delete
curl -X DELETE http://localhost:8080/notes/1

Key takeaways

No framework needed for a simple CRUD API — net/http is enough.
Interface in the consumer package (note.Store lives in note, notstorage) keeps dependencies pointing inward.
Typed sentinel errors decouple business logic from HTTP concerns.
sync.RWMutex with defensive copies keeps the in-memory store safe under concurrency.
Dependency injection via constructors makes the whole thing trivially testable.

The next natural step would be swapping MemoryStorage for a real database (PostgreSQL with pgx, for example) — and because of the Store interface, main.go is the only file that changes.

Building a Deterministic Password CLI in Go with Argon2id

A0mineTV — Thu, 12 Mar 2026 14:43:11 +0000

Most password generators focus on randomness.

GitHub repo: VincentCapek/argon2-password-cli

This project takes a different route: it derives the same password every time from a master password and a label such as github, gmail, or bank.

That makes it a great little Go project for learning a few useful concepts at once:

building a CLI with flag
structuring a small Go codebase
using Argon2id
understanding deterministic derivation versus random generation
shaping output with validation and character groups

The idea

Instead of generating a brand-new password on every run, the CLI derives a reproducible one from two inputs:

a master password
a label

So this:

go run . -master="MyUltraSecret" -label="github" -length=20

Will always return the same password as long as the inputs and options stay the same.

Change the label to gmail, and the output changes too.

That gives you a simple mental model:

same master + same label = same password
same master + different label = different password

Why this is interesting

When you first build a password generator, the obvious route is to use crypto/rand and produce something fully random.

That is still the right approach for many use cases.

But a deterministic password CLI teaches a different lesson: you are not generating randomness for storage or one-time usage, you are deriving a stable result from a secret and a context.

That is exactly why this kind of mini project is interesting from a learning perspective.

It pushes you to think about:

what a salt is
why context matters
how to separate CLI parsing from generation logic
how to build a reproducible byte stream
how to shape the final password so it remains usable

Project structure

The repository is intentionally small:

main.go handles the CLI flags and builds the config
generator.go contains the derivation and password generation logic
go.mod defines the module and dependencies

That small size is actually one of the project’s strengths. You can read the whole codebase in one sitting and still touch several important ideas.

How the generator works

The generation pipeline is clean and easy to follow.

1. Parse CLI options

The CLI accepts a master password, a label, a desired length, and options for lowercase, uppercase, digits, and symbols.

That already makes the project practical while staying beginner-friendly.

2. Normalize the label

Before using the label, the code normalizes it by trimming spaces and converting it to lowercase.

That means values like:

github
GitHub
GITHUB

all resolve to the same normalized label.

This is a small but important detail, because it avoids accidental password drift caused by casing or whitespace differences.

3. Turn the label into a salt

The normalized label is hashed with SHA-256, and the first 16 bytes are used as the salt.

This is a neat design choice for a deterministic CLI:

the label remains human-friendly
the salt is derived in a consistent way
changing the label changes the salt, which changes the result

4. Derive a seed with Argon2id

The project then uses argon2.IDKey(...) to derive a 32-byte seed from:

the master password
the derived salt
the cost parameters

This is the cryptographic core of the project.

Instead of directly turning the label into a password, the code first asks Argon2id to produce a strong derived key. That key becomes the seed for the next stage.

5. Build a deterministic byte stream

From there, the project uses a custom byteStream.

The idea is simple:

combine the seed with a counter
hash that combination with SHA-256
use the resulting bytes as a deterministic stream
increment the counter when more bytes are needed

This is a nice educational touch, because it makes the generation process easier to reason about than hiding everything behind a single opaque helper.

6. Build the password from character groups

The code defines separate character sets for:

lowercase letters
uppercase letters
digits
symbols

It first guarantees at least one character from each enabled group.

Then it fills the rest of the password from the merged character set.

Finally, it performs a deterministic shuffle so the password does not always start with the same kind of characters.

That last part matters a lot. Without the shuffle, the output shape would be predictable even if the actual characters were not.

A small project, but a good set of lessons

What I like about this repository is that it stays small without being trivial.

It introduces several ideas that show up again and again in real projects:

validating input early
separating config from logic
composing small helper functions
avoiding duplicated logic for character groups
keeping the CLI thin and the generator focused

In other words, this is not just a “security toy.” It is also a solid exercise in writing clean Go.

Random generation vs deterministic derivation

This is probably the most important distinction in the whole project.

A traditional password generator says:

give me a fresh random password right now

This CLI says:

derive the same password again from a secret and a label

That difference changes the whole architecture.

If you want true randomness, crypto/rand is the right tool.

If you want reproducibility tied to a context, a derivation approach like this becomes much more interesting.

That distinction is one of the reasons this project works so well as a learning exercise.

Example commands

Generate a 20-character password for GitHub:

go run . -master="MyUltraSecret" -label="github" -length=20

go run . -master="MyUltraSecret" -label="bank" -length=16 -symbols=false

Increase the Argon2 cost parameters:

go run . -master="MyUltraSecret" -label="github" -time=4 -memory=64

What I would improve next

If I were extending this project, I would probably add:

hidden master-password input instead of passing it directly on the command line
unit tests for deterministic output and validation rules
profiles for site-specific password policies
clipboard support
a cmd/ layout if the project grows

None of that is required for the project to be useful today, but each item would be a natural next step.

Final thoughts

I like projects like this because they stay focused.

You do not need a framework, a database, or a large architecture to learn something meaningful. Sometimes a compact CLI is enough to explore:

Go flags
data validation
helper types
deterministic generation
Argon2id integration

If you want a small but instructive Go project, building a deterministic password CLI like this is a very good exercise.

It teaches both language fundamentals and design trade-offs in a way that stays concrete from start to finish.

Building SearchForge: a lightweight search interface with Go and Vue

A0mineTV — Wed, 11 Mar 2026 13:01:44 +0000

I like building products that are small, focused, and easy to reason about.

That is exactly why I started SearchForge: a local search application with a Go backend and a Vue 3 + TypeScript frontend, designed to feel like a modern SERP while staying simple enough to evolve quickly.

The project is available on GitHub here: VincentCapek/SearchForge.

The goal was not to recreate a full search engine from day one.

The goal was to build a clean foundation:

a backend that can fetch and normalize results,
a frontend that can render them in a familiar way,
and an architecture flexible enough to support multiple search providers later.

Why I built it

I wanted a project that sat at the intersection of backend structure, frontend UX, and search-oriented interfaces.

Search is a great playground for that because even a “simple” search page forces you to think about several layers at once:

how results are fetched,
how they are normalized,
how errors are handled,
how loading states feel,
and how the UI stays readable when the data changes.

Instead of starting with a huge stack, I deliberately chose a lightweight setup:

Go for the backend,
Vue 3 + TypeScript for the frontend,
Vite for fast iteration,
and UnoCSS for a design system that stays close to the code.

The architecture

From the beginning, I wanted the codebase to be split by responsibility rather than mixed together in a single app layer.

The project is organized around a few simple parts:

search/ contains the search fetching and parsing logic
server/ contains the HTTP server and route registration
server/api/ contains the API handlers and JSON error helpers
assets/ contains the frontend application
utils/ is where shared helpers live

That separation matters more than it seems.

It means I can improve parsing logic without touching the UI, and I can redesign the frontend without rewriting the backend contract.

Why Go for the backend

For this kind of project, Go felt like a natural fit.

I wanted a backend that was:

fast to run locally,
easy to read,
simple to deploy later,
and not dependent on a heavy framework just to expose a few endpoints.

So I used the standard library HTTP server and built a small router with dedicated handlers.

That gave me a backend that stays explicit:

a health endpoint,
provider-specific search endpoints,
and a small JSON layer for success and error responses.

One detail I particularly like is the generic handler factory.

Instead of repeating the same validation and response logic for every provider, I used a generic makeSearchHandler function that wraps a search function and turns it into an HTTP handler.

That keeps the API layer small while making it easy to plug in new providers.

Fetching and parsing search results

The core of the project lives in the search layer.

Right now, the backend already includes logic for multiple providers, including DuckDuckGo and Brave. The idea is straightforward:

build the search URL,
fetch the HTML document,
parse the relevant nodes,
normalize the output,
return a consistent JSON response to the frontend.

To do that, I used goquery, which gives me a jQuery-like API for HTML parsing in Go.

For DuckDuckGo, I parse result blocks, ignore ads, extract the title, URL, domain, and snippet, then normalize the URL before returning it.

For Brave, I follow a similar flow, but with selectors adapted to Brave’s markup and a few extra fields such as site metadata.

This is one of the most interesting parts of the project because scraping search results is never just “grab some HTML and done.”

You have to think about:

noisy markup,
invalid links,
duplicate results,
result normalization,
and how brittle selectors can become over time.

Adding a small relevance filter

I also added a lightweight blocklist layer.

This lets me exclude domains that are not useful for the kind of result quality I want in the interface. It is a tiny feature, but it changes the feel of the output immediately.

I like this kind of pragmatic layer because it shows that ranking and filtering are not always giant machine learning problems.

Sometimes, a simple handcrafted rule already makes the product feel better.

Designing the frontend

On the frontend side, I wanted the UI to stay clean and component-driven.

The app is built with Vue 3, TypeScript, and Vite, and split into small pieces:

a search bar,
a result list,
individual result cards,
and a composable dedicated to the search flow.

That composable is important.

Instead of scattering state across the app, I grouped the core search state into a single place:

the query,
loading,
error,
results,
and whether the user has already searched.

That makes the UI easy to reason about because each visual state maps to a clear application state:

initial state,
loading state,
empty state,
error state,
and result state.

This is the kind of pattern I like in frontend projects: not complicated, just predictable.

Why I used UnoCSS

I chose UnoCSS because I wanted utility-first styling without turning the code into an unreadable wall of classes.

The project defines shortcuts and theme tokens for:

layout,
search fields,
buttons,
result cards,
feedback panels,
and typography.

That means I can keep a consistent visual language while still moving fast.

I also like that the design system already reflects the kind of interface I wanted: soft borders, muted text, clean spacing, and a search-first layout that feels familiar without being a copy.

Keeping frontend and backend decoupled in development

One practical choice that helped a lot was using Vite’s proxy.

The frontend runs on its own dev server, while API and health requests are forwarded to the Go backend. That keeps the local workflow smooth:

run Go on port 8080,
run Vite on port 5173,
and let the frontend talk to the API without CORS headaches.

It is a small detail, but it makes iteration much faster.

What I like about this project

What I like most about SearchForge is that it already has the right shape.

It is not trying to do everything.

It is trying to do the important things clearly:

separate concerns,
normalize data at the backend layer,
keep the frontend simple,
and leave enough room for future expansion.

There are even traces of its earlier naming and evolution in the codebase, which I honestly like. It reminds me that good projects are rarely born “finished” — they become clearer as you build them.

What I would improve next

This project is already a strong base, but there are a lot of directions I want to explore next.

A few obvious ones are:

adding more providers,
introducing filters and engine selection,
improving normalization across providers,
storing search history,
serving the frontend directly from Go in production,
and refining the SERP UI further.

I also want to keep improving the contract between backend and frontend so each provider can plug into the same interface cleanly.

That is where this kind of project becomes really fun: once the foundation is stable, every new feature has a clear place to live.

Final thoughts

SearchForge is the kind of project I enjoy building the most: small enough to move fast, but structured enough to grow into something more serious.

It gave me a chance to work on:

backend API design,
HTML parsing in Go,
provider normalization,
frontend state management,
and design system thinking inside a Vue app.

Most importantly, it helped me build a product in layers instead of building everything at once.

That is usually how I like to work:
start with a clear backbone, make each part understandable, and leave room for the project to become more ambitious over time.

If you are interested in lightweight full-stack projects, search interfaces, or pragmatic architecture, this kind of setup is a lot of fun to build.

You can explore the codebase here: github.com/VincentCapek/SearchForge.

Why ChatGPT Codex Became My Go-To Partner for Backend Business Logic

A0mineTV — Tue, 03 Mar 2026 16:35:22 +0000

TL;DR: I don’t use AI to "write CRUD faster." I use it where backend work is most expensive: business logic, data invariants, state transitions, idempotency, and regression-proof refactors.

The Silent Danger of Backend Bugs

On the backend, speed is meaningless if you ship the wrong behavior. Unlike a UI bug, which is usually visible, a backend bug can be silent and devastating:

The wrong status is stored in the database.
A customer is charged the wrong amount.
A retry logic creates duplicate records.
A permission check is slightly too permissive.

These bugs generate support tickets and long-term distrust in the system. That’s why using an AI partner (like ChatGPT or Codex) is more about observability and precision than just typing code.

That’s why I started using ChatGPT Codex as a backend-focused pair programmer—not as a snippet generator.

What Makes Business Logic Hard ?

Business logic is rarely a single if statement. It is a complex system of rules, priority between those rules, and invariants (things that must never happen). The hard part isn't writing the code; it's stating the rule precisely and making it safe to evolve without breaking side effects.

Where Codex helps most in backend projects

Clarifying rules into a testable contract

Before I implement, I use Codex to turn vague rules into something concrete:

Given / When / Then scenarios
edge cases (“what happens if…?”)
invariants and failure modes
a decision table or scenario matrix

The goal is not to “ask the model for the solution.”
The goal is to remove ambiguity and create a contract I can test and maintain.

A simple prompt that works well:

You are my backend reviewer. Turn this business rule into:
1) a short spec (in plain English),
2) a scenario matrix (nominal + edge cases),
3) unit tests (PHPUnit for PHP / pytest for Python),
4) implementation notes (invariants, idempotency, transactions, concurrency).
Business rule: <paste here>
Constraints: <DB, performance, API compatibility, etc.>

Surfacing the “invisible constraints” early

The real backend gotchas usually live outside the feature description:

Idempotency (duplicate requests, retries)
Transactions (partial failure)
State machines (allowed transitions)
Concurrency (race conditions)
Integration contracts (API, queues, webhooks)

Codex is good at forcing those questions to the surface. Even if you decide “we don’t need this right now,” at least it becomes a conscious decision.

Safer refactors across multiple files

Backend refactors are scary because logic tends to spread:

controllers, services, repositories
duplicated checks
hidden coupling through shared helpers
inconsistent error handling

Codex helps me:

identify duplication and drift
propose extractions (services / policies / use-cases)
rename across files consistently
produce a reviewable patch instead of isolated snippets

A concrete example: idempotent checkout with state transitions

Let’s use a common scenario: checkout.
We want:

a single charge even if the request is retried
safe state transitions
atomic DB changes

Business rule (simplified)

A checkout request includes an idempotency_key.
If the same key is seen again, return the previously created result (no duplicate charge).
Order states: DRAFT -> PENDING_PAYMENT -> PAID (and no jumping backwards).
If payment fails, mark as PAYMENT_FAILED and keep the order consistent.

Example in PHP (Laravel-ish style)

State transitions as explicit rules:

final class OrderStatus
{
    public const DRAFT = 'DRAFT';
    public const PENDING_PAYMENT = 'PENDING_PAYMENT';
    public const PAID = 'PAID';
    public const PAYMENT_FAILED = 'PAYMENT_FAILED';

    public static function canTransition(string $from, string $to): bool
    {
        $allowed = [
            self::DRAFT => [self::PENDING_PAYMENT],
            self::PENDING_PAYMENT => [self::PAID, self::PAYMENT_FAILED],
            self::PAID => [],
            self::PAYMENT_FAILED => [],
        ];

        return in_array($to, $allowed[$from] ?? [], true);
    }
}

Idempotency record (DB-backed):

// idempotency_keys table: key (unique), resource_type, resource_id, response_hash, created_at
final class IdempotencyStore
{
    public function find(string $key): ?IdempotencyRecord { /* ... */ }
    public function save(IdempotencyRecord $record): void { /* ... */ }
}

Checkout service with transaction:

final class CheckoutService
{
    public function __construct(
        private IdempotencyStore $idem,
        private PaymentGateway $payments,
        private OrderRepository $orders,
    ) {}

    public function checkout(int $orderId, string $idempotencyKey): CheckoutResult
    {
        if ($existing = $this->idem->find($idempotencyKey)) {
            return $this->orders->getCheckoutResult($existing->resourceId());
        }

        return DB::transaction(function () use ($orderId, $idempotencyKey) {
            $order = $this->orders->lockForUpdate($orderId);

            if (!OrderStatus::canTransition($order->status, OrderStatus::PENDING_PAYMENT)) {
                throw new DomainException("Order cannot be checked out from status {$order->status}");
            }

            $order->status = OrderStatus::PENDING_PAYMENT;
            $this->orders->save($order);

            try {
                $payment = $this->payments->charge($order->total, $idempotencyKey);

                $order->status = OrderStatus::PAID;
                $this->orders->save($order);

                $this->idem->save(IdempotencyRecord::for($idempotencyKey, 'order', $order->id));
                return CheckoutResult::paid($order->id, $payment->id);
            } catch (PaymentFailed $e) {
                $order->status = OrderStatus::PAYMENT_FAILED;
                $this->orders->save($order);

                $this->idem->save(IdempotencyRecord::for($idempotencyKey, 'order', $order->id));
                return CheckoutResult::failed($order->id, $e->getMessage());
            }
        });
    }
}

Example tests (PHPUnit)

public function test_checkout_is_idempotent(): void
{
    $service = $this->makeService();

    $r1 = $service->checkout(orderId: 42, idempotencyKey: 'abc');
    $r2 = $service->checkout(orderId: 42, idempotencyKey: 'abc');

    $this->assertSame($r1->orderId, $r2->orderId);
    $this->assertSame($r1->status, $r2->status);
    $this->assertEquals(1, $this->paymentGateway->chargeCount());
}

Same idea in Python (pytest)

def test_checkout_is_idempotent(service, payment_gateway):
    r1 = service.checkout(order_id=42, idempotency_key="abc")
    r2 = service.checkout(order_id=42, idempotency_key="abc")

    assert r1.order_id == r2.order_id
    assert r1.status == r2.status
    assert payment_gateway.charge_count == 1

How Codex fits into this workflow

When I work on features like this, I use Codex for:

Spec shaping
- “Rewrite this rule into a testable spec + scenario matrix.”
- “List invariants and failure modes.”
Test-first scaffolding
- “Generate PHPUnit/pytest tests for these scenarios.”
Refactor safety
- “Extract this into a domain service without changing behavior.”
- “Find duplicated business rules across the repo.”
Review mode
- “Act as a backend reviewer: point out hidden regressions, race conditions, missing cases.”

Example “review prompt”:

Review this diff like a senior backend engineer.
Focus on:
- hidden behavior changes
- missing edge cases
- idempotency / retries
- transaction boundaries and consistency
- concurrency and locking
- error handling and observability
Then propose test cases to cover risks.
Diff: <paste diff or file paths>

Practical tips to get better results (without over-prompting)

Give constraints upfront: DB, framework conventions, error handling style.
Ask for scenarios before code: It reduces rework dramatically.
Keep business logic explicit: state transitions, invariants, and idempotency rules should be visible.
Treat outputs as drafts: you still own the architecture and safety decisions.
Use Codex as a reviewer: it’s often most valuable when it challenges your assumptions.

What Codex doesn’t replace

Codex is not a substitute for:

understanding your domain
reviewing security implications
deciding trade-offs (consistency vs latency, strict vs eventual)
monitoring, logging, and alerting strategy

But it does compress the feedback loop between “rule” and “correct behavior,” which is where backend teams spend a lot of time.

Closing thoughts

For backend projects, “AI that writes code” is nice.

“AI that helps you ship safe business logic” is a different level of usefulness.

If you’re building backends in PHP or Python, try using Codex less like a generator and more like:

a spec editor,
a test designer,
a refactor assistant,
and a relentless reviewer.

That’s where it pays off.

Laravel 13 + Inertia + Vue 3 + TypeScript: A Practical Upgrade Path from Laravel 12

A0mineTV — Sun, 01 Mar 2026 16:58:26 +0000

Laravel upgrades are often discussed as dry changelogs and release notes. To understand the real-world impact, I built a functional application using Laravel 13 + Inertia + Vue 3 + TypeScript and compared the experience with Laravel 12.

The experiment focused on shipping actual features: CRUD screens, validation, complex Eloquent queries, and relationships like reviews and polymorphic media.

This article is a hands-on summary of what I built and what I learned.

Note on Timing: At the time of this build, Laravel 13 was available as 13.x-dev. Expect minor ecosystem hiccups when using development branches.

1. What Really Changes from Laravel 12 → Laravel 13

The PHP Baseline Move

The most significant "real-world" difference is the baseline: Laravel 13 pushes the minimum PHP version forward. While beneficial long-term, it immediately impacts your infrastructure, requiring updates to CI images, Docker base images, and hosting environments like Forge or Vapor. In practice, the upgrade cost often lies more in your environment and dependencies than in your application code.

Attributes Become First-Class

Laravel 13 leans heavily into PHP Attributes (#[...]) for configuration that previously lived in protected class properties. This makes classes more declarative; you can open a model and immediately see its exports, permissions, and scopes at the top of the file.

Inertia Stability

One major advantage is that Inertia stays stable during this transition. You can modernize your backend baseline while keeping your SPA-like frontend workflow—using Inertia::render(), Vue components, and useForm<T>()—exactly the same.

2) Attributes (annotations) become first-class

Laravel 13 leans into PHP Attributes (#[...]) for configuration that used to live in class properties.

This is not about “saving lines of code”. It’s about making classes more declarative: you open a model and immediately see what it allows/exports and which scopes exist.

Here’s the exact style I used in the project (more on it later):

<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Builder;
use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Attributes\Fillable;
use Illuminate\Database\Eloquent\Attributes\Visible;
use Illuminate\Database\Eloquent\Attributes\Scope;

#[Fillable(['name', 'price_cents', 'is_active'])]
#[Visible(['id', 'name', 'price_cents', 'is_active'])]
class Product extends Model
{
    #[Scope]
    protected function search(Builder $query, string $q): void
    {
        $query->where('name', 'like', "%{$q}%");
    }
}

3) Inertia stays stable (and that’s a good thing)

On the frontend side, Inertia doesn’t “change with Laravel 13”. The big value is that you can modernize the backend while keeping your SPA-like workflow the same:

controller returns Inertia::render(...)
pages are Vue components
forms are powered by useForm<T>()

So your upgrade effort is concentrated in backend baseline + patterns, not in “rewriting your frontend”.

Project setup: Laravel 13 + Inertia + Vue 3 + TypeScript

1) Composer + environment

If you are on 13.x-dev, keep your composer.json clean:

minimum-stability and prefer-stable must be top-level keys, not inside require
you may need prefer-stable: true to avoid pulling dev versions for everything
some packages may lag behind (I hit this with laravel/tinker)

A minimal starting point:

{
  "require": {
    "php": "^8.3",
    "laravel/framework": "13.x-dev"
  },
  "minimum-stability": "dev",
  "prefer-stable": true
}

If Composer gets stuck on conflicts, I recommend a clean resolution pass:

rm -rf vendor composer.lock
composer install
php artisan --version

2) Inertia server setup

Install the Laravel adapter:

composer require inertiajs/inertia-laravel -W

Create the root template at resources/views/app.blade.php:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
  @vite(['resources/css/app.css', 'resources/js/app.ts'])
  @inertiaHead
</head>
<body>
  @inertia
</body>
</html>

Then create a middleware to share props (auth user, flash messages, etc.):

<?php

namespace App\Http\Middleware;

use Illuminate\Http\Request;
use Inertia\Middleware;

class HandleInertiaRequests extends Middleware
{
    protected $rootView = 'app';

    public function share(Request $request): array
    {
        return [
            ...parent::share($request),
            'auth' => [
                'user' => $request->user(),
            ],
            'flash' => [
                'success' => fn () => $request->session()->get('success'),
                'error'   => fn () => $request->session()->get('error'),
            ],
        ];
    }
}

Laravel 13 uses bootstrap/app.php middleware registration (no Http\Kernel.php), so make sure your HandleInertiaRequests is appended to the web middleware group.

3) Vue 3 + TypeScript + Vite

Install dependencies (example with pnpm):

pnpm add vue @inertiajs/vue3
pnpm add -D typescript vue-tsc @types/node @vitejs/plugin-vue

resources/js/app.ts:

import './bootstrap'
import { createApp, h } from 'vue'
import { createInertiaApp } from '@inertiajs/vue3'
import { resolvePageComponent } from 'laravel-vite-plugin/inertia-helpers'

createInertiaApp({
  resolve: (name) =>
    resolvePageComponent(`./Pages/${name}.vue`, import.meta.glob('./Pages/**/*.vue')),
  setup({ el, App, props, plugin }) {
    createApp({ render: () => h(App, props) })
      .use(plugin)
      .mount(el)
  },
})

Feature 1: Products CRUD (Inertia + TS)

Generate the backend pieces

php artisan make:model Product -m
php artisan make:controller ProductController --resource
php artisan make:request StoreProductRequest
php artisan make:request UpdateProductRequest

Migration (simplified):

Schema::create('products', function (Blueprint $table) {
    $table->id();
    $table->string('name');
    $table->unsignedInteger('price_cents');
    $table->boolean('is_active')->default(true);
    $table->timestamps();
});

Laravel 13-style model configuration with attributes

Here’s the model again (this was the main “Laravel 13” part of the CRUD):

<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Builder;
use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Attributes\Fillable;
use Illuminate\Database\Eloquent\Attributes\Visible;
use Illuminate\Database\Eloquent\Attributes\Scope;

#[Fillable(['name', 'price_cents', 'is_active'])]
#[Visible(['id', 'name', 'price_cents', 'is_active'])]
class Product extends Model
{
    #[Scope]
    protected function search(Builder $query, string $q): void
    {
        $query->where('name', 'like', "%{$q}%");
    }
}

Controller (pagination + search)

<?php

namespace App\Http\Controllers;

use App\Http\Requests\StoreProductRequest;
use App\Http\Requests\UpdateProductRequest;
use App\Models\Product;
use Illuminate\Http\Request;
use Inertia\Inertia;

class ProductController extends Controller
{
    public function index(Request $request)
    {
        $q = $request->string('q')->toString();

        $products = Product::query()
            ->when($q !== '', fn ($query) => $query->search($q)) // attribute scope
            ->latest()
            ->paginate(10)
            ->withQueryString();

        return Inertia::render('Products/Index', [
            'products' => $products,
            'filters' => ['q' => $q],
        ]);
    }

    public function create()
    {
        return Inertia::render('Products/Create');
    }

    public function store(StoreProductRequest $request)
    {
        Product::create($request->validated());

        return redirect()
            ->route('products.index')
            ->with('success', 'Product created.');
    }

    public function edit(Product $product)
    {
        return Inertia::render('Products/Edit', [
            'product' => $product->only('id', 'name', 'price_cents', 'is_active'),
        ]);
    }

    public function update(UpdateProductRequest $request, Product $product)
    {
        $product->update($request->validated());

        return redirect()
            ->route('products.index')
            ->with('success', 'Product updated.');
    }

    public function destroy(Product $product)
    {
        $product->delete();

        return redirect()
            ->route('products.index')
            ->with('success', 'Product deleted.');
    }
}

TypeScript-friendly Inertia pages

On the Vue side, the most important thing is typing your form state and avoiding v-model on readonly props.

Example form type:

type ProductForm = {
  name: string
  price_cents: number
  is_active: boolean
}

And then:

const form = useForm<ProductForm>({
  name: '',
  price_cents: 0,
  is_active: true,
})

Feature 2: Reviews (Eloquent relations + Inertia pages)

Once CRUD was working, I added reviews to exercise Eloquent relationships.

Database shape

products 1—N reviews
customers 1—N reviews
unique constraint: (product_id, customer_id) to ensure one review per customer per product

That gives you:

relationship loading (with('customer'))
aggregates (withCount, withAvg)
nested routes (products/{product}/reviews)

Useful Eloquent aggregate

Product::query()
  ->whereKey($product->id)
  ->withCount('reviews')
  ->withAvg('reviews', 'rating')
  ->first();

This kind of query is where Laravel’s ORM really shines: you get meaningful stats without hand-writing raw SQL everywhere.

Feature 3: Polymorphic media (one table, multiple parents)

A polymorphic relation lets you attach media to multiple models (Product, Customer, Order...) using one media table:

mediable_type
mediable_id

Migration helper:

$table->morphs('mediable');

Then:

Media has morphTo()
Product has morphMany(Media::class, 'mediable')

Why it’s great:

you don’t need product_images, customer_avatars, order_files...
you get a uniform API in Eloquent ($model->media()->create(...))

Running the app (backend + frontend)

Two terminals:

php artisan serve

pnpm dev

Or a single command if you wired a composer run dev script that starts both processes.

Lessons learned (the honest part)

Laravel 13 dev branch is usable, but expect dependency mismatches. If a package doesn’t support ^13, either drop it temporarily or use its dev branch.
The biggest win of Laravel 13 in my build was declarative configuration with attributes. It doesn’t rewrite your app, but it makes your codebase easier to read as it grows.
Inertia is a perfect match for this kind of exploration: you can build real screens fast while keeping backend logic “Laravel-native”.

Next steps (if you want to push the ORM further)

If you want to turn this into an even better Eloquent playground:

product variants (Product → ProductVariant, options/values, complex pivots)
inventory & stock movements (transactions + aggregates)
multi-tenant scoping (global scopes + tenant_id)

Laravel Scheduler in Production: Why I Use It (and How I Make It Reliable)

A0mineTV — Thu, 26 Feb 2026 12:49:20 +0000

Scheduled tasks are easy—until they aren’t. The first time an invoice isn’t sent, a sync silently stops, or a report runs twice and crashes your server, you realize scheduled work isn’t just "ops trivia." It’s a product risk.

For a long time, I treated scheduling as a server concern by adding lines to a crontab. But that led to major pain points:

Tasks were configured outside the codebase (not versioned or reviewable).
Differences between staging and production ("it works on my server").
Overlapping jobs because a previous run didn't finish.
Double executions when the app scaled to multiple instances.

Laravel’s Scheduler solves the real problem: Governance. It turns scheduling into something you can read, review, deploy, and reason about.

The core idea: the server triggers, Laravel orchestrates

In production, you only need one cron entry on your server:

run php artisan schedule:run every minute

That’s it.

From this point, Laravel decides which tasks are due. Your schedule becomes part of your application code, shifting it from a "mystery ops config" to versioned application behavior.

This shifts scheduling from “mystery ops config” to versioned application behavior.

Why I prefer Laravel Scheduler over “pure crontab”

I’m not anti-cron. Cron is great at one thing: triggering commands at a regular cadence.

The issues start when cron becomes the place where business-critical workflows live. Because then you’re maintaining system behavior in a place that:

is not part of pull requests
can’t be code-reviewed the same way
varies between environments
becomes messy over time (and nobody wants to touch it)

Laravel Scheduler fixes that by letting me express scheduling as intent, not cron syntax.

Instead of thinking “what is the crontab line for weekdays at 02:00?”, I can encode the intent directly:

every day at 2 AM
in the correct timezone
never overlap
only run once even with multiple servers
keep output for auditing

My “production defaults”: make tasks safe by design

Almost every important scheduled task in my projects includes two safety guarantees:

1) No overlaps

If a job is still running, the next scheduled tick should not start another copy.

That’s what withoutOverlapping() gives you.

Overlaps cause the most annoying class of bugs: duplicates. Duplicate emails. Duplicate invoices. Duplicate exports. Duplicate API calls. Duplicate side effects.

2) One execution across multiple servers

When an app scales horizontally, cron runs on every instance by default.

Without protection, the same scheduled task can run N times.

That’s what onOneServer() is for.

If you’ve ever scaled to two servers and suddenly saw doubled notifications… you only need that incident once to adopt onOneServer() forever.

A concrete example (Carbon-friendly snippet)

Let’s say you generate a daily report at 2 AM:

<?php

use Illuminate\Support\Facades\Schedule;

Schedule::command('reports:daily')
    ->dailyAt('02:00')
    ->timezone('Europe/Paris')
    ->onOneServer()
    ->withoutOverlapping()
    ->sendOutputTo(storage_path('logs/schedule-reports.log'));

What I like about this code is that it reads like a checklist of business intent:

Daily at 02:00
Correct timezone
Single run across instances
No overlap
Output preserved for auditing

Observability: don’t “trust” schedules—prove they run

A scheduled task that fails silently is worse than one that fails loudly.

So I treat scheduled work like I treat anything business-critical: it needs traceability.

At minimum, I want:

output persisted somewhere (sendOutputTo, appendOutputTo, etc.)
a way to audit the configured schedule (php artisan schedule:list)
visibility in logs/monitoring when something breaks

If the task is critical (payments, invoices, notifications), I go a step further and connect failures to alerts.

The point is not “more tooling”. The point is shorter time to detect.

The scheduler is an orchestrator, not a worker

Here’s a rule that saved me multiple times:

The scheduler should trigger work, not be the work.

If something can be slow, fragile, or dependent on external services, I don’t want it to run as one long synchronous command inside schedule:run.

Instead, I schedule a command that dispatches a job:

the schedule stays quick and predictable
the heavy work runs in the queue
retries and failures are handled properly
monitoring becomes easier

This is also how you avoid minute-based drift when tasks take longer than expected.

The “SQL vs PHP” equivalent in scheduling

I use a similar separation of concerns as with data transformations:

cron/Laravel schedule: when
job/command: what
queue workers: how it executes reliably

When those responsibilities are mixed, maintenance becomes painful.

Common pitfalls (that look fine until production)

I’ve seen these issues repeatedly:

“It works locally but not in prod”

Often the schedule is correct, but the server isn’t actually triggering it (missing cron entry, wrong PHP path, wrong user).

Overlaps

The task runs every minute, but takes 2 minutes. Now you have two copies running. Then three.

Multi-instance duplicates

Scaling from 1 to 2 servers doubles everything—emails, webhooks, cleanup jobs.

No logs, no audit trail

You’re guessing whether it ran. Guessing is not a strategy.

A quick production checklist

If I’m shipping scheduled tasks, I want to answer these questions:

Is there exactly one trigger cron on the server ?
Can this task overlap? If yes, how do I prevent it ?
Can this task run on multiple servers ? If yes, how do I enforce single execution ?
Where do I see output ?
If it fails, how do I find out quickly ?
Should this be a queued job instead ?

Final thought

Laravel Scheduler doesn’t just “schedule tasks”.

It gives you a way to treat scheduled work like real application behavior:

versioned
reviewable
predictable
safer in production
easier to audit and troubleshoot

And once you’ve dealt with a silent failure or duplicated side effects in production, that shift is worth a lot.

DEV Community: A0mineTV

One interface, eight job sources: designing a connector pipeline that doesn't fight you

The shape of the problem

The contract

The orchestrator: SynchronizeSourceAction

The interesting part: PersistOfferAction

Where it got tested for real: adding a source that isn't a network request

What I'd tell someone building this from scratch

Structuring a Laravel Project with Repositories and Services (Without Over-Engineering)

Why I would revisit the original approach

When this structure is actually useful

The main issue with generic BaseRepository examples

A more practical Laravel structure

Step 1: create a repository contract around the feature

Step 2: implement the repository with Eloquent

Step 3: put real business logic in the service layer

Step 4: move validation to Form Requests

Step 5: use API Resources for response formatting

Step 6: keep the controller focused on HTTP

Step 7: bind the repository in the service container

What is improved compared to the older version

1. The repository is not generic for the sake of being generic

2. The service contains actual business logic

3. The controller is smaller for the right reasons

4. The code becomes easier to test

When I would not use repositories and services

Final thoughts

How I Built a Support Ticket MCP Server in Laravel

Why this is a good MCP use case

Registering the server in Laravel

Defining the support server

The ticket creation tool

The ticket resource

The prompt that turns raw data into a ready-to-send summary

Why I like this architecture

Final thoughts

PHP 8.5: The Changes That Really Matter in Everyday Development

The pipe operator makes transformations easier to read

The new URI extension is one of the most useful additions

Small new functions that remove a lot of noise

#[\NoDiscard] helps prevent silent mistakes

Fatal errors are more useful now

Practical extension improvements you will actually notice

DOM gets outerHTML

getimagesize() improves support for modern formats

Partitioned cookies are now supported

cURL exposes more diagnostic information

mail() reports failures more honestly

The deprecations are not scary, but they are worth cleaning up

What I would prioritize first in a real migration

1. Try the features that can simplify real code

2. Clean up easy deprecations early

3. Check extension-related behavior where it matters

Final thoughts

Learning Buffalo by Building a Small Helpdesk App in Go

Why Buffalo ?

The Example: HelpDesk Lite

What a Buffalo Project Feels Like

Routing: Very Easy to Read

Actions: The Core of the Request Flow

Pop: Database Work Without Too Much Boilerplate

Migrations: A Good Workflow Once You Understand the Rules

Plush Templates: Familiar, but You Need to Respect the Context

Validation and Error Rendering

Running the App

What I Like About Buffalo

1. It gives Go a more “full-stack framework” feel

2. The request flow is easy to understand

3. Pop and migrations are practical

4. The framework teaches discipline

Building a Simple Notes REST API with Go and Fiber

Why Fiber ?

Project structure

Bootstrapping the Fiber app

Defining the model

Adding an in-memory store

Registering routes

Writing the handlers

Adding middleware

Why this project was useful

The orchestrator: `SynchronizeSourceAction`

The interesting part: `PersistOfferAction`

`#[\NoDiscard]` helps prevent silent mistakes

DOM gets `outerHTML`

`getimagesize()` improves support for modern formats

`mail()` reports failures more honestly