Forem: Laravel Mastery

Strategy Pattern in Laravel: Clean Payment Processing

Laravel Mastery — Tue, 06 Jan 2026 12:43:19 +0000

The Problem 😫
Ever seen code like this?

public function processPayment(Request $request)
{
    $method = $request->payment_method;

    if ($method === 'credit_card') {
        // 50 lines of credit card logic...
    } elseif ($method === 'paypal') {
        // 40 lines of PayPal logic...
    } elseif ($method === 'crypto') {
        // 60 lines of crypto logic...
    } // ... more conditions
}

This creates:

200+ line methods
Untestable code
Maintenance nightmares
SOLID violations

The Solution: Strategy Pattern ✨

The Strategy Pattern encapsulates algorithms into separate classes, making them interchangeable.

Step 1: Define the Interface

interface PaymentStrategyInterface
{
    public function pay(float $amount, array $details): array;
    public function validate(array $details): bool;
    public function refund(string $transactionId, float $amount): array;
}

Step 2: Create Concrete Strategies

class CreditCardStrategy implements PaymentStrategyInterface
{
    public function pay(float $amount, array $details): array
    {
        // Credit card processing logic
        return [
            'success' => true,
            'transaction_id' => 'txn_' . uniqid(),
        ];
    }

    public function validate(array $details): bool
    {
        return !empty($details['card_number']) && 
               !empty($details['cvv']);
    }

    public function refund(string $transactionId, float $amount): array
    {
        // Refund logic
        return ['success' => true];
    }
}

class PayPalStrategy implements PaymentStrategyInterface
{
    public function pay(float $amount, array $details): array
    {
        // PayPal processing logic
        return [
            'success' => true,
            'transaction_id' => 'pp_' . uniqid(),
        ];
    }

    public function validate(array $details): bool
    {
        return !empty($details['email']) && 
               filter_var($details['email'], FILTER_VALIDATE_EMAIL);
    }

    public function refund(string $transactionId, float $amount): array
    {
        return ['success' => true];
    }
}

Step 3: Create Strategy Factory

class PaymentStrategyFactory
{
    public function create(string $method): PaymentStrategyInterface
    {
        return match($method) {
            'credit_card' => new CreditCardStrategy(),
            'paypal' => new PayPalStrategy(),
            'crypto' => new CryptoStrategy(),
            default => throw new \InvalidArgumentException("Unknown method: {$method}"),
        };
    }
}

Step 4: Use in Controller

class OrderController extends Controller
{
    public function __construct(
        private PaymentStrategyFactory $factory
    ) {}

    public function processPayment(Request $request)
    {
        $strategy = $this->factory->create($request->payment_method);

        if (!$strategy->validate($request->payment_details)) {
            return response()->json(['error' => 'Invalid details'], 400);
        }

        $result = $strategy->pay(
            $request->amount,
            $request->payment_details
        );

        return response()->json($result);
    }
}

Benefits 🎯
✅ Single Responsibility - Each strategy handles one method
✅ Open/Closed - Add new methods without modifying existing code
✅ Easy Testing - Test each strategy independently
✅ Maintainable - Clear separation of concerns
✅ Flexible - Swap strategies at runtime

Testing Example

class CreditCardStrategyTest extends TestCase
{
    public function test_validates_card_details(): void
    {
        $strategy = new CreditCardStrategy();

        $valid = $strategy->validate([
            'card_number' => '4532015112830366',
            'cvv' => '123',
        ]);

        $this->assertTrue($valid);
    }
}

Real-World Use Cases 💡

Use Strategy Pattern for:

Payments - Credit cards, PayPal, Crypto
Storage - S3, Local, DigitalOcean
Notifications - Email, SMS, Slack
Authentication - OAuth, LDAP, JWT
Export - PDF, Excel, CSV

Read the Full Article 📖
Want the complete implementation with advanced techniques, more examples, and best practices?
Read the full article on Medium
The full version includes:

Complete payment gateway integrations
Advanced dynamic strategy selection
Comprehensive unit tests
Service provider configuration
Error handling patterns
Real production examples

Quick Takeaway
Transform this mess:

if ($method === 'x') { /* 50 lines */ }
elseif ($method === 'y') { /* 40 lines */ }

Into this elegance:

$strategy = $factory->create($method);
$result = $strategy->pay($amount, $details);

Your code will thank you! 🚀

What design patterns do you use in Laravel? Share in the comments!

Mastering the Factory Pattern in Laravel: Challenges, Solutions & Real-World Magic ✨

Laravel Mastery — Sun, 04 Jan 2026 07:37:24 +0000

What Exactly is the Factory Pattern?

Think of a factory pattern like a car manufacturing plant. Instead of handcrafting each car part by part, you have a standardized process that produces vehicles based on specifications. In Laravel, the Factory Pattern creates objects without exposing the creation logic to the client and refers to the newly created object through a common interface.

Why Should You Care?

Before we jump into the challenges, let me tell you why this matters:

Testing becomes a breeze - Generate realistic test data in seconds
Consistency across your app - Same object creation logic everywhere
Cleaner code - No more messy object instantiation scattered around
Rapid prototyping - Spin up demo data faster than you can say "php artisan"

Challenge #1: Repetitive Test Data Creation 😫
The Problem
You're writing tests and find yourself doing this over and over:

// UserTest.php - The painful way
public function test_user_can_create_post()
{
    $user = new User();
    $user->name = 'John Doe';
    $user->email = 'john@example.com';
    $user->password = Hash::make('password');
    $user->email_verified_at = now();
    $user->save();

    // Repeat this 47 more times in different tests... 😭
}

The Solution: Laravel Model Factories

Laravel's built-in factory system saves the day:

// database/factories/UserFactory.php
namespace Database\Factories;

use Illuminate\Database\Eloquent\Factories\Factory;
use Illuminate\Support\Facades\Hash;
use Illuminate\Support\Str;

class UserFactory extends Factory
{
    public function definition(): array
    {
        return [
            'name' => fake()->name(),
            'email' => fake()->unique()->safeEmail(),
            'email_verified_at' => now(),
            'password' => Hash::make('password'),
            'remember_token' => Str::random(10),
        ];
    }
}

Now your tests become elegant:

public function test_user_can_create_post()
{
    $user = User::factory()->create();

    // That's it! One beautiful line. 🎉
}

Pro Tip: Need multiple users? User::factory()->count(50)->create() - boom! 50 users instantly.

Challenge #2: Complex Object Relationships 🕸️

The Problem

Real applications have intricate relationships. A blog post needs an author, comments, tags, and maybe some media attachments. Creating this manually is nightmare fuel:

$user = User::create([...]);
$post = Post::create(['user_id' => $user->id, ...]);
$comment1 = Comment::create(['post_id' => $post->id, ...]);
$comment2 = Comment::create(['post_id' => $post->id, ...]);
// This is exhausting...

The Solution: Factory Relationships

Laravel factories handle relationships like a boss:

// database/factories/PostFactory.php
class PostFactory extends Factory
{
    public function definition(): array
    {
        return [
            'user_id' => User::factory(), // Automatic user creation!
            'title' => fake()->sentence(),
            'content' => fake()->paragraphs(3, true),
            'published_at' => fake()->dateTimeBetween('-1 year', 'now'),
        ];
    }
}

// database/factories/CommentFactory.php
class CommentFactory extends Factory
{
    public function definition(): array
    {
        return [
            'post_id' => Post::factory(),
            'user_id' => User::factory(),
            'content' => fake()->paragraph(),
        ];
    }
}

