DEV Community: Alex Beygi

How to Build a Great Dev Team (That Actually Works)

Alex Beygi — Tue, 17 Mar 2026 13:40:14 +0000

Building a high-performing development team isn’t just about hiring the best engineers or choosing the right tech stack. Many companies obsess over systems, processes, and productivity frameworks—but overlook the most important factor:

1. Start With a People-First Culture

When building a team, the instinct is often to optimize for performance: faster delivery, better output, more efficiency.

But here’s the paradox:

The most productive teams are not the most pressured—they are the most supported.

When people feel safe, respected, and valued, they naturally perform better. A healthy environment creates:

Higher engagement
Better collaboration
Stronger long-term output

If you build the best system in the world but place the wrong people in it, it will fail.
People are the foundation—not the system.

2. Trust Is Everything

At the core of every great team is one thing: trust.

Without trust

Processes break down
Communication becomes defensive
Productivity drops

Many organisations try to fix problems by adding more rules and policies. But often, these systems are just “scar tissue”—reactions to past mistakes rather than real solutions.

Instead of asking:

“How do we prevent this from ever happening again?”

ASK:

“Why did this happen in the first place?”

Great teams solve root problems, not just symptoms.

3. Hire the Right People—and the Right Managers

A strong culture starts at the top—but it doesn’t survive unless it flows through good managers.

A great manager is:

Empathetic
Honest
Supportive
Willing to advocate for their team

Ask yourself this simple question:

“Would I want to work for this person?”

Great managers don’t just report problems—they:

Defend their team
Support growth
Even challenge leadership when needed

Bad managers, on the other hand, can destroy even the best culture.

4. Define Your Values Clearly

Before hiring or scaling your team, you need clarity:

What does success look like?
What do we stand for?
What behaviors do we reward—and reject?

Without clear values:

Good people may still fail
Teams become misaligned
Expectations become unclear

Strong values create:

Alignment
Psychological safety
Better decision-making

For example, a healthy dev team might value:

Work-life balance over hustle culture
Diversity of thought (“weird means interesting”)
Psychological safety (“you’ve already made it”)

Values aren’t just words—they guide hiring, feedback, and daily behavior.

5. Integrity Over Image

It’s easy to talk about culture.
It’s much harder to live it—especially when things go wrong.

True integrity means:

Being consistent in good and bad times
Doing what you said you would do
Not overpromising

Many leaders act supportive—until pressure hits.
That’s when real culture is revealed.

Integrity means being the same person in every situation.

If your team can rely on that consistency, trust grows naturally.

6. Build a Culture of Radical Candor

One of the biggest killers of team performance is poor communication.

Great teams practice radical candor:

Be honest
Be direct
Be kind

This doesn’t mean being harsh.
It means caring enough to tell the truth—even when it’s uncomfortable.

A strong communication culture looks like:

Feedback is immediate, not delayed
Problems are discussed openly
Conflict is handled constructively

Many teams avoid difficult conversations in the name of “being nice.”
But that creates hidden frustration and toxicity.

Healthy teams don’t avoid conflict—they handle it well.

7. Encourage Collaboration Over Competition

In weak cultures:

Developers compete
Knowledge is hoarded
People protect their position

In strong cultures:

Developers help each other
Knowledge is shared
The team grows together

The goal is to create a “team brain”—where:

Everyone contributes
Everyone learns
Everyone supports

This leads to:

Faster problem solving
Better innovation
Stronger team cohesion

8. Support Your Team Beyond Work

A great dev team isn’t just about code—it’s about life.

If your team is worried about:

Health
Family
Finances

They can’t perform at their best.

Support can include:

Flexible working hours
Learning budgets (books, courses, conferences)
Health and wellbeing support
Real understanding of personal challenges

The best companies ask:

“What matters most to our people—and how can we help?”

9. Create the Workplace You’d Want

This is the ultimate test:

If you were an employee, would you want to work here?

Think about:

Communication style
Work-life balance
Leadership behavior
Growth opportunities

If the answer is no, something needs to change.

Final Thoughts

Building a great development team isn’t about:

Hiring “10x developers”
Forcing productivity
Adding more processes

It’s about:

Trust
Communication
Integrity
Care

When you focus on people first, everything else follows.

