Forem: A0mineTV

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.

Laravel Collections: Why I Use Them for Business Logic (Not Just Convenience)

A0mineTV — Wed, 25 Feb 2026 12:30:42 +0000

When we talk about Laravel, the conversation usually focuses on Eloquent, migrations, or queues. But if I had to pick one feature that improves my day-to-day code quality the most, it would be Laravel Collections.

I don't use them because they look "fancy." I use them because they help me write business logic that is easier to read, maintain, and explain to others.

I use Collections because they help me write business logic in a way that is easier to read, easier to maintain, and easier to explain to another developer.

In short: they help me separate what the code does from how the data is being iterated.

The real problem with `foreach` in business logic

There is nothing wrong with foreach for simple iterations. However, as projects grow, business logic inside loops often turns into:

Nested loops and temporary "accumulator" arrays.
Branching logic (if/else) spread everywhere.
Mixed responsibilities: The code handles how to iterate data and what to do with it at the same time.

This makes the code hard to review, debug, or change without introducing subtle bugs.

That’s the reason I reach for Collections so often.

How I think about it: SQL/Eloquent vs Collections

To keep my projects clean, I follow a strict split of responsibilities:

Database / Eloquent (Data Retrieval): I use SQL for filtering large datasets, joins, and basic aggregates. This reduces the amount of data loaded into memory.
Collections (Business Transformations): Once the data is in PHP, I use Collections for reshaping, grouping, formatting, and applying complex conditional rules.

This separation ensures the database does what it’s good at, while the Collection pipeline handles the business intent.

The database does what it is good at.
The Collection pipeline handles what is easier to express in PHP business logic.

Why Collections improve readability

Collections allow you to write code as a sequence of intentional steps:

Filter out what you don't need.
Transform the data shape.
Group by a specific criteria.
Aggregate (sum, count, etc.).
Sort the result.

That’s a huge difference compared to a loop-heavy approach where those steps are mixed together.

When I read a Collection pipeline, I can usually understand the business intent first.

That matters a lot in real work, because most of the time we are not writing algorithms from scratch — we are maintaining and extending business rules.

A concrete example: top categories from paid orders

Imagine you need to compute revenue per category for paid orders, sorted by the highest earners.

Here is how I would write it with Collections:

$topCategories = collect($orders)
    ->where('status', 'paid')
    ->flatMap(fn ($order) => $order['items'])
    ->groupBy('category')
    ->map(fn ($items, $category) => [
        'category' => $category,
        'revenue'  => $items->sum(
            fn ($item) => $item['price'] * $item['qty']
        ),
        'products' => $items->pluck('name')->unique()->count(),
    ])
    ->sortByDesc('revenue')
    ->take(5)
    ->values();

What I like about this snippet is that I can almost read it as plain English.

It describes the business process step by step.

The same kind of logic with loops gets noisy fast

A loop-based version is absolutely possible.

But it usually introduces:

mutable state ($result, $totals, $seenProducts)
branching logic inside loops
manual initialization
more room for subtle bugs

Something like this (simplified):

$categories = [];

foreach ($orders as $order) {
    if ($order['status'] !== 'paid') {
        continue;
    }

    foreach ($order['items'] as $item) {
        $category = $item['category'];

        if (! isset($categories[$category])) {
            $categories[$category] = [
                'category' => $category,
                'revenue' => 0,
                'products' => [],
            ];
        }

        $categories[$category]['revenue'] += $item['price'] * $item['qty'];
        $categories[$category]['products'][$item['name']] = true;
    }
}

$topCategories = [];

foreach ($categories as $category) {
    $category['products'] = count($category['products']);
    $topCategories[] = $category;
}

usort($topCategories, fn ($a, $b) => $b['revenue'] <=> $a['revenue']);
$topCategories = array_slice($topCategories, 0, 5);

This works.

But the business intent is less obvious because the iteration mechanics are taking center stage.

That’s exactly why I prefer Collections when the transformation is more “business” than “algorithmic”.

Why this scales better in a team

For me, the biggest benefit is not syntax.

It’s team readability.

When code is written as a Collection pipeline, another developer can usually:

scan it quickly
identify each transformation step
modify one step without rewriting everything

That makes refactoring safer.

It also makes code reviews faster, because the intent is explicit.

And in client work or product teams, that matters a lot more than saving 3 lines of code.

The Collection methods I use the most (and why)

Here are the methods I use constantly in Laravel projects:

`filter()` / `reject()`

For cleaning a dataset before doing anything else.

Use case: keep only valid items, paid orders, active users, etc.

`map()`

For transforming the shape of data.

Use case: converting internal arrays/models into API-friendly or UI-friendly output.

`flatMap()`

Great when each item contains a nested list and you want a single flattened list.

Use case: orders → items, users → permissions, posts → tags.

`groupBy()`