Now creating complex structures is child's play:

// Create a post with author and 5 comments
$post = Post::factory()
    ->has(Comment::factory()->count(5))
    ->create();

// Or use the relationship name
$post = Post::factory()
    ->hasComments(5)
    ->create();

// Create a user with 3 posts, each with 2 comments
$user = User::factory()
    ->has(
        Post::factory()
            ->count(3)
            ->has(Comment::factory()->count(2))
    )
    ->create();

Mind = Blown 🤯

Challenge #3: Different Object States 🎭

The Problem
Your User model needs different states: admin users, suspended users, unverified users. How do you handle this without creating
separate factory classes?

The Solution: Factory States
Laravel factories support states - different configurations of the same object:

class UserFactory extends Factory
{
    public function definition(): array
    {
        return [
            'name' => fake()->name(),
            'email' => fake()->unique()->safeEmail(),
            'password' => Hash::make('password'),
            'role' => 'user',
            'is_active' => true,
        ];
    }

    public function admin(): static
    {
        return $this->state(fn (array $attributes) => [
            'role' => 'admin',
        ]);
    }

    public function suspended(): static
    {
        return $this->state(fn (array $attributes) => [
            'is_active' => false,
            'suspended_at' => now(),
        ]);
    }

    public function unverified(): static
    {
        return $this->state(fn (array $attributes) => [
            'email_verified_at' => null,
        ]);
    }
}

Using states is beautifully expressive:

// Create an admin user
$admin = User::factory()->admin()->create();

// Create a suspended user
$suspended = User::factory()->suspended()->create();

// Create an unverified admin (chain states!)
$unverifiedAdmin = User::factory()->admin()->unverified()->create();

// Create 10 suspended users
$suspendedUsers = User::factory()->count(10)->suspended()->create();

Challenge #4: Realistic Test Data 🎯

The Problem
Your tests use fake data, but it doesn't reflect real-world scenarios. Product prices are random, dates don't make sense, and relationships are illogical.

The Solution: Smart Factory Logic
Add intelligence to your factories:

// database/factories/ProductFactory.php
class ProductFactory extends Factory
{
    public function definition(): array
    {
        $cost = fake()->randomFloat(2, 10, 500);
        $markup = fake()->randomFloat(2, 1.2, 2.5);

        return [
            'name' => fake()->words(3, true),
            'sku' => strtoupper(fake()->bothify('??-####')),
            'cost' => $cost,
            'price' => round($cost * $markup, 2), // Logical pricing
            'stock' => fake()->numberBetween(0, 1000),
            'is_featured' => fake()->boolean(20), // 20% chance
        ];
    }

    public function expensive(): static
    {
        return $this->state(function (array $attributes) {
            $cost = fake()->randomFloat(2, 500, 5000);
            return [
                'cost' => $cost,
                'price' => round($cost * 1.5, 2),
                'is_featured' => true,
            ];
        });
    }

    public function outOfStock(): static
    {
        return $this->state(fn (array $attributes) => [
            'stock' => 0,
        ]);
    }
}

// database/factories/OrderFactory.php
class OrderFactory extends Factory
{
    public function definition(): array
    {
        $createdAt = fake()->dateTimeBetween('-6 months', 'now');

        return [
            'user_id' => User::factory(),
            'status' => 'pending',
            'total' => 0, // Will be calculated
            'created_at' => $createdAt,
            'updated_at' => $createdAt,
        ];
    }

    public function completed(): static
    {
        return $this->state(function (array $attributes) {
            $createdAt = $attributes['created_at'];
            $completedAt = fake()->dateTimeBetween(
                $createdAt, 
                $createdAt->modify('+7 days')
            );

            return [
                'status' => 'completed',
                'completed_at' => $completedAt,
                'updated_at' => $completedAt,
            ];
        });
    }
}

Challenge #5: Seeding Large Datasets Efficiently ⚡

The Problem
You need to seed your database with thousands of records for demos or performance testing. Creating them one by one is painfully slow.
The Solution: Optimize Factory Performance

// database/seeders/DatabaseSeeder.php
class DatabaseSeeder extends Seeder
{
    public function run(): void
    {
        // Bad: Creates records one by one (SLOW)
        for ($i = 0; $i < 10000; $i++) {
            User::factory()->create();
        }

        // Good: Uses batch creation (FAST)
        User::factory()->count(10000)->create();

        // Better: Disable events and use chunks for massive datasets
        DB::statement('SET FOREIGN_KEY_CHECKS=0;');

        collect(range(1, 10))->each(function () {
            User::factory()
                ->count(1000)
                ->create();
        });

        DB::statement('SET FOREIGN_KEY_CHECKS=1;');

        // Pro level: Create complex structures efficiently
        User::factory()
            ->count(100)
            ->has(
                Post::factory()
                    ->count(5)
                    ->has(Comment::factory()->count(3))
            )
            ->create();
    }
}

Performance Tip: For massive datasets, consider using DB::table()->insert() directly in your factories for even better performance.

Challenge #6: Custom Factory Behavior 🎨

The Problem
Sometimes you need factories to behave differently based on context or create objects with specific callback logic.
The Solution: Configure and AfterCreating Hooks

class UserFactory extends Factory
{
    public function definition(): array
    {
        return [
            'name' => fake()->name(),
            'email' => fake()->unique()->safeEmail(),
            'password' => Hash::make('password'),
        ];
    }

    public function configure(): static
    {
        return $this->afterCreating(function (User $user) {
            // Automatically create a profile for each user
            $user->profile()->create([
                'bio' => fake()->paragraph(),
                'avatar' => fake()->imageUrl(),
            ]);
        });
    }

    public function withPosts(int $count = 3): static
    {
        return $this->has(Post::factory()->count($count), 'posts');
    }

    public function verified(): static
    {
        return $this->state(fn (array $attributes) => [
            'email_verified_at' => now(),
        ])->afterCreating(function (User $user) {
            // Send welcome email after verification
            // Mail::to($user)->send(new WelcomeEmail());
        });
    }
}

Usage:

// User automatically gets a profile
$user = User::factory()->create();

// Custom method for cleaner code
$user = User::factory()->withPosts(5)->create();

// Verified user with welcome email
$user = User::factory()->verified()->create();

Challenge #7: Testing Edge Cases 🔍

The Problem
Your app needs to handle edge cases: empty strings, maximum values, special characters, null values. Creating these scenarios manually is tedious.
The Solution: Edge Case Factory States

class ProductFactory extends Factory
{
    public function definition(): array
    {
        return [
            'name' => fake()->words(3, true),
            'description' => fake()->paragraph(),
            'price' => fake()->randomFloat(2, 10, 1000),
            'stock' => fake()->numberBetween(0, 100),
        ];
    }

    public function withLongName(): static
    {
        return $this->state(fn (array $attributes) => [
            'name' => fake()->text(255), // Max length
        ]);
    }

    public function withSpecialCharacters(): static
    {
        return $this->state(fn (array $attributes) => [
            'name' => "Test <script>alert('xss')</script> Product",
            'description' => "Description with émojis 🚀 and spëcial çhars",
        ]);
    }

    public function minimal(): static
    {
        return $this->state(fn (array $attributes) => [
            'name' => 'A', // Minimum valid length
            'description' => null,
            'price' => 0.01, // Minimum price
            'stock' => 0,
        ]);
    }

    public function maximum(): static
    {
        return $this->state(fn (array $attributes) => [
            'price' => 999999.99,
            'stock' => 999999,
        ]);
    }
}