Build a place where people want to work—and you’ll naturally build a team that performs.

Understanding RabbitMQ Exchange Types: Direct, Fanout, and Topic

Alex Beygi — Sun, 08 Feb 2026 16:40:58 +0000

RabbitMQ is a message broker that implements the AMQP (Advanced Message Queuing Protocol). At the heart of RabbitMQ’s routing model lies the exchange. Exchanges are responsible for receiving messages from producers and routing them to one or more queues based on defined rules.

Choosing the correct exchange type is critical for building scalable, correct, and maintainable systems—especially in real-time systems such as chat, notifications, and event-driven architectures.

This article explains the three most commonly used exchange types—Direct, Fanout, and Topic—and demonstrates how each routes messages, when to use them, and common mistakes to avoid.

Core Concepts Recap

Before diving into exchange types, it’s important to understand a few fundamental components:

Producer: Sends messages to an exchange.
Exchange: Routes messages to queues based on rules.
Queue: Stores messages until they are consumed.
Binding: A rule that links a queue to an exchange.
Routing Key: A string attached to a message, used by the exchange to decide where the message goes.

An exchange never stores messages. It only decides where messages should be routed.

1. Direct Exchange

How Direct Exchange Works
A direct exchange routes messages to queues only if the routing key exactly matches the binding key.

Routing is deterministic
Matching is strict equality
No pattern matching is performed

Let's take at a PHP/Laravel example:

Install the client:

composer require php-amqplib/php-amqplib

Example .env

Q_HOST=127.0.0.1
MQ_PORT=5672
MQ_USER=guest
MQ_PASS=guest
MQ_VHOST=/

Typical connection factory (recommended to reuse in services):

use PhpAmqpLib\Connection\AMQPStreamConnection;
 embed function mqConnection(): AMQPStreamConnection {
    return new AMQPStreamConnection(
        env('MQ_HOST'),
        env('MQ_PORT'),
        env('MQ_USER'),
        env('MQ_PASS'),
        env('MQ_VHOST')
    ); 
}

Publish to a Direct Exchange

use PhpAmqpLib\Message\AMQPMessage;

public function publishOrderCreated(array $payload)
{
    $connection = mqConnection();
    $channel = $connection->channel();

    $exchange = 'orders.direct';
    $queue    = 'orders.created.queue';
    $key      = 'order.created';

    // Topology
    $channel->exchange_declare($exchange, 'direct', false, true, false);
    $channel->queue_declare($queue, false, true, false, false);
    $channel->queue_bind($queue, $exchange, $key);

    $msg = new AMQPMessage(json_encode($payload), [
        'content_type'  => 'application/json',
        'delivery_mode' => AMQPMessage::DELIVERY_MODE_PERSISTENT,
    ]);

    $channel->basic_publish($msg, $exchange, $key);

    $channel->close();
    $connection->close();
}

Consumer for a Direct Queue (manual ack)

$channel->basic_qos(null, 1, null);

$channel->basic_consume('orders.created.queue', '', false, false, false, false,
    function ($msg) {
        $data = json_decode($msg->body, true);

        try {
            // process...
            $msg->ack();
        } catch (\Throwable $e) {
            $msg->nack(false, true); // requeue on failure
        }
    }
);

while ($channel->is_consuming()) {
    $channel->wait();
}

When to Use Direct Exchange

Task queues (background jobs)

Worker pools

Point-to-point messaging
Routing messages to a specific consumer group

Characteristics

✔ Predictable routing
✔ High performance
❌ Not suitable for broadcast
❌ No pattern matching

2. Fanout Exchange

How Fanout Exchange Works

A fanout exchange routes messages to all bound queues, ignoring the routing key entirely.

Routing key is irrelevant
Every bound queue receives a copy
Pure broadcast semantics

Visual Explanation

In the diagram’s Fanout Exchange section:

The producer sends a message
The fanout exchange delivers the message to Queue X, Queue Y, and Queue Z
All consumers receive the same message independently

When to Use (Chat Example)

Fanout is perfect when multiple servers must receive the same message, such as a chat system where multiple WebSocket nodes need to forward messages to connected clients.

Example:

ws.node1.queue
ws.node2.queue
ws.node3.queue

Every node receives the message and delivers it to clients connected to that node.