One of the most useful methods for reports.

Use case: group by category, day, status, team, source, etc.

`pluck()`

Perfect for extracting a single field quickly.

Use case: IDs, names, emails, labels.

`sum()`, `count()`, `reduce()`

For aggregations.

I use reduce() when I need custom accumulation logic. For simpler totals, sum() and count() are clearer.

`sortBy()` / `sortByDesc()`

For final ordering before returning the result.

Why this works so well with Eloquent

Another reason I use Collections so much: they fit naturally into Laravel’s flow.

You fetch a set of models with Eloquent, and then you can immediately transform them with Collection methods.

That transition from:

retrieved data to
business-ready data is one of the things Laravel does really well.

It makes the backend code feel consistent.

A practical rule I follow (important)

I do not use Collections blindly for everything.

Here’s my rule:

If it is faster, simpler, and more correct in SQL → do it in SQL.
If it is easier to understand as business logic in PHP → use Collections.

This matters because Collections run in PHP memory.

So if I am dealing with a very large dataset, I first reduce the dataset in the query layer, then use Collections for the final transformation.

That balance is usually the sweet spot.

Bonus: use macros for repeated business transformations

One underrated feature is that Collections are macroable.

That means you can define your own reusable Collection methods for recurring transformations.

If your project often computes the same kind of report or formatting, a macro can help standardize that logic and keep pipelines even cleaner.

This is especially useful in larger codebases where business transformations start to repeat.

Final thought

Laravel Collections are not just a convenience API.

For me, they are a design tool for writing clearer backend code.

They help me:

separate retrieval from transformation
express business logic as a pipeline
reduce loop noise
make code easier to maintain

And in real projects, that readability pays off every time.

Laravel Notifications in Practice: Mail, Database, Queues, and Clean Testing

A0mineTV — Fri, 20 Feb 2026 12:21:14 +0000

Notifications look simple at first—until your app grows. You start by sending a quick email from a controller, but soon you need more:

Email and in-app notifications.
Different channels depending on user preferences.
Queued delivery so the UI stays fast.
Clean tests that don't actually hit your SMTP server.

That is exactly where Laravel Notifications shine. They provide a structured way to send short, event-driven messages across multiple channels using a single class.

Laravel gives you a clean, structured way to send short, event-driven messages (like Order shipped, Invoice paid, New comment, Password changed) across multiple channels with one notification class.

In this article, I’ll show a practical setup you can reuse in real projects.

Why use Notifications instead of sending mail directly ?

While you could call Mail::to()->send() everywhere, notifications offer a better architecture:

Centralized logic: One place to define delivery channels via the via() method.
Multi-channel support: Easily switch between or combine mail, database, Slack, and SMS.
Built-in Queues: Native support for background processing.
Observability: Built-in support for testing with Notification::fake().

This makes your code easier to maintain when your app evolves.

A real example: order shipped

Let’s say you have an e-commerce app and want to notify a user when an order is shipped.

We’ll send:

an email notification
an in-app notification stored in the database

Step 1: Generate a notification

php artisan make:notification OrderShipped

Laravel creates a class in app/Notifications/OrderShipped.php.

Step 2: Build the notification class

Here is a practical version:

<?php

namespace App\Notifications;

use App\Models\Order;
use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Notifications\Messages\MailMessage;
use Illuminate\Notifications\Notification;

class OrderShipped extends Notification implements ShouldQueue
{
    use Queueable;

    public function __construct(
        public Order $order
    ) {}

    /**
     * Decide which channels to use.
     */
    public function via(object $notifiable): array
    {
        return ['mail', 'database'];
    }

    /**
     * Email version.
     */
    public function toMail(object $notifiable): MailMessage
    {
        return (new MailMessage)
            ->subject('Your order has been shipped')
            ->greeting('Hello ' . $notifiable->name . ' 👋')
            ->line("Good news! Your order #{$this->order->id} has been shipped.")
            ->action('Track my order', url("/orders/{$this->order->id}"))
            ->line('Thank you for your purchase.');
    }

    /**
     * Database version (stored as JSON in notifications table).
     */
    public function toArray(object $notifiable): array
    {
        return [
            'order_id' => $this->order->id,
            'status' => 'shipped',
            'message' => "Your order #{$this->order->id} has been shipped.",
            'url' => "/orders/{$this->order->id}",
        ];
    }
}

Why this is clean

via() defines the channels in one place
toMail() handles only the email message
toArray() formats the in-app payload
ShouldQueue + Queueable keeps delivery async and your request fast

Step 3: Send the notification

If your User model uses Laravel’s default Notifiable trait (it usually does), sending is straightforward:

$user->notify(new OrderShipped($order));

You can also send to multiple users:

use Illuminate\Support\Facades\Notification;

Notification::send($admins, new OrderShipped($order));

This is super useful for admin alerts, moderation events, or internal ops notifications.