Testing edge cases becomes trivial:

public function test_handles_long_product_names()
{
    $product = Product::factory()->withLongName()->create();

    $this->assertLessThanOrEqual(255, strlen($product->name));
}

public function test_sanitizes_special_characters()
{
    $product = Product::factory()->withSpecialCharacters()->create();

    $response = $this->get("/products/{$product->id}");
    $response->assertDontSee('<script>', false);
}

Real-World Example: E-Commerce Platform 🛒

Let's put it all together with a realistic e-commerce scenario:

// Create a complete e-commerce test scenario
public function test_complete_order_flow()
{
    // Create a customer with verified email
    $customer = User::factory()
        ->verified()
        ->create();

    // Create some products with different states
    $expensiveProduct = Product::factory()
        ->expensive()
        ->create();

    $regularProducts = Product::factory()
        ->count(3)
        ->create();

    $outOfStockProduct = Product::factory()
        ->outOfStock()
        ->create();

    // Create an order with items
    $order = Order::factory()
        ->for($customer)
        ->hasAttached($expensiveProduct, ['quantity' => 1])
        ->hasAttached($regularProducts->first(), ['quantity' => 2])
        ->create();

    // Complete the order
    $order->update(['status' => 'completed']);

    // Assertions
    $this->assertEquals(2, $order->items()->count());
    $this->assertTrue($order->total > 0);
    $this->assertEquals('completed', $order->status);
}

Best Practices & Pro Tips 💡

1. Keep Factories Simple
Don't overload factories with too much logic. If you need complex setup, use states or dedicated seeder classes.
2. Use Sequences for Variations

$users = User::factory()
    ->count(3)
    ->sequence(
        ['role' => 'admin'],
        ['role' => 'editor'],
        ['role' => 'user'],
    )
    ->create();

3. Override Attributes When Needed

$user = User::factory()->create([
    'email' => 'specific@example.com',
    'name' => 'Specific Name',
]);

4. Use Faker Wisely

// Good - Realistic data
'phone' => fake()->phoneNumber(),
'address' => fake()->address(),

// Better - Locale-specific
'phone' => fake('en_US')->phoneNumber(),

5. Document Your Factory States

/**
 * Create a suspended user account.
 * Used for testing account recovery and reactivation flows.
 */
public function suspended(): static
{
    // ...
}

Common Pitfalls to Avoid ⚠️

❌ Don't Use Factories in Production Code

// BAD - Never do this in controllers/services
public function store()
{
    $user = User::factory()->create();
}

❌ Don't Create Unnecessary Database Hits

// BAD - Creates actual database records
User::factory()->make(); // Use this for in-memory objects
User::factory()->create(); // Use this when you need DB persistence

❌ Don't Hardcode Relationships

// BAD
'user_id' => 1, // What if user 1 doesn't exist?

// GOOD
'user_id' => User::factory(),

Wrapping Up 🎁

The Factory Pattern in Laravel is not just about generating test data—it's about writing maintainable, testable, and expressive code. Master these patterns, and you'll:

Write tests 10x faster
Catch bugs before they reach production
Onboard new developers with ease
Build demos and prototypes in minutes

Start small, experiment with states, and gradually build up your factory arsenal. Your future self (and your team) will thank you!

📚 Read the Full Version
Want even more details, advanced techniques, and additional examples?
👉 Read the complete guide on Medium
👉 Follow me on Medium for more Laravel deep-dives!

💬 Let's Connect!
What's your biggest challenge with Laravel factories? Drop a comment below!
Found this helpful? Give it a ❤️ and share with your fellow Laravel developers!

Laravel Service Container: From Dependency Hell to Clean Code

Laravel Mastery — Thu, 01 Jan 2026 06:41:02 +0000

How I transformed my tightly-coupled Laravel app into a testable, maintainable codebase using the Service Container pattern

The Problem I Couldn't Ignore

Six months into my Laravel project, my code looked like this:

class OrderController extends Controller
{
    public function store(Request $request)
    {
        $paymentGateway = new StripePaymentGateway();
        $emailService = new SendGridEmailService();
        $inventoryManager = new InventoryManager();

        // Tightly coupled nightmare
        // Impossible to test
        // Hard to maintain
    }
}

The problems were real:

🔴 Couldn't test without hitting Stripe's API
🔴 Changing payment providers meant rewriting controllers
🔴 Zero unit tests (they were impossible to write)
🔴 Every refactor broke something unexpected

The Solution: Laravel's Service Container

Laravel's Service Container + Dependency Injection transformed everything:

// Define the contract
interface PaymentGatewayInterface
{
    public function charge(float $amount, array $details): PaymentResult;
}

// Inject dependencies
class OrderController extends Controller
{
    public function __construct(
        private PaymentGatewayInterface $payment,
        private EmailServiceInterface $email,
        private InventoryManager $inventory
    ) {}

    public function store(Request $request)
    {
        // Now testable, flexible, maintainable
    }
}

Bind in your Service Provider:

Real Impact: The Transformation
Before:

❌ 0 unit tests
❌ 3 days to switch payment providers
❌ 12 files changed per dependency modification
❌ Fear of refactoring

After:

✅ 94% test coverage
✅ 15 minutes to switch providers (config only)
✅ Single service provider change
✅ Confident refactoring

Testing Became Actually Enjoyable

class OrderProcessorTest extends TestCase
{
    public function test_successful_order()
    {
        // Mock the dependencies
        $mockPayment = Mockery::mock(PaymentGatewayInterface::class);
        $mockPayment->shouldReceive('charge')
                    ->once()
                    ->andReturn(new PaymentResult(success: true));

        // Inject mocks - no real API calls!
        $processor = new OrderProcessor($mockPayment, $mockEmail, $mockInventory);

        $result = $processor->process($order);

        $this->assertTrue($result);
    }
}

Advanced Pattern: Contextual Binding

Different contexts need different implementations:

// Admin gets detailed logging
$this->app->when(AdminController::class)
          ->needs(LoggerInterface::class)
          ->give(DetailedLogger::class);

// API gets minimal logging
$this->app->when(ApiController::class)
          ->needs(LoggerInterface::class)
          ->give(MinimalLogger::class);

Common Pitfalls to Avoid

*1. Don't Over-Engineer
*

// ❌ Unnecessary for simple cases
interface UserFormatterInterface { }

// ✅ Keep it simple
class UserFormatter { }

2. Watch for Circular Dependencies

// ❌ This breaks
class OrderService {
    public function __construct(InvoiceService $invoice) {}
}
class InvoiceService {
    public function __construct(OrderService $order) {}
}

// ✅ Use events to decouple
event(new OrderCreated($order));

**3. Organize Service Providers
**Don't dump everything in AppServiceProvider. Create dedicated providers:

// PaymentServiceProvider.php
class PaymentServiceProvider extends ServiceProvider
{
    public function register()
    {
        $this->app->bind(PaymentGatewayInterface::class, StripePaymentGateway::class);
        $this->app->singleton(PaymentProcessor::class);
    }
}

Quick Wins You Can Implement Today

1. Use Method Injection for One-Off Dependencies:

public function generate(Request $request, ReportGenerator $generator)
{
    // Laravel auto-resolves only when needed
    return $generator->create($request->input('type'));
}

2. Tag Related Services:

$this->app->tag([
    'payment.stripe',
    'payment.paypal',
], 'payment.gateways');

// Use all tagged services
$gateways = app()->tagged('payment.gateways');