Laravel Example: Publish to Fanout (Chat Broadcast)

use PhpAmqpLib\Message\AMQPMessage;

public function broadcastChatMessage(array $payload)
{
    $connection = mqConnection();
    $channel = $connection->channel();

    $exchange = 'chat.fanout';

    $channel->exchange_declare($exchange, 'fanout', false, true, false);

    $msg = new AMQPMessage(json_encode($payload), [
        'content_type' => 'application/json',
    ]);

    // routing key is ignored for fanout; pass '' conventionally
    $channel->basic_publish($msg, $exchange, '');

    $channel->close();
    $connection->close();
}

Fanout Consumers: Each server has its own queue

On WebSocket Server 1:

$exchange = 'chat.fanout';
$queue = 'ws.server1.queue';

$channel->exchange_declare($exchange, 'fanout', false, true, false);
$channel->queue_declare($queue, false, true, false, false);
$channel->queue_bind($queue, $exchange);

$channel->basic_consume($queue, '', false, true, false, false, function($msg) {
    // push to local websocket clients
    echo "server1 received: {$msg->body}\n";
});

On WebSocket Server 2: same pattern but ws.server2.queue.

Result: all websocket servers receive each message and forward to their connected users.

3. Topic Exchange

How Topic Exchange Works

A topic exchange routes messages using pattern matching on routing keys.

Topic exchanges route messages based on patterns in routing keys (dot-separated words):

Wildcards:

* matches exactly one word # matches zero or more words

Example routing key:

embed logs.error.app1

Example bindings:

logs.error.* ✅
logs.*.app1 ✅
logs.# ✅

Topic is best for:

event buses in microservices
routing by domain + action + sub-type
logging/event pipelines

Laravel Example: Topic Exchange for Events

use PhpAmqpLib\Message\AMQPMessage;

public function publishEvent(string $routingKey, array $payload)
{
    $connection = mqConnection();
    $channel = $connection->channel();

    $exchange = 'events.topic';

    $channel->exchange_declare($exchange, 'topic', false, true, false);

    $msg = new AMQPMessage(json_encode($payload), [
        'content_type' => 'application/json',
    ]);

    $channel->basic_publish($msg, $exchange, $routingKey);

    $channel->close();
    $connection->close();
}

Bind Consumers by Pattern

All logs for app1:

$queue = 'logs.app1.all.queue';
$channel->queue_declare($queue, false, true, false, false);
$channel->queue_bind($queue, 'events.topic', 'logs.#.app1');

Everything:

$queue = 'logs.all.queue';
$channel->queue_bind($queue, 'events.topic', '#');

Direct vs Fanout vs Topic: Choosing Correctly

Requirement	Best Exchange
One specific queue processes each message	Direct
Broadcast to every consumer	Fanout
Flexible routing with patterns	Topic
Chat broadcast to many WebSocket nodes	Fanout
Event bus across services	Topic
Worker queues (jobs)	Direct

Common Production Notes (Laravel):

1) Don’t auto-ack unless losing messages is acceptable

In your earlier consumer, you used no_ack=true. That makes delivery at-most-once (messages can be lost on crash). For real systems, prefer manual ack.

2) Use durable topology for reliability

Use:

durable=true for exchanges/queues
delivery_mode=PERSISTENT for messages

3) Prefer long-running workers (Artisan + Supervisor)

Consumers should be CLI workers (Supervisor/systemd/Docker), not HTTP requests.

Conclusion

Direct: exact routing, ideal for job workers.
Fanout: pure broadcast, perfect for chat/WebSocket clusters.
Topic: pattern routing, best for event buses and log pipelines.

The Rising Complexity of Modern CSS

Alex Beygi — Wed, 26 Nov 2025 10:07:59 +0000

Modern CSS is nothing short of incredible. It gives us the tools to craft rich, interactive, and visually stunning experiences on the web. But with this surge in capability comes a new weakness—not in CSS itself, but in the way we work with it.

When I started my career as a web developer, writing CSS often meant inventing hacks to work around what it couldn’t do. Those days are far behind us. Today, CSS offers advanced layout systems, 3D transformations, and highly flexible animation tools.

Yet most of the challenges we face in modern CSS aren’t about missing features—they stem from how we author it. This is why the future of CSS might not live in plain text files at all, but in visual creation tools.