Step 4: Enable database notifications

If you want in-app notifications (bell icon, notification list, unread count), create the notifications table:

php artisan make:notifications-table
php artisan migrate

Laravel stores notification payloads in a notifications table (including the type, JSON data, and read_at status).

Step 5: Display notifications in your app

Because your model uses Notifiable, you get relationships out of the box:

$user->notifications
$user->unreadNotifications
$user->readNotifications

Example in a controller:

public function index(Request $request)
{
    $user = $request->user();

    return response()->json([
        'unread_count' => $user->unreadNotifications()->count(),
        'items' => $user->notifications()->latest()->limit(20)->get(),
    ]);
}

This is enough to build a simple notification center in Vue / React / Blade.

Step 6: Mark notifications as read

A common pattern: when a user opens the notification list, mark unread notifications as read.

public function markAllAsRead(Request $request)
{
    $request->user()->unreadNotifications->markAsRead();

    return response()->json(['message' => 'Notifications marked as read']);
}

For large volumes, you can also use a direct query update (more efficient than looping in memory).

Step 7: Keep your app fast with queues

Notifications often call external services (SMTP, Slack, SMS providers), so they should usually be queued.

We already added:

implements ShouldQueue
use Queueable

Now make sure your queue is configured and a worker is running (Redis is a great choice in production).

Example local setup:

QUEUE_CONNECTION=database

Then run:

php artisan queue:work

Why queueing matters

Without queues:

user clicks a button
request waits for email/SMS API
response feels slower

With queues:

notification job is pushed to the queue
request returns quickly
worker sends the notification in the background

This becomes a big win as soon as you have real traffic.

Step 8: Test notifications cleanly

One of Laravel’s best features here is Notification::fake().

It lets you test behavior without sending anything.

use App\Models\Order;
use App\Models\User;
use App\Notifications\OrderShipped;
use Illuminate\Support\Facades\Notification;

it('notifies the user when an order is shipped', function () {
    Notification::fake();

    $user = User::factory()->create();
    $order = Order::factory()->create(['user_id' => $user->id]);

    // Your application logic...
    $user->notify(new OrderShipped($order));

    Notification::assertSentTo($user, OrderShipped::class);
});

This keeps tests fast, reliable, and focused on your business logic.

A practical pattern I like

In real projects, I usually trigger notifications after a state change in a service/action class.

Example:

class ShipOrderAction
{
    public function handle(Order $order): void
    {
        $order->update(['status' => 'shipped']);

        $order->user->notify(new OrderShipped($order));
    }
}

Why this works well:

controller stays thin
notification logic is tied to the domain action
easy to test
easy to reuse from HTTP, CLI, or jobs

Common mistakes to avoid

1) Sending notifications directly in controllers everywhere

It works at first, but it spreads your logic across the app.

2) Forgetting to queue notifications

Mail and third-party channels can slow down your requests a lot.

3) Overloading notifications with business logic

Keep notifications focused on delivery + presentation.

Your business rules should live in services/actions.

4) Mixing database and broadcast payloads without thinking

If your database payload and realtime frontend payload need to differ, define toDatabase() and toBroadcast() separately instead of relying on one toArray() for both.

Bonus ideas for production projects

Once your base setup is working, Laravel Notifications scale really well:

Admin alerts (new signup, failed payment, suspicious login)
User activity (comment replies, mentions, reminders)
Subscription events (trial ending, invoice paid, renewal failed)
Realtime UI notifications with broadcasting
Channel preferences (email only, app only, both)

You can even make the via() method dynamic:

public function via(object $notifiable): array
{
    return $notifiable->wants_email_notifications
        ? ['mail', 'database']
        : ['database'];
}

That’s a very clean way to support user preferences.

Final thoughts

Laravel Notifications are simple to start with, but very powerful when your app grows.

They give you a consistent structure for:

deciding where a message should be sent
formatting it for each channel
queueing it for performance
testing it safely

If you’re building Laravel apps with user workflows (orders, bookings, payments, accounts, dashboards), Notifications are one of those features that quickly become foundational.

Forem: A0mineTV

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

Where to go next

Final thoughts

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

What we're building

Project structure

The model

The storage interface

The service layer

The in-memory storage

The HTTP handler

Wiring it all together

Try it out

Key takeaways

Building a Deterministic Password CLI in Go with Argon2id

The idea

Why this is interesting

Project structure

How the generator works

1. Parse CLI options

2. Normalize the label

3. Turn the label into a salt

4. Derive a seed with Argon2id

5. Build a deterministic byte stream

6. Build the password from character groups

A small project, but a good set of lessons

Random generation vs deterministic derivation

`#[\NoDiscard]` helps prevent silent mistakes

DOM gets `outerHTML`

`getimagesize()` improves support for modern formats

`mail()` reports failures more honestly