3. Use Singletons for Expensive Operations:

// Reuse the same instance
$this->app->singleton(ExpensiveService::class);

*Key Takeaways
*

Depend on abstractions - Use interfaces for flexibility
Let Laravel resolve - The container is powerful, use it
Test everything - DI makes testing actually possible
Start simple - Add abstraction when you need it
Organize bindings
Use dedicated service providers

*The Bottom Line
*
The Service Container isn't just about managing dependencies—it's about writing code that evolves with your needs without massive rewrites.
Switching from Stripe to PayPal used to take me 3 days and touch 12+ files. Now? Change one line in a config file. 15 minutes max.
That's the power of proper dependency injection.

📚 Want the Full Deep Dive?

This is a condensed version. For the complete guide including:
Real production examples with payment gateway abstraction
Step-by-step refactoring strategies
Performance optimization techniques
Complete testing strategies
More advanced patterns and pitfalls

Read the full article on Medium: Mastering Laravel's Service Container: From Pain Points to Production-Ready Solutions

_
Have you struggled with tightly-coupled Laravel code? Drop a comment with your experience! 👇_

Repository Pattern in Laravel: Clean Up Your Messy Code

Laravel Mastery — Sun, 28 Dec 2025 11:55:58 +0000

The Problem
Ever seen controllers like this?

public class OrderController extends Controller
{
    public function show($id)
    {
        $order = Order::with(['customer', 'items.product'])
            ->where('id', $id)
            ->first();

        return response()->json($order);
    }

    public function getUserOrders($userId)
    {
        // Same query duplicated! 😱
        $orders = Order::with(['customer', 'items.product'])
            ->where('customer_id', $userId)
            ->get();

        return response()->json($orders);
    }
}

Problems:

🔴 Duplicated queries everywhere
🔴 Controllers tightly coupled to Eloquent
🔴 Impossible to test without database
🔴 Business logic mixed with data access

The Solution: Repository Pattern

Step 1: Create Interface

interface OrderRepositoryInterface
{
    public function find(int $id): ?Order;
    public function findWithRelations(int $id): ?Order;
    public function findByCustomer(int $customerId): Collection;
}

Step 2: Implement Repository

class OrderRepository implements OrderRepositoryInterface
{
    protected $model;

    public function __construct(Order $model)
    {
        $this->model = $model;
    }

    public function findWithRelations(int $id): ?Order
    {
        return $this->model
            ->with(['customer', 'items.product'])
            ->find($id);
    }

    public function findByCustomer(int $customerId): Collection
    {
        return $this->model
            ->with(['customer', 'items.product'])
            ->where('customer_id', $customerId)
            ->orderBy('created_at', 'desc')
            ->get();
    }
}

Step 3: Register in Service Provider

class RepositoryServiceProvider extends ServiceProvider
{
    public function register()
    {
        $this->app->bind(
            OrderRepositoryInterface::class,
            OrderRepository::class
        );
    }
}

Step 4: Clean Controller

class OrderController extends Controller
{
    protected $orderRepository;

    public function __construct(OrderRepositoryInterface $orderRepository)
    {
        $this->orderRepository = $orderRepository;
    }

    public function show(int $id)
    {
        $order = $this->orderRepository->findWithRelations($id);

        if (!$order) {
            return response()->json(['message' => 'Not found'], 404);
        }

        return response()->json($order);
    }

    public function getUserOrders(int $userId)
    {
        $orders = $this->orderRepository->findByCustomer($userId);
        return response()->json($orders);
    }
}

Benefits
✅ No Duplication - Query logic in one place
✅ Easy Testing - Mock repositories instead of database
✅ Flexibility - Switch data sources without touching business logic
✅ Clean Code - Controllers focus on HTTP concerns
✅ Reusability - Use same repository in controllers, jobs, commands

Advanced: Base Repository

abstract class BaseRepository
{
    protected $model;

    public function all(): Collection
    {
        return $this->model->all();
    }

    public function find(int $id): ?Model
    {
        return $this->model->find($id);
    }

    public function create(array $data): Model
    {
        return $this->model->create($data);
    }

    public function update(int $id, array $data): bool
    {
        return $this->model->find($id)?->update($data) ?? false;
    }

    public function delete(int $id): bool
    {
        return $this->model->find($id)?->delete() ?? false;
    }
}

Now extend it:

class ProductRepository extends BaseRepository
{
    public function __construct(Product $model)
    {
        parent::__construct($model);
    }

    public function getFeatured(int $limit = 10): Collection
    {
        return $this->model
            ->where('is_featured', true)
            ->where('stock', '>', 0)
            ->limit($limit)
            ->get();
    }

    public function searchAndFilter(array $filters)
    {
        $query = $this->model->query();

        if (!empty($filters['search'])) {
            $query->where('name', 'like', "%{$filters['search']}%");
        }

        if (!empty($filters['min_price'])) {
            $query->where('price', '>=', $filters['min_price']);
        }

        return $query->paginate(15);
    }
}

Testing Made Easy
Without Repository:

// Must set up entire database
$order = Order::factory()->hasItems(3)->create();
$response = $this->getJson("/api/orders/{$order->id}");

With Repository:

// Just mock the repository!
$orderRepo = Mockery::mock(OrderRepositoryInterface::class);
$orderRepo->shouldReceive('find')
    ->with(1)
    ->andReturn($mockOrder);

$this->app->instance(OrderRepositoryInterface::class, $orderRepo);

Common Pitfalls

❌ Don't Return Query Builder

// Bad
public function getActive()
{
    return $this->model->where('active', true); // Query builder!
}

✅ Do Return Concrete Results

// Good
public function getActive(): Collection
{
    return $this->model->where('active', true)->get();
}

✅ Do Keep Repository for Data Access Only

// Good - Repository only handles data
public function create(array $data): Order
{
    return $this->model->create($data);
}

// Business logic in Service
class OrderService
{
    public function placeOrder(array $data): Order
    {
        $order = $this->orderRepository->create($data);
        Mail::to($order->customer)->send(new OrderCreated($order));
        return $order;
    }
}

Quick Checklist
Before implementing Repository Pattern, ask yourself:

Is my controller doing database queries directly?
Am I duplicating the same queries in multiple places?
Is testing my code difficult without a database?
Do I want to switch between Eloquent/Query Builder/Raw SQL easily?
Am I building more than a simple CRUD app?
If you answered yes to 2+ questions, Repository Pattern will help you!

Conclusion

The Repository Pattern isn't always necessary for simple CRUD apps, but once your application grows, it becomes invaluable. It gives you:
Clean, testable code
Centralized data access logic
Flexibility to change data sources
Better separation of concerns

Start small - implement it for your most complex models first, then expand as needed.

Want the Full Deep Dive?

This is a condensed version! For the complete guide with:

✨ More advanced examples (caching, service layer integration)
✨ Real-world blog system implementation
✨ Complete testing strategies
✨ E-commerce order management example

Read the full article on Medium:
👉 Repository Pattern in Laravel: From Problem to Solution
Follow me for more Laravel tips:
👉 masteryoflaravel on Medium

What's your experience with Repository Pattern? Love it? Hate it? Let's discuss in the comments! 💬

12 Design Patterns Every Laravel Developer Must Master in 2025

Laravel Mastery — Fri, 26 Dec 2025 08:50:45 +0000

Discover the most practical design patterns used in Laravel with real-world examples. From Repository to Strategy patterns - level up your PHP development