That idea might sound outrageous at first, but bear with me—I’ll try to make the case.

The Growing Complexity of Color

Developers have spent years building intuition around HEX and RGB. But new colour models like OKLCH require us to rethink that mental map entirely. You might instantly recognise a colour like #FF00FF, but oklch(0.7017 0.3225 328.36) is far less intuitive.

In the 2025 State of CSS survey, only 12% of respondents said they had tried any of the new level-4, wide-gamut color spaces and had a positive experience.

Gradients: A Perfect Case for Visual Tools

Gradients are a clear example of where visual editors shine.

Without something like https://gradient.style, working with gradients quickly becomes frustrating. Human brains simply aren’t built to imagine what a gradient such as:

linear-gradient(in srgb, 37deg, #8dea81 0%, #92d3d2 100%)

will look like—especially when different interpolation colour spaces can dramatically alter the result.

Animations: Even More Dependent on Visual Editing

Nowhere is this issue more apparent than with animation timing functions.

Translating sets of coordinates into a bezier curve—and then picturing how that curve will animate an element—is not something most people can do mentally. Tools that allow you to see and manipulate these curves visually are essentially required.

The newer linear() interpolation function unlocks some amazing possibilities—like mimicking realistic physical motion—but creating “spring” or “bounce” curves manually is nearly impossible without visual guidance.

Keyframe animations have the same problem. Basic from/to sequences are simple enough, but once you introduce multiple keyframes, editing and fine-tuning them becomes tedious. A dedicated keyframe editor removes that friction entirely.

Falling Behind the CSS Working Group

In the past, browser support was the main obstacle to adopting new CSS features. That’s no longer true. For example, offset-path has been fully supported in all major browsers since 2022—yet in the 2025 State of CSS survey, only 30% of participants even knew it existed.

As the specification grows, remembering how each feature works becomes increasingly difficult. Many new CSS capabilities see slow adoption simply because developers can’t keep up.

More Advanced Features on the Horizon

The brand-new shape() and path() functions are incredibly powerful, but crafting them manually can be tedious.

clip‑path: shape(from 87% 0.5%, hline to 1%, curve to 16% 52% with 1% 1% / 17% 17%, curve to 1% 100% with 16% 87% / 1% 100%, hline to 87%, curve to 100% 52% with 87% 100% / 100% 89%, curve to 87% 1% with 100% 15% / 87% 1%, close);

Other impressive features—like mask-image, offset-path, and conic-gradient—will likely remain underused simply because writing the CSS for them is so complex.

A New Era of CSS Tools

CSS has grown beyond what traditional text editors are comfortable handling—and that’s worth celebrating. Many developers already rely on visual tools to build gradients, paths, and animation timing functions, but these tools can go even further.

Not only do visual tools make it easier to define colours, gradients, and animations—they also introduce developers to features they may not have known about.

When new CSS capabilities are paired with intuitive visual interfaces, they become far more approachable and much easier to incorporate into everyday work.

Everything about Next.js 16

Alex Beygi — Thu, 13 Nov 2025 09:16:14 +0000

Next.js 16 is here, and it brings one of the most polished releases the framework has seen in a while. Instead of chasing big rewrites, this version focuses on the fundamentals, faster builds, predictable caching, smarter routing, and better developer visibility.

And if you’re deploying on Appwrite Sites, you can start using Next.js 16 today. The latest release is fully supported, so you can build, test, and host your Next.js projects seamlessly on Appwrite’s open-source infrastructure.

Many of the features introduced in earlier betas are now stable and production-ready, giving developers more control and consistency across their workflows.

Here’s what’s new, what’s changed, and why it matters for anyone building with Next.js today.

Cache components

Caching in Next.js used to be a bit of a mystery. Sometimes your data was cached when you didn’t want it to be; other times it wasn’t cached at all. You’d deploy, see stale data, and wonder if the problem was in your code or in the framework.

Next.js 16 fixes that by introducing Cache Components: A new, explicit caching model. Instead of Next.js deciding what to cache, you tell it what should be cached and when to revalidate.

It’s built on top of Partial Pre-rendering (PPR), which already blurred the line between static and dynamic pages. Together, they make rendering predictable and flexible.

Next.js DevTools MCP

One of the more forward-looking additions in this release is Next.js DevTools MCP.

It hooks into the Model Context Protocol (MCP), which lets AI tools and agents understand your project’s context, your routing, caching, and rendering behaviour.

Why does that matter? Because AI that actually knows how your app works can give better debugging help, clearer explanations, and smarter suggestions. Instead of just dumping stack traces, it can reason about what’s happening under the hood.

It’s still early, but it points toward a future where your dev tools don’t just react to errors, they understand them.

proxy.ts

The old middleware.ts file is now proxy.ts. That’s it. Same behaviour, better name.

There has been a lot of confusion around how middlewares work in Next.js. These middlewares are not your typical middlewares. You’re at the mercy of any network calls you make in these middlewares, as a single slow network call may block the initial load of your entire webpage, which is not ideal. Middlewares in Next.js are used to do something lightweight, for example, redirecting users based on the authentication cookies stored. Since the term middleware continued to cause issues, the Next.js team finally decided to rename it to proxy so that the purpose of using it is clear.

Logging improvements

Next.js 16 also improves logs, and not in a superficial “we added colours” way.

Build and dev logs now show where time is spent, breaking down compilation, rendering, and optimization steps. So if your build suddenly feels slower, you can immediately tell which parts are to blame.

It’s a quiet but practical improvement that makes day-to-day development just a little less frustrating.

Turbopack update

Turbopack has officially graduated from beta and is now the default bundler for all new Next.js projects.

It’s fast, like 2–5× faster builds and up to 10× faster Fast Refresh. For large projects, filesystem caching (currently in beta) further cuts down on startup times by reusing compiled artifacts between sessions.

You’ll notice the difference most if you’re in that constant build, refresh–iterate loop all day. It’s less about benchmarks and more about getting back into flow faster.

Build Adapters API

If you’ve ever had to deploy a Next.js app in an unusual environment, say, outside Vercel, this one’s for you.

Build Adapters, now in alpha, let you hook into the build process and modify it without forking the framework. It’s especially handy for teams self-hosting or building custom pipelines.

This update shows that Next.js is starting to take flexibility seriously for developers running the framework in different environments.

React compiler support

Next.js 16 now includes stable support for the React Compiler, which automatically memoizes components to cut down on unnecessary re-renders.

You don’t have to sprinkle useMemo or useCallback everywhere. The compiler handles it. There’s a small tradeoff in build time since it uses Babel, but the performance gains in rendering make it worthwhile for complex UI-heavy apps.

Routing and Prefetching

Routing has seen a major under-the-hood upgrade.

Prefetching is now more efficient thanks to layout deduplication. Shared layouts download once, even if you prefetch dozens of links. And incremental prefetching ensures that only what's missing gets fetched instead of entire pages.

It even cancels prefetch requests when links leave the viewport. You won’t have to change your code to benefit. Everything just feels snappier.

Refined caching APIs

Caching APIs have been cleaned up and made more explicit.

The updated revalidateTag() now takes a cache-life profile, letting you fine-tune how data revalidates. The new updateTag() API adds “read-your-writes” behavior, so when users make changes, they see them reflected right away. And refresh() handles refreshing uncached data like live counts or notifications.

Together, these updates turn caching into a transparent system that behaves exactly how you expect, not how the framework guesses you want it to.

React 19.2 and Core Updates
Next.js 16 ships with React 19.2, which brings some nice quality-of-life improvements:

useEffectEvent() for cleaner effect logic
View Transitions for smoother navigation
The new component for managing background UI states

The release also updates core requirements. You’ll need Node.js 20.9+, TypeScript 5.1+, and modern browsers. Old features like AMP support and the next lint command are gone, making the framework leaner overall.

Wrapping up

Next.js 16 isn’t a release that changes how you build. It’s one that changes how your build feels. Caching is now predictable. Builds are faster. Routing is leaner. Logs are clearer.

And with Appwrite Sites now supporting Next.js 16, you can deploy and host your latest projects right away, from development to production, on fully open-source infrastructure. Whether you’re experimenting with Cache Components, testing Turbopack, or building production apps, everything runs smoothly on Appwrite Sites.

[Boost]

Alex Beygi — Fri, 01 Aug 2025 14:56:13 +0000

Understanding JavaScript Symbol - A Unique Identifier

Alex Beygi ・ Aug 1

#javascript #frontend

Understanding JavaScript Symbol - A Unique Identifier

Alex Beygi — Fri, 01 Aug 2025 14:55:46 +0000

In JavaScript, Symbol("Alex") is a way to create a unique identifier.

Symbols are a special data type in JavaScript. Even if you create two symbols with the same description ("Alex" in this case), they will always be unique.

Key Points About Symbols
Creating a Symbol:

const mySymbol = Symbol("Alex");
console.log(mySymbol); // Outputs: Symbol(Alex)

Uniqueness:

Even if you do this:

const symbol1 = Symbol("Alex");
const symbol2 = Symbol("Alex");
console.log(symbol1 === symbol2); // Outputs: false

The two symbols are different, even if they have the same description.

Why Use Symbols?

Object Properties: Symbols can be used as unique keys for object properties. They avoid naming conflicts because no two symbols are the same.

They are useful for creating "hidden" properties that won't conflict with other keys.

Practical Example: Avoiding Key Conflicts
Here's how to use a Symbol to avoid property name conflicts in an object.

// Example with Symbols
const symId = Symbol("id");

const user = {
   name: "Alex",
   [symId]: 12345 // Symbol is used as a unique property key
};

console.log(user); 
// Outputs: { name: 'Alex', [Symbol(id)]: 12345 }

// Accessing the Symbol property
console.log(user[symId]); // Outputs: 12345

// Another script cannot accidentally overwrite this property:
user["id"] = 67890; // Regular key
console.log(user.id); // Outputs: 67890 (regular key)
console.log(user[symId]); // Still Outputs: 12345 (symbol key is untouched)

Key Benefits
Symbols Prevent Key Overlaps: The Symbol key (symId) and the regular string key ("id") don't clash.

Hidden Properties: Symbols don't show up in regular for...in or Object.keys() loops.

This makes symbols very useful for internal object properties that you want to stay hidden or unique.

[Boost]

Alex Beygi — Fri, 01 Aug 2025 12:41:21 +0000

Redis Pub/Sub vs Laravel Reverb: Real-Time Laravel at Its Best

Alex Beygi ・ Aug 1

#laravel #websocket #redis #socketio

Redis Pub/Sub vs Laravel Reverb: Real-Time Laravel at Its Best

Alex Beygi — Fri, 01 Aug 2025 07:46:09 +0000

Both Redis Pub/Sub and Laravel Reverb can be used for real-time functionality in Laravel applications, but they address different layers of the real-time stack and have distinct benefits and use cases:

Redis Pub/Sub is a messaging paradigm where publishers send messages to channels, and subscribers listen to those channels. It's fast, lightweight, and widely used for real-time messaging.

Laravel Reverb is Laravel's first-party WebSocket server introduced in Laravel 11, aiming to offer a robust real-time solution tightly integrated with Laravel’s broadcasting system.

Feature	Redis Pub/Sub	Laravel Reverb
Speed	Extremely fast (in-memory)	Fast with persistent WebSocket connections
Latency	Sub-millisecond	Sub-millisecond (depending on network/WebSocket load)
Horizontal Scaling	Tricky (no persistence)	Cluster support, queue integration
Message Durability	None (ephemeral)	Optional via queues and Redis
Connection Type	Stateless	Persistent (WebSocket)

Performance

Redis Pub/Sub
Speed: Extremely fast due to being in-memory and low-overhead.

Latency: Sub-millisecond for local setups.

Horizontal Scaling: Pub/Sub doesn't support message persistence or queuing, which can be a limitation in distributed systems.

Load Handling: Handles high-throughput messaging, but can drop messages if subscribers disconnect.

Redis::publish('channel-name', json_encode(['message' => 'Hello']));

On the subscriber side, you'd need a separate process (often in Node.js or Go) to receive messages and forward to clients.

Laravel Reverb
Speed: Built on top of FrankenPHP or Swoole, it's designed for high concurrency and persistent WebSocket connections.

Latency: Excellent for WebSocket-based communication; real-time delivery with persistent connections.

Horizontal Scaling: Supports clustering and integrates tightly with Laravel queues and Redis.

Reliability: Built-in reconnection and session handling. More resilient than raw Pub/Sub.

Example:

Broadcasting Event:

event(new MessageSent($message));

Client Side (with Laravel Echo):

Echo.channel('chat')
    .listen('MessageSent', (e) => {
        console.log(e.message);
    });

Verdict:
Redis Pub/Sub is ideal for backend-to-backend communication or ephemeral events.

Reverb shines in persistent client communication and scales more gracefully in Laravel-native projects.

Conclusion
If you're looking to build real-time features in Laravel, Laravel Reverb is the clear winner in terms of usability, integration, and developer experience. It’s made for Laravel, integrates with everything you already use, and takes away the pain of setting up a real-time infrastructure.

That said, Redis Pub/Sub is still a great choice for lightweight, internal messaging systems or cross-service communication where WebSockets aren't needed.

Leveraging Laravel Actions for Cleaner, Reusable Code

Alex Beygi — Thu, 31 Jul 2025 21:26:45 +0000

Laravel Actions are a design pattern used to encapsulate specific units of work—such as creating a user, sending an email, or processing a queue—into individual, reusable classes. Instead of bloating your controller or service classes, Actions help you isolate the logic into small, single-purpose files.

Think of an Action as a method that does one thing and does it well, but it's wrapped inside a class to promote clarity, testability, and reuse.

Why Use Laravel Actions?

Using Actions in Laravel can greatly enhance your codebase. Here’s why:

1. Separation of Concerns
Instead of having bloated controllers or services with mixed responsibilities, each Action handles a single task.

Example: You can move the logic for creating a user from your controller into a CreateUserAction class.

2. Reusability
Actions can be used across controllers, jobs, commands, or even tests without duplicating logic.

Example: The same CreateInvoiceAction can be used in a web controller and a scheduled command.

3. Testability
Since Actions are standalone classes, they can be easily tested in isolation without relying on the full controller or service environment.

Example: You can write a unit test for SendWelcomeEmailAction without mocking any controller behaviour.

4. Cleaner Codebase
Controllers become thin and focused on request/response handling. Business logic lives in Actions.

Example: A controller method becomes just 3 lines: validate, call action, return response.

Installing Laravel Actions (by Loris Leiva)

You can build Actions manually, but the lorisleiva/laravel-actions package makes it much more elegant.

composer require lorisleiva/laravel-actions

Practical Examples:

Example 1: Action for Validation and Creating a Post

app/Actions/Post/CreatePostAction.php

namespace App\Actions\Post;

use App\Models\Post;
use Lorisleiva\Actions\Concerns\AsAction;

class CreatePost
{
    /**
     * Handle the creation of a new post.
     */
    public function handle(array $data): Post
    {
        return Post::create($data);
    }

    /**
     * Validation rules for the request.
     */
    public function rules(): array
    {
        return [
            'title' => 'required|string|max:255',
            'content' => 'required|string',
        ];
    }

    /**
     * Invoke method used by Laravel's route to execute the action.
     */
    public function __invoke(Request $request): Post
    {
        $validated = $request->validate($this->rules());
        return $this->handle($validated);
    }
}

Route Example

use App\Actions\Post\CreatePost;

Route::post('/posts', CreatePost::class);

Example 2: Action for Running a Queue Job

// app/Actions/User/SendWelcomeEmailAction.php

namespace App\Actions\User;

use App\Jobs\SendWelcomeEmail;

class SendWelcomeEmailAction
{
    public function execute($user)
    {
        SendWelcomeEmail::dispatch($user);
    }
}
Usage in Controller or Listener:

$action = app(SendWelcomeEmailAction::class);
$action->execute($user);

How to Implement Actions

There are multiple ways to structure your Actions:
Manually create them in a Actions namespace.

Example using the package:

php artisan make:action CreateUser

And then:

public function handle(array $data)
{
    // Business logic
}

When to Use Laravel Actions?

Use Actions when:

A piece of logic is repeated across different parts of your application.
Your controller methods are growing too large.
You want to improve unit testing and readability.
You are building a service-oriented or domain-driven architecture.

Conclusion

Laravel Actions are a powerful tool to improve the architecture of your Laravel application. They promote clean code, reusability, and testability, while reducing the cognitive load in your controllers. Whether you're validating requests, running queues, or performing business logic, wrapping that logic in Actions will lead to a more maintainable and scalable application.