Ever wondered why some Laravel code feels elegant and maintainable while others become a tangled mess? The secret lies in design patterns - battle-tested solutions that Laravel itself uses internally.
Let me show you the 12 patterns that'll transform your Laravel development game. 🚀

🎯 Why Design Patterns Matter

Design patterns give you:

Cleaner code that's easier to read
Better testing capabilities
Shared vocabulary with other developers
Scalable architecture for growing apps

Laravel already uses many of these patterns internally. Understanding them means working with the framework, not against it.

1️⃣ Repository Pattern

Problem: Your controllers are fat, and database logic is everywhere.
Solution: Centralize data access in repositories.

interface UserRepositoryInterface {
    public function find($id);
    public function create(array $data);
}

class EloquentUserRepository implements UserRepositoryInterface {
    public function find($id) {
        return User::find($id);
    }
}

// Bind in ServiceProvider
$this->app->bind(UserRepositoryInterface::class, EloquentUserRepository::class);

Real use: Swap database for cache or API without touching controllers.

2️⃣ Service Container (DI)

Laravel's superpower: Automatic dependency injection.

class OrderController extends Controller {
    public function store(OrderService $orderService) {
        return $orderService->processOrder($request->all());
    }
}

No manual instantiation needed! Laravel resolves it automatically. 🎩✨

3️⃣ Factory Pattern

Create objects without specifying exact classes.

class NotificationFactory {
    public static function create($type) {
        return match($type) {
            'email' => new EmailNotification(),
            'sms' => new SmsNotification(),
            'push' => new PushNotification(),
        };
    }
}

Real use: Multi-channel notifications, payment gateways.

4️⃣ Strategy Pattern

Multiple algorithms, one interface.

interface PaymentStrategy {
    public function pay($amount);
}

class CreditCardPayment implements PaymentStrategy {
    public function pay($amount) { /* ... */ }
}

class PayPalPayment implements PaymentStrategy {
    public function pay($amount) { /* ... */ }
}

Real use: Different shipping calculators, pricing strategies.

5️⃣ Observer Pattern

Laravel Events = Observer Pattern 🎯

// Event
class UserRegistered {
    public function __construct(public $user) {}
}

// Listener
class SendWelcomeEmail {
    public function handle(UserRegistered $event) {
        Mail::to($event->user)->send(new WelcomeEmail());
    }
}

// Trigger
event(new UserRegistered($user));

Real use: Send emails, update analytics, trigger webhooks - all decoupled.

6️⃣ Decorator Pattern

Laravel Middleware = Decorator Pattern 🎭

class LogRequest {
    public function handle($request, Closure $next) {
        Log::info('Request: ' . $request->path());
        return $next($request);
    }
}

Add layers of functionality without modifying core logic.

7️⃣ Singleton Pattern

One instance to rule them all.

// In ServiceProvider
$this->app->singleton(ConfigManager::class);

Real use: Database connections, cache managers.

8️⃣ Adapter Pattern

Make incompatible interfaces work together.

interface PaymentGateway {
    public function charge($amount);
}

class StripeAdapter implements PaymentGateway {
    public function charge($amount) {
        return $this->stripe->charges->create(['amount' => $amount]);
    }
}

class PayPalAdapter implements PaymentGateway {
    public function charge($amount) {
        return $this->paypal->createPayment($amount);
    }
}

Real use: Unified interface for multiple payment processors.

9️⃣ Builder Pattern

Laravel Query Builder is the perfect example!

$reports = (new ReportBuilder())
    ->forUser(1)
    ->between('2024-01-01', '2024-12-31')
    ->withDetails()
    ->get();

Real use: Complex queries, API request builders.

🔟 Facade Pattern

Simple interface to complex subsystems.

// Instead of complex instantiation
Mail::send(new WelcomeEmail());
Cache::remember('key', 3600, fn() => expensive());

Laravel Facades simplify everything! 🎪

1️⃣1️⃣ Chain of Responsibility

Pass requests through a chain of handlers.

class ValidateData {
    public function handle($data, Closure $next) {
        if (!$this->isValid($data)) {
            throw new ValidationException();
        }
        return $next($data);
    }
}

Real use: Middleware pipelines, data processing chains.

1️⃣2️⃣ Command Pattern

Laravel Jobs = Command Pattern 📦

class ProcessPayment implements ShouldQueue {
    public function __construct(protected $orderId) {}

    public function handle() {
        $order = Order::find($this->orderId);
        // Process payment
    }
}

ProcessPayment::dispatch($orderId);

Real use: Background jobs, queued tasks.

🎨 Combining Patterns in Real Apps

The magic happens when you combine patterns:

// Repository + Service + Strategy
class OrderService {
    public function __construct(
        protected OrderRepository $repository,
        protected ShippingCalculator $calculator
    ) {}

    public function createOrder($data) {
        $shipping = $this->calculator->calculate($data['weight']);
        $data['shipping_cost'] = $shipping;

        return $this->repository->create($data);
    }
}

💡 Best Practices

Don't over-engineer - Use patterns when they solve real problems
Start simple - Refactor to patterns as complexity grows
Use Laravel's built-ins - Don't reinvent the wheel
Test everything - Patterns should make testing easier

🎯 Key Takeaways

Laravel already uses these patterns internally
Start with Repository, Service Container, and Observer
Combine patterns for powerful architectures
Use patterns to solve problems, not to show off
Your code will be cleaner, testable, and scalable

📚 Read the Full Version
Want deeper dives into each pattern with more complex examples?
Read the complete guide on Medium

Follow me for more Laravel tips
Medium

🤔 Which pattern do you use most?

Drop a comment below! Let's discuss which patterns have helped you the most in your Laravel projects.

Happy coding! 🚀

Laravel #PHP #DesignPatterns #WebDev #CleanCode #SoftwareArchitecture #BackendDevelopment #Programming

🚀 Mastering PHP Attributes: From Zero to Hero

Laravel Mastery — Tue, 23 Dec 2025 06:27:59 +0000

Mastering PHP Attributes: Custom Creation, Routing & Validation

description: Deep dive into PHP 8+ attributes - learn to build custom attributes, attribute-based routing, and powerful validation systems with real-world

PHP 8.0 introduced attributes - a game-changer for writing clean, declarative code. Let's explore how to create custom attributes, build routing systems, and implement validation frameworks.

🎯 What Are Attributes?

Attributes are metadata you attach to classes, methods, properties, and parameters. Think of them as sticky notes on your code that become powerful at runtime.

#[Route('/users/{id}')]
#[AuditLog('ViewUser')]
public function show(int $id) { }

🔨 Part 1: Creating Custom Attributes

Basic Custom Attribute

#[Attribute(Attribute::TARGET_METHOD | Attribute::IS_REPEATABLE)]
class AuditLog
{
    public function __construct(
        public string $operation,
        public LogLevel $level = LogLevel::INFO,
        public array $sensitiveParams = []
    ) {}
}

enum LogLevel: string {
    case INFO = 'info';
    case WARNING = 'warning';
    case ERROR = 'error';
}

Usage Example

class PaymentController
{
    #[AuditLog('ProcessPayment', LogLevel::WARNING, ['cardNumber', 'cvv'])]
    public function process(string $cardNumber, string $cvv): bool
    {
        // Payment logic
        return true;
    }
}

🔍 Part 2: Reading Attributes with Reflection

class AttributeProcessor
{
    public static function processAuditLogs(object $controller, string $method): void
    {
        $reflection = new ReflectionMethod($controller, $method);
        $attributes = $reflection->getAttributes(AuditLog::class);

        foreach ($attributes as $attr) {
            $audit = $attr->newInstance();
            echo "Logging: {$audit->operation} at level {$audit->level->value}\n";
        }
    }
}

// Usage
AttributeProcessor::processAuditLogs(new PaymentController(), 'process');
// Output: Logging: ProcessPayment at level warning

🛣️ Part 3: Attribute-Based Routing

Route Attributes

#[Attribute(Attribute::TARGET_METHOD)]
class Route
{
    public function __construct(
        public string $path,
        public string $method = 'GET'
    ) {}
}

#[Attribute(Attribute::TARGET_CLASS)]
class RoutePrefix
{
    public function __construct(public string $prefix) {}
}

Simple Router Implementation

class Router
{
    private array $routes = [];

    public function register(string $controllerClass): void
    {
        $reflection = new ReflectionClass($controllerClass);

        // Get class prefix
        $prefixAttrs = $reflection->getAttributes(RoutePrefix::class);
        $prefix = $prefixAttrs[0]->newInstance()->prefix ?? '';

        // Register methods
        foreach ($reflection->getMethods() as $method) {
            $routeAttrs = $method->getAttributes(Route::class);

            foreach ($routeAttrs as $attr) {
                $route = $attr->newInstance();
                $fullPath = $prefix . $route->path;

                $this->routes[$route->method][$fullPath] = [
                    'controller' => $controllerClass,
                    'method' => $method->getName()
                ];
            }
        }
    }

    public function dispatch(string $httpMethod, string $uri): mixed
    {
        if (!isset($this->routes[$httpMethod][$uri])) {
            throw new Exception("Route not found");
        }

        $route = $this->routes[$httpMethod][$uri];
        $controller = new $route['controller']();

        return $controller->{$route['method']}();
    }
}

Controller Example

#[RoutePrefix('/api/users')]
class UserController
{
    #[Route('/')]
    public function index(): array
    {
        return ['users' => ['Alice', 'Bob']];
    }

    #[Route('/{id}', method: 'GET')]
    public function show(int $id): array
    {
        return ['id' => $id, 'name' => 'Alice'];
    }

    #[Route('/', method: 'POST')]
    public function store(): array
    {
        return ['message' => 'User created'];
    }
}

// Usage
$router = new Router();
$router->register(UserController::class);
$result = $router->dispatch('GET', '/api/users/');
// Returns: ['users' => ['Alice', 'Bob']]

✅ Part 4: Validation Attributes

#[Attribute(Attribute::TARGET_PROPERTY)]
abstract class ValidationRule
{
    public function __construct(public string $message = '') {}
    abstract public function validate(mixed $value): bool;
}

#[Attribute(Attribute::TARGET_PROPERTY)]
class Required extends ValidationRule
{
    public function validate(mixed $value): bool
    {
        return !empty(trim($value));
    }
}

#[Attribute(Attribute::TARGET_PROPERTY)]
class Email extends ValidationRule
{
    public function validate(mixed $value): bool
    {
        return filter_var($value, FILTER_VALIDATE_EMAIL) !== false;
    }
}

#[Attribute(Attribute::TARGET_PROPERTY)]
class Length extends ValidationRule
{
    public function __construct(
        public int $min = 0,
        public int $max = PHP_INT_MAX,
        string $message = 'Invalid length'
    ) {
        parent::__construct($message);
    }

    public function validate(mixed $value): bool
    {
        $len = mb_strlen($value);
        return $len >= $this->min && $len <= $this->max;
    }
}

Validator Engine

class Validator
{
    private array $errors = [];

    public function validate(object $object): bool
    {
        $reflection = new ReflectionClass($object);

        foreach ($reflection->getProperties() as $property) {
            $property->setAccessible(true);
            $value = $property->getValue($object);

            $attributes = $property->getAttributes(
                ValidationRule::class,
                ReflectionAttribute::IS_INSTANCEOF
            );

            foreach ($attributes as $attr) {
                $rule = $attr->newInstance();

                if (!$rule->validate($value)) {
                    $this->errors[$property->getName()][] = $rule->message;
                }
            }
        }

        return empty($this->errors);
    }

    public function getErrors(): array
    {
        return $this->errors;
    }
}

Model with Validation

class UserRequest
{
    #[Required(message: 'Name is required')]
    #[Length(min: 3, max: 50)]
    public string $name;

    #[Required]
    #[Email(message: 'Invalid email address')]
    public string $email;

    #[Required]
    #[Length(min: 8, message: 'Password must be at least 8 characters')]
    public string $password;
}

// Usage
$request = new UserRequest();
$request->name = 'Jo';
$request->email = 'invalid-email';
$request->password = '123';

$validator = new Validator();

if (!$validator->validate($request)) {
    print_r($validator->getErrors());
    /* Output:
    [
        'name' => ['Invalid length'],
        'email' => ['Invalid email address'],
        'password' => ['Password must be at least 8 characters']
    ]
    */
}

🎯 Real-World Combined Example

#[RoutePrefix('/api')]
class OrderController
{
    #[Route('/orders', method: 'POST')]
    #[AuditLog('CreateOrder', LogLevel::INFO)]
    public function create(): array
    {
        $request = new OrderRequest();
        $request->amount = 50.00;
        $request->email = 'customer@example.com';

        $validator = new Validator();

        if (!$validator->validate($request)) {
            http_response_code(422);
            return ['errors' => $validator->getErrors()];
        }

        return ['message' => 'Order created', 'id' => 123];
    }
}

class OrderRequest
{
    #[Required]
    #[Range(min: 1, max: 99999)]
    public float $amount;

    #[Required]
    #[Email]
    public string $email;
}

🚀 Key Benefits

✅ Type-safe - Compile-time validation
✅ Clean syntax - No messy docblocks
✅ IDE support - Full autocomplete
✅ Maintainable - DRY principle
✅ Performance - Cached by OPcache
💡 Pro Tips

Cache reflection data in production
Use IS_INSTANCEOF flag for inheritance
Combine attributes for powerful patterns
Keep attributes simple and focused
Document custom attributes well

🎓 Conclusion

PHP attributes unlock powerful declarative programming patterns. Start with validation, add routing, then explore cross-cutting concerns like logging and caching.
What will you build with attributes? Share in the comments! 👇

Want to dive deeper? Check out the full version of this article on Medium with extended examples and production-ready code!
More tutorials and insights? Follow me on Medium for deep dives into PHP, architecture patterns, and modern web development!
Found this helpful? Drop a ❤️ and follow for more!

php #attributes #php8 #webdevelopment #programming

When "Simple" Problems Aren't Simple: Hard-Learned Lessons from PHP's Hidden Gems

Laravel Mastery — Sat, 20 Dec 2025 07:44:27 +0000

Originally published on Medium - Read the full story here

I thought I was a decent PHP developer. I knew Laravel, wrote clean code, and shipped features on time. Then a "simple" CSV import feature taught me I'd been solving the wrong problems all along.

The 3 AM Wake-Up Call

Picture this: It's 3 AM. Your phone won't stop buzzing. The batch process has failed again, corrupting records before crashing. Your CTO wants to know why a "basic CSV upload" has caused three production incidents in two weeks.
This was my reality. A "two-day task" became a three-month nightmare. The problem? I was treating CSV as solved when it's actually a minefield.
What I learned the hard way:

Excel adds hidden byte order marks
Google Sheets escapes quotes differently than LibreOffice
MacOS and Windows use different line endings
Files edited across multiple programs become chaos

We tried parsing everything with fgetcsv() and custom validation. It was like translating five languages with a pocket dictionary—technically possible, but you'll miss crucial nuances.

The UUID Mistake I Almost Made

Architecting microservices, I needed IDs that wouldn't collide across services. My solution? Generate random 32-character strings with bin2hex(random_bytes(16)). Shipped it. Felt clever.
Two weeks later: duplicate IDs appeared in production. Rarely, but it happened. In a financial system, "rarely" isn't acceptable.
I'd hit the birthday paradox. Collisions become statistically likely faster than you'd expect. Worse, I had no idea seven different UUID versions exist, each designed for specific scenarios:

Version 1: timestamps + MAC addresses (sortable, privacy concerns)
Version 4: purely random (no privacy issues, unsortable)
Version 7: timestamp-ordered with random components (perfect for database indexes)

I was about to spend weeks on a half-baked solution that would cause subtle bugs for years.

The Lawsuit We Couldn't Defend

A customer disputed a $15,000 transaction. Our database showed it existed. But we couldn't prove how it happened—just the final state.
Traditional databases store current state: user balance, order status, subscription tier. Not how we got there. When someone disputes something, you're defenseless.
Questions we couldn't answer:

When did they initiate the order?
What did they see on screen?
Did they explicitly confirm?
What IP address?

Event sourcing changes this fundamentally. Store events, not state: account created, deposited $150, withdrew $50. Every state change is immutable.
But implementing from scratch? I spent three weeks building an event store that worked perfectly in development and collapsed under production load.

The Pattern I Finally Recognized

Every mistake followed the same arc:

"This looks simple"
Implement obvious solution
Works in development
Breaks in production in unexpected ways
Add special cases
More special cases
Maintenance nightmare

Real problems I hit:

CSV files with mixed encodings, malformed quotes, embedded newlines
UUID collisions from birthday paradox
Event stores that couldn't handle concurrent writes
Console apps that became 2,000-line monsters
Validation logic scattered across 47 files
HTTP clients without circuit breakers causing cascading failures
Date bugs during DST transitions that cost us money

Each time, specialized packages had already solved these problems comprehensively.

What Changed My Perspective

The best engineers aren't the ones who build everything from scratch. They recognize patterns, understand trade-offs, and choose appropriate tools.
When you're debugging CSV encoding at 3 AM, you're not learning about character sets—you're wasting time on solved problems. When implementing UUID collision detection, you're not strengthening algorithms knowledge—you're rediscovering decades-old distributed systems research.
The real cost: Every hour solving already-solved problems is an hour not spent on actual business logic—problems unique to your domain that provide competitive advantage.

The Lesson

After switching to specialized libraries for these problems:

No more 3 AM calls about CSV imports
No UUID collisions
Complete audit trails for disputes
Maintainable console applications
Clean, testable validation logic
Resilient third-party integrations
Correct date handling across timezones

The difference isn't just saving time. It's learning from others' mistakes. Every production-ready package represents hundreds of hours of development, thousands of hours of testing, and real-world experience you'll never see.
Next time you face a complex problem, pause before coding. Ask: Has someone solved this? What can I learn from their approach? Is this simple on the surface but complex underneath?
That's what separates junior from senior engineers—not syntax knowledge, but recognizing which problems deserve custom solutions versus which benefit from standing on giants' shoulders.

Want the full deep-dive with all the details? Read the complete article on Medium where I break down each problem, the failures, and the solutions in depth.

php #webdev #softwaredevelopment #programming #backend #laravel #bestpractices #testing #architecture #lessons

PHP Killed Dynamic Properties. Here's Why (And What to Do)

Laravel Mastery — Wed, 17 Dec 2025 17:44:25 +0000

Starting with PHP 8.2, dynamic properties are deprecated. In PHP 9.0, they're completely gone.
If you're seeing deprecation warnings in your Laravel 11 projects, this is why.

What Are Dynamic Properties?

Properties added to objects without being declared in the class:

class User {}

$user = new User();
$user->age = 30; // ⚠️ Dynamic property

The Problem

Silent Typos = Hidden Bugs

$user->custmer_email = 'john@example.com'; // Typo!
// Later...
echo $user->customer_email; // null 😱

No Type Safety

$user->age = 30;        // int
$user->age = 'thirty';  // string - no error!
$user->age = null;      // also "fine"

IDE Can't Help You

No autocomplete
No refactoring support
Static analysis tools are blind

Architecture Decay

// Anemic domain model
$user->cached_data = $something;
$user->temp_flag = true;
$user->random_stuff = $whatever;

The Fix: Declare Properties Explicitly

✅ Modern PHP Way

class User {
    public string $name;
    public int $age;
    public bool $isActive;
}

✅ Constructor Property Promotion (PHP 8+)

class CreateOrderRequest {
    public function __construct(
        public readonly string $customerId,
        public readonly array $items,
        public readonly ?string $promoCode = null,
    ) {}
}

Laravel-Specific Solutions

❌ Don't Do This

$user = User::find(1);
$user->is_verified = true; // Undefined property!

✅ Do This Instead

class User extends Model {
    protected $fillable = [
        'name',
        'email',
        'is_verified',
    ];

    protected $casts = [
        'is_verified' => 'boolean',
        'email_verified_at' => 'datetime',
    ];
}

✅ Or Use Accessors

use Illuminate\Database\Eloquent\Casts\Attribute;

class User extends Model {
    protected function fullName(): Attribute {
        return Attribute::make(
            get: fn() => "{$this->first_name} {$this->last_name}",
        );
    }
}

The Escape Hatch (Use Sparingly!)

#[\AllowDynamicProperties]
class LegacyCode {
    // Opt into old behavior
}

Only use this for:

Legacy vendor code
Gradual migration (with a plan to remove)

Never use for new code!

Migration Strategy

./vendor/bin/phpstan analyze --level 8
./vendor/bin/psalm --no-cache

2. Fix Systematically

Critical: Domain models (fix now)
High: Controllers/Services (next sprint)
Medium: DTOs (incremental)
Low: Test utilities (add attribute if needed)

3. Prevent Regression

Add static analysis to CI:

# .github/workflows/ci.yml
- name: Static Analysis
  run: ./vendor/bin/phpstan analyze

Version	Status
PHP 8.1	✅ Allowed
PHP 8.2	⚠️ Deprecated warning
PHP 9.0	❌ Fatal error

Why This Change Matters

Modern PHP is moving toward:

✅ Explicit over implicit
✅ Type safety by default
✅ Better tooling support
✅ Refactor-friendly code

Dynamic properties don't fit this vision.

Real Example: Before & After

Before ❌

class ApiResponse {}

$response = new ApiResponse();
$response->data = $data;
$response->status = 200;

After ✅

class ApiResponse {
    public function __construct(
        public readonly mixed $data,
        public readonly int $status,
        public readonly int $timestamp = time(),
    ) {}
}

$response = new ApiResponse($data, 200);

Benefits: Type-safe, self-documenting, immutable, refactor-friendly.

🎯 Key Takeaways

Declare all properties explicitly
Use typed properties for safety
Leverage PHP 8+ features (constructor promotion, readonly)
Run static analysis regularly
Plan migration for legacy code

This is a condensed version. For the complete guide including:

Historical context of PHP's design evolution
Detailed migration strategies for large codebases
Advanced Laravel patterns
Philosophical discussion on constraints
More real-world examples

👉 Read the full article on Medium:

php #laravel #webdev #programming #backend #php8 #cleancode #softwaredevelopment

Laravel Bastion: Stripe-Style API Authentication for Laravel

Laravel Mastery — Mon, 15 Dec 2025 06:15:09 +0000

Ever wished Laravel had API tokens as elegant as Stripe's? Meet Laravel Bastion by Steve McDougall.

What is Bastion?
Bastion brings Stripe-inspired API key management to Laravel with prefixed tokens, environment isolation, and granular permissions.

app_test_pk_xxxxxxxxxxxxx
app_live_sk_xxxxxxxxxxxxx

🌍 Environment Isolation

Separate test and live environments prevent accidental key leaks.
🎯 Granular Scopes

['posts:read', 'posts:write', 'users:*']

🔐 Three Token Types

Public keys (client-side safe)
Secret keys (server-side only)
Restricted keys (limited scopes)

📊 Built-in Audit Logging

Track every token action for security and compliance.

Quick Start

Add the trait:

use JustSteveKing\Bastion\Concerns\HasBastionTokens;

class User extends Authenticatable
{
    use HasBastionTokens;
}

Create a token:

$result = $user->createBastionToken(
    name: 'My API Key',
    scopes: ['posts:read'],
    environment: TokenEnvironment::Test,
    type: TokenType::Restricted,
);

Protect routes:

Route::middleware(AuthenticateToken::class)->group(function () {
    Route::get('/api/posts', [PostController::class, 'index']);
});

Use CLI commands:

php artisan bastion:generate {user-id} "Token Name"
php artisan bastion:rotate {token-id}
php artisan bastion:revoke {token-id}

Why Bastion?

Choose Bastion when you need:

Multi-environment isolation
Fine-grained permissions
Enterprise-grade security
Stripe-like developer experience

Perfect for SaaS platforms, fintech apps, and third-party APIs.
Get started: Laravel Bastion on GitHub

📖 Read the full in-depth article on Medium: Laravel Bastion: Complete Guide

laravel #php #api #authentication

Stop Hardcoding Translations in Laravel - Use Translatable

Laravel Mastery — Sun, 14 Dec 2025 06:11:33 +0000

Stop Hardcoding Translations in Laravel - Use Translatable
🤔 The Problem
Building a multilingual Laravel app? You've probably written messy code like this:

// ❌ The nightmare approach
switch($status) {
    case 'draft':
        return $locale === 'es' ? 'Borrador' : 
               ($locale === 'fr' ? 'Brouillon' : 'Draft');
    // ... more chaos
}

There's a much cleaner way.
✨ The Solution: Translatable Enums
Meet the Laravel Enum Translatable package by Osama Sadah.
Install It

composer require osama/laravel-enum-translatable

Create Your Enum

<?php

namespace App\Enums;

use Osama\LaravelEnums\Concerns\EnumTranslatable;

enum ArticleStatus: string
{
    use EnumTranslatable;  // ← Magic happens here

    case DRAFT = 'draft';
    case PUBLISHED = 'published';
    case REJECTED = 'rejected';
}

Add Translations

// lang/en/enums.php
return [
    'article_statuses' => [
        'draft' => 'Draft',
        'published' => 'Published',
        'rejected' => 'Rejected',
    ],
];

// lang/es/enums.php
return [
    'article_statuses' => [
        'draft' => 'Borrador',
        'published' => 'Publicado',
        'rejected' => 'Rechazado',
    ],
];

// lang/fr/enums.php
return [
    'article_statuses' => [
        'draft' => 'Brouillon',
        'published' => 'Publié',
        'rejected' => 'Rejeté',
    ],
];

Use It Everywhere

$status = ArticleStatus::DRAFT;

// Current locale
$label = $status->trans(); 
// "Draft" (en) or "Borrador" (es) or "Brouillon" (fr)

// Specific locale
$spanish = $status->trans('es'); // "Borrador"

// All translations at once
$all = $status->allTrans(); 
// ['en' => 'Draft', 'es' => 'Borrador', 'fr' => 'Brouillon']

🚀 Real Example: Blog API
The Model

use App\Enums\ArticleStatus;
use Illuminate\Database\Eloquent\Model;

class Article extends Model
{
    protected function casts(): array
    {
        return [
            'status' => ArticleStatus::class,
        ];
    }
}

The Controller

public function show(Article $article)
{
    return response()->json([
        'id' => $article->id,
        'title' => $article->title,
        'status' => [
            'value' => $article->status->value,
            'label' => $article->status->trans(),
            'all_translations' => $article->status->allTrans(),
        ],
    ]);
}

The Response

{
  "id": 1,
  "title": "Getting Started with Laravel",
  "status": {
    "value": "published",
    "label": "Published",
    "all_translations": {
      "en": "Published",
      "es": "Publicado",
      "fr": "Publié"
    }
  }
}

Perfect for multi-language frontends! 🌍
*💪 Advanced: Combine with Business Logic
*

enum OrderStatus: string
{
    use EnumTranslatable;

    case PENDING = 'pending';
    case PAID = 'paid';
    case SHIPPED = 'shipped';
    case DELIVERED = 'delivered';

    public function badge(): string
    {
        return match($this) {
            self::PENDING => 'warning',
            self::PAID => 'info',
            self::SHIPPED => 'primary',
            self::DELIVERED => 'success',
        };
    }

    public function canBeCancelled(): bool
    {
        return in_array($this, [self::PENDING, self::PAID]);
    }
}

In Your Blade View

<span class="badge badge-{{ $order->status->badge() }}">
    {{ $order->status->trans() }}
</span>

@if($order->status->canBeCancelled())
    <button class="btn btn-danger">
        {{ __('Cancel Order') }}
    </button>
@endif

Clean, readable, maintainable! ✨
🎯 Why This Rocks
✅ Type-Safe - PHP 8.1+ enum power
✅ DRY - Write translation once, use everywhere
✅ Clean Code - No conditionals scattered around
✅ Scalable - Add languages without code changes
✅ Testable - Easy to unit test
🧪 Quick Test Example

public function test_translations_exist_for_all_locales()
{
    $locales = ['en', 'es', 'fr'];

    foreach (ArticleStatus::cases() as $status) {
        foreach ($locales as $locale) {
            $translation = $status->trans($locale);

            $this->assertNotNull($translation);
            $this->assertNotEmpty($translation);
        }
    }
}

📦 Quick Reference

// Get current locale translation
$status->trans()

// Get specific locale
$status->trans('es')

// Get all translations
$status->allTrans()

// In models (automatic casting)
protected $casts = ['status' => ArticleStatus::class];

🎓 Want More?
This is a quick introduction. I've written a comprehensive guide covering:

🏗️ Multi-tenant applications
🔧 Custom translation structures
⚡ Performance optimization
🚀 Production deployment strategies
🧪 Complete testing approaches
📊 Real-world case studies

👉 Read the Full Guide on Medium →

💡 Pro Tips

Always set a fallback:

// config/app.php
'fallback_locale' => 'en',

Dynamic form selects:

$options = collect(ArticleStatus::cases())
    ->map(fn($s) => [
        'value' => $s->value,
        'label' => $s->trans()
    ]);

Localized notifications:

$locale = $user->locale ?? 'en';
$message = "Status changed to: " . $order->status->trans($locale);

🌟 Common Use Cases

E-commerce: Order statuses, payment statuses
CMS: Article statuses, content types
SaaS: Subscription tiers, user roles
Task Management: Priority levels, task states
Multi-tenant Apps: Per-tenant translations