DEV Community: Indunil Peramuna

The One-Line MySQL 8 Switch to Auto-Optimize Your Dedicated Database Infrastructure

Indunil Peramuna — Fri, 05 Jun 2026 13:49:06 +0000

As an application scales, managing the database layer transitions from an active development task to a pure infrastructure challenge. If you have ever opened a production MySQL my.cnf configuration file, you have likely stared down the anxiety-inducing task of manually tuning memory allocations, redo logs, and system-level flush methods.

Get it wrong, and you introduce artificial disk bottlenecks or trigger system lockups. Get it right, and your database handles high concurrency with ease.

Fortunately, if your infrastructure strategy includes moving your database to its own hardware—such as a dedicated Write Primary node or a standalone Read Replica cluster—MySQL 8 introduced a feature that removes the trial-and-error entirely.

By adding a single, powerful line to your config block, MySQL transforms into a self-tuning engine:

innodb_dedicated_server = ON

Let's do a deep architectural dive into what this switch does under the hood, the four heavy-hitting variables it auto-adjusts, how to prepare your configuration files, and the critical guardrails you must enforce.

What Happens Under the Hood?

When the MySQL daemon initializes with innodb_dedicated_server = ON, it bypasses standard static defaults. Instead, it probes the underlying operating system at runtime to detect the total available physical RAM and CPU cores.

Using those metrics, it dynamically recalculates and tunes the four most critical components of the InnoDB storage engine.

                  ┌──────────────────────────────────────────────┐
                  │        innodb_dedicated_server = ON          │
                  └──────────────────────┬───────────────────────┘
                                         │ (Probes Host Hardware)
                                         ▼
         ┌───────────────────────────────┴───────────────────────────────┐
         ▼                               ▼                               ▼
┌─────────────────┐             ┌─────────────────┐             ┌─────────────────┐
│   Buffer Pool   │             │  Flush Method   │             │    Redo Logs    │
│  Scales up to   │             │   Switches to   │             │    Optimizes    │
│   80% of RAM    │             │    O_DIRECT     │             │ Write Buffering │
└─────────────────┘             └─────────────────┘             └─────────────────┘

Here is the exact engineering breakdown of what it auto-adjusts:

1. `innodb_buffer_pool_size` (The Memory Footprint)

The buffer pool is the primary memory area where InnoDB caches table data and indexes.

The Default Danger: Out of the box, MySQL defaults this to a tiny 128 MB, which kills production performance instantly.
The Auto-Tuned Reality: It dynamically scales based on your machine's physical hardware capacity:
- Server RAM < 1 GB: Stays at the baseline 128 MB.
- Server RAM <= 4 GB: Allocates 50% of total system RAM.
- Server RAM < 16 GB: Allocates 75% of total system RAM.
- Server RAM >= 16 GB: Aggressively claims 80% of total system RAM.

2. `innodb_flush_method` (Eliminating OS Overhead)

On Linux systems, enabling the dedicated server flag forces the engine to use the O_DIRECT flush method.

Why this is critical: By default, the operating system attempts to cache database files in its own filesystem page cache, while MySQL is simultaneously caching them inside its own buffer pool. This "double caching" is highly inefficient and risks memory exhaustion. O_DIRECT tells the engine to bypass the OS page cache completely, routing I/O throughput straight to disk and leaving memory management entirely to InnoDB.

3. `innodb_log_file_size` & `innodb_log_files_in_group` (Redo Log Optimization)

Redo logs record every single data modification before it is asynchronously flushed to the actual tablespace. If these logs are too small, the database chokes on heavy transaction bursts because it has to freeze operations to flush log buffers to disk. The auto-tuner dynamically scales the redo log sizes up to a calculated ratio of your total buffer pool size, maximizing write concurrency.

4. `innodb_log_buffer_size`

This defines the memory buffer size that InnoDB utilizes before writing data out to the redo logs on disk. The auto-tuner scales this proportionally, ensuring massive or concurrent transactions don't instantly suffer from disk I/O latency bottlenecks.

🛠️ The Implementation Rule: Clean Your Config First

Before you flip this switch, you must perform a clean-up of your existing configuration. This is where many production migrations fail.

If you have explicit, old lines defining any of these four values anywhere else in your my.cnf or mysqld.cnf files, MySQL will prioritize those hardcoded parameters. It will silently override the auto-tuner, completely defeating the purpose of the setting.

Open your configuration file and delete or comment out (#) the following blocks if they exist:

# =====================================================================
# REMOVE OR COMMENT THESE OUT TO LET DEDICATED SERVER TAKE CONTROL:
# =====================================================================
# innodb_buffer_pool_size = 2G
# innodb_log_file_size = 512M
# innodb_log_buffer_size = 16M
# innodb_flush_method = O_DIRECT

Once the legacy parameters are scrubbed, append the magic line under your core server block:

[mysqld]
innodb_dedicated_server = ON

Save the file and safely restart your database service to let it evaluate the environment and step up its tuning:

sudo systemctl restart mysql

⚠️ The Architectural Guardrails (When NOT to use it)

As senior engineers, we must focus on the trade-offs. The name of this feature is literal: dedicated_server.

You must only use this flag if the target server is a 100% dedicated database box.

Do NOT turn this on if:

You run a compact "monolith" architecture where Nginx, PHP-FPM, Redis, and MySQL all co-exist on the same single VPS or bare-metal host.
You are deploying inside a local development environment (e.g., standard Docker Compose setups or lightweight dev virtual machines).

The Risk: If your server has 32 GB of RAM, MySQL will cleanly claim 25.6 GB (80%) the moment it boots. If you have application workers like PHP-FPM or memory caches like Redis competing on that exact same operating system instance, the system will face instantaneous memory exhaustion.

When the OS hits that wall, the Linux Kernel's Out-Of-Memory (OOM) Killer will trigger, abruptly terminating random processes to protect the host machine. More often than not, it will kill your web workers or crash the database daemon itself.

Summary

When scaling infrastructure out—moving from single instances to complex multi-node topologies like primary-replica splitting—reducing manual operational overhead is key.

Leveraging innodb_dedicated_server = ON allows your stateless database layers to automatically optimize themselves to match whatever compute tier you throw them on, freeing you up to focus on application architecture rather than micro-managing database configurations.

Have you transitioned your production clusters to use MySQL's native auto-tuning? Let's talk shop and share experiences in the comments below! 👇

Supercharge Your PHP Apps with FrankenPHP Classic Mode

Indunil Peramuna — Tue, 13 Jan 2026 13:31:17 +0000

Supercharge Your PHP Apps with FrankenPHP Classic Mode

PHP deployment hasn't seen a shift this exciting in years. FrankenPHP is here, and while everyone talks about "worker mode", Classic Mode is the immediate upgrade your servers need.

I've written a comprehensive guide on how to replace PHP-FPM with FrankenPHP behind Nginx.

What is Classic Mode?

It allows FrankenPHP to act as a standard request handler, just faster and simpler than FPM. It integrates perfectly with your existing Nginx setups.

Why it's better:

103 Early Hints: Speeds up perceived load times by sending assets before the page is ready.
Observability: Detailed Prometheus metrics and structured logging out of the box.
Robustness: Benefits from Go's memory safety for the server layer.

Static vs Dynamic (Glibc) Builds

One of huge advantages of FrankenPHP is the static build.

Static: Zero dependencies. Runs on Alpine, Debian, CentOS without needing libraries like libpng installed. Perfect for containers.
Dynamic: Uses system libraries. Better if you need specific system-patched versions of libs.

The Tool

I also released an open-source tool, frankenphp-classic-setup, which automates:

Binary installation (smartly chooses Static or Dynamic based on need).
Systemd service creation.
Nginx configuration generation.
CLI wrapper setup (use fphp instead of php).

The Guide

I cover the manual "hard way" to help you learn, and the automated "easy way" to get you into production fast.

Manual Steps Summary

Download frankenphp.
Set up a systemd service pointing to your doc root.
Proxy Nginx to port 9000.

Automated Way

git clone https://github.com/iperamuna/frankenphp-classic-setup.git
sudo ./setup.sh

Read the full technical breakdown and guide here

About the Author
Indunil Peramuna is a software engineer passionate about optimizing modern web infrastructure.

GitHub: @iperamuna
LinkedIn: indunilperamuna
Telegram: @iperamuna
Discord: iperamuna
WhatsApp: +94777671771

Why HTML Fragment Caching is the Performance Game-Changer Your Laravel App Needs

Indunil Peramuna — Thu, 16 Oct 2025 02:00:09 +0000

As a Senior Software Engineer who's spent years optimizing web applications, I've seen firsthand how the right caching strategy can transform user experience and reduce infrastructure costs. Today, I want to share insights about a critical but often overlooked caching technique: HTML Fragment Caching.

The Hidden Performance Bottleneck

Picture this: Your Laravel application is serving a dashboard with multiple widgets - user statistics, product recommendations, recent orders, and activity feeds. Each widget requires database queries, data processing, and Blade template rendering.

The problem? Even with Redis caching your database queries, you're still re-rendering the same HTML markup on every request. That's like caching the ingredients but cooking the meal fresh every time.

The Traditional Caching Approach (And Why It Falls Short)

Most developers stop at caching database results:

// This caches the data, but not the rendered HTML
$products = Cache::remember('products:featured', 3600, function () {
    return Product::featured()->with('category')->get();
});

// This still runs on every request
return view('dashboard.products', compact('products'))->render();

The issue: You're caching the data, but the expensive Blade rendering, HTML generation, and string concatenation still happen on every request. In high-traffic applications, this can mean thousands of unnecessary CPU cycles.

Enter HTML Fragment Caching

HTML Fragment Caching takes a different approach - it caches the final rendered HTML output, not just the data. This means:

✅ Zero database queries on cache hits

✅ Zero Blade rendering on cache hits

✅ Zero string processing on cache hits

✅ Instant HTML delivery to users

Real-World Impact

In a recent project, implementing HTML fragment caching reduced average response times from 800ms to 120ms for dashboard pages. That's an 85% performance improvement with zero code changes to business logic.

Here's what the transformation looks like:

Before (Traditional Caching):

Request → Database Query (cached) → Data Processing → Blade Rendering → HTML Output
Time: ~800ms

After (HTML Fragment Caching):

Request → Cached HTML Output
Time: ~120ms

Introducing Laravel HTML Fragment Cache

As an open source contributor, I've been working on a package that makes HTML fragment caching dead simple in Laravel applications. Here's why it's different:

🎯 Universal Cache Support

Works with Redis, Memcached, Database, File, Array, DynamoDB, and Octane - no vendor lock-in.

🔧 Developer-Friendly

// Simple facade usage
$html = FragmentCache::rememberHtml(
    identifier: "customer:{$customer->id}",
    builder: function () use ($customer) {
        return view('components.products-widget', [
            'products' => $customer->products()->featured()->get()
        ])->render();
    },
    ttl: '6 hours'
);

🎨 Blade Directive Support

@fragmentCache('products:featured')
    <div class="featured-products">
        @foreach($featuredProducts as $product)
            <div class="product">{{ $product->name }}</div>
        @endforeach
    </div>
@endFragmentCache

🚀 Livewire Integration

Perfect for caching expensive Livewire component rendering with a simple trait:

class ProductDashboard extends Component
{
    use CachesRenderedHtml;

    public function render()
    {
        return $this->renderCached(function () {
            // Expensive operations only run on cache miss
            return view('livewire.product-dashboard')->render();
        });
    }
}

The Business Case for HTML Fragment Caching

💰 Cost Reduction

Reduced server load: Less CPU usage means smaller server instances
Lower database costs: Fewer queries mean less database load
CDN efficiency: Cached HTML can be served from edge locations

📈 User Experience

Faster page loads: Users see content instantly
Better SEO: Google rewards fast-loading pages
Higher conversion rates: Every 100ms improvement can increase conversions by 1%

🛠️ Developer Experience

Zero refactoring: Works with existing code
Easy debugging: Can be disabled per environment
Flexible invalidation: Cache specific fragments when data changes

When to Use HTML Fragment Caching

Perfect for:

Dashboard widgets and components
Product listings and catalogs
User-specific content (with proper identifiers)
API responses that return HTML
Expensive report generation

Not ideal for:

Highly dynamic, user-specific content
Real-time data that changes frequently
Content that's already cached at the CDN level

Getting Started

The package is designed to be production-ready with comprehensive documentation, tests, and examples. It follows Laravel conventions and integrates seamlessly with existing applications.

composer require iperamuna/laravel-html-fragment-cache

The Open Source Philosophy

As someone who contributes to open source projects, I believe in building tools that solve real problems for developers. This package emerged from solving performance challenges in production applications, and I'm excited to share it with the Laravel community.

The source code is available on GitHub with:

✅ Comprehensive test coverage
✅ Detailed documentation
✅ Real-world examples
✅ CI/CD pipeline
✅ MIT license

Key Takeaways

HTML Fragment Caching can provide massive performance improvements with minimal code changes
Cache the output, not just the data - this is often the missing piece in performance optimization
Choose the right tool - make sure your caching solution works with your existing infrastructure
Measure the impact - always benchmark before and after implementing caching strategies

What's Your Experience?

I'd love to hear about your caching strategies and performance optimization experiences. What challenges have you faced with caching in your applications? Have you tried HTML fragment caching before?

Let's discuss in the comments below! 👇

🔗 Share This Article

If you found this article helpful, please consider sharing it with your network:

• 📘 Facebook • 💼 LinkedIn • 🐦 Twitter • 💬 WhatsApp • 📋 Copy link

Tags: #Laravel #PHP #WebDevelopment #Performance #Caching #OpenSource #SoftwareEngineering #WebOptimization

GitHub Repository: iperamuna/laravel-html-fragment-cache

Connect with me for more insights on web development, performance optimization, and open source contributions.
Facebook • LinkedIn • WhatsApp

Enhancing Object-Oriented Design with Traits, Interfaces, and Abstract Classes

Indunil Peramuna — Mon, 29 Jul 2024 18:15:18 +0000

In object-oriented programming, maintaining a clean and modular design is crucial for creating scalable and maintainable applications. By leveraging design patterns and principles, developers can create code that is both flexible and easy to extend. This article explores how using traits, interfaces, and abstract classes can enhance your design, with a focus on Data Transfer Objects (DTOs) as a practical example.

Understanding the Basics: Traits, Interfaces, and Abstract Classes

Traits:
Traits are a mechanism for code reuse in single inheritance languages like PHP. They allow you to define methods that can be used in multiple classes, promoting code reuse without requiring inheritance.

Interfaces:
Interfaces define a contract that classes must adhere to. They specify which methods a class must implement, ensuring consistency and allowing for polymorphism.

Abstract Classes:
Abstract classes provide a base class that other classes can extend. They can include abstract methods (which must be implemented by subclasses) and concrete methods (which can be used as-is or overridden).

Practical Example: Implementing Traits, Interfaces, and Abstract Classes in DTOs

To illustrate how traits, interfaces, and abstract classes work together, let's use the example of Data Transfer Objects (DTOs). DTOs are used to transfer data between different layers of an application without including business logic. We'll create a flexible and maintainable DTO system by leveraging these object-oriented principles.

1. Defining the Abstract Base Class

The BaseDTO abstract class provides common functionality for all DTOs, such as converting data to an array or JSON format and initialising from an array.

App/Dto/BaseDTO.php

namespace App\Dto;

/**
 * Abstract class BaseDTO
 * 
 * Provides common functionality for Data Transfer Objects (DTOs).
 */
abstract class BaseDTO
{
    /**
     * BaseDTO constructor.
     *
     * @param array $data Initial data to populate the DTO.
     */
    public function __construct(array $data = [])
    {
        $this->setFromArray($data);
    }

    /**
     * Convert the DTO to an array.
     *
     * @return array The DTO as an associative array.
     */
    public function toArray(): array
    {
        $properties = get_object_vars($this);
        return array_filter($properties, function ($property) {
            return $property !== null;
        });
    }

    /**
     * Convert the DTO to a JSON string.
     *
     * @return string The DTO as a JSON string.
     */
    public function toJson(): string
    {
        return json_encode($this->toArray());
    }

    /**
     * Set the DTO properties from an array.
     *
     * @param array $data The data to set on the DTO.
     */
    protected function setFromArray(array $data): void
    {
        foreach ($data as $key => $value) {
            if (property_exists($this, $key)) {
                $this->$key = $value;
            }
        }
    }
}

2. Creating Specific Interfaces

Interfaces define the specific methods that our DTOs need to implement based on different data sources, such as models, APIs, and CSV files.

App/Contracts/Dto/SetFromModel.php

/**
 * Interface SetFromModel
 * 
 * Defines a method for setting DTO properties from a model.
 */
interface SetFromModel
{
    /**
     * Set DTO properties from a model.
     *
     * @param mixed $model The model to set properties from.
     * @return self
     */
    public function setFromModel($model): self;
}

App/Contracts/Dto/SetFromAPI.php

/**
 * Interface SetFromAPI
 * 
 * Defines a method for setting DTO properties from API data.
 */
interface SetFromAPI
{
    /**
     * Set DTO properties from API data.
     *
     * @param array $data The API data to set properties from.
     * @return self
     */
    public function setFromAPI(array $data): self;
}

App/Contracts/Dto/SetFromCSV.php

/**
 * Interface SetFromCSV
 * 
 * Defines a method for setting DTO properties from CSV data.
 */
interface SetFromCSV
{
    /**
     * Set DTO properties from CSV data.
     *
     * @param array $data The CSV data to set properties from.
     * @return self
     */
    public function setFromCSV(array $data): self;
}

3. Implementing Traits for Reusability

Traits allow us to define reusable methods for setting data from various sources, making it easy to share functionality across different DTOs.

App/Traits/Dto/SetFromModelTrait.php

namespace App\Traits\Dto;

trait SetFromModelTrait
{
    public function setFromModel($model): self
    {
        foreach (get_object_vars($model) as $key => $value) {
            if (property_exists($this, $key)) {
                $this->$key = $value;
            }
        }

        return $this;
    }
}

App/Traits/Dto/SetFromAPITrait.php

namespace App\Traits\Dto;

/**
 * Trait SetFromModelTrait
 * 
 * Provides a method for setting DTO properties from a model.
 */
trait SetFromModelTrait
{
    /**
     * Set DTO properties from a model.
     *
     * @param mixed $model The model to set properties from.
     * @return self
     */
    public function setFromModel($model): self
    {
        foreach (get_object_vars($model) as $key => $value) {
            if (property_exists($this, $key)) {
                $this->$key = $value;
            }
        }

        return $this;
    }
}

App/Traits/Dto/SetFromCSVTrait.php

namespace App\Traits\Dto;

/**
 * Trait SetFromCSVTrait
 * 
 * Provides a method for setting DTO properties from CSV data.
 */
trait SetFromCSVTrait
{
    /**
     * Set DTO properties from CSV data.
     *
     * @param array $data The CSV data to set properties from.
     * @return self
     */
    public function setFromCSV(array $data): self
    {
        // Assuming CSV data follows a specific structure
        $this->name = $data[0] ?? null;
        $this->address = $data[1] ?? null;
        $this->price = isset($data[2]) ? (float)$data[2] : null;
        $this->subscription = $data[3] ?? null;
        $this->assets = isset($data[4]) ? explode(',', $data[4]) : [];

        return $this;
    }
}

4. Implementing the Concrete DTO Class

Finally, implement the concrete PropertyDTO class that utilizes the abstract class, interfaces, and traits.

namespace App\DTO;

use App\Contracts\SetFromModel;
use App\Contracts\SetFromAPI;
use App\Contracts\SetFromCSV;
use App\DTO\Traits\SetFromModelTrait;
use App\DTO\Traits\SetFromAPITrait;
use App\DTO\Traits\SetFromCSVTrait;

/**
 * Class PropertyDTO
 * 
 * Represents a Property Data Transfer Object.
 */
readonly class PropertyDTO extends BaseDTO implements SetFromModel, SetFromAPI, SetFromCSV
{
    use SetFromModelTrait, SetFromAPITrait, SetFromCSVTrait;

    /**
     * @var string The name of the property.
     */
    public string $name;

    /**
     * @var string The address of the property.
     */
    public string $address;

    /**
     * @var float The price of the property.
     */
    public float $price;

    /**
     * @var ?string The subscription type of the property.
     */
    public ?string $subscription;

    /**
     * @var ?array The assets of the property.
     */
    public ?array $assets;

    // Other specific methods can be added here
}

Best Practices for Using Traits, Interfaces, and Abstract Classes

Encapsulation of Behavior: Use traits to encapsulate common behavior that can be reused across multiple classes, reducing duplication and improving maintainability.
Defining Clear Contracts: Interfaces should define clear contracts for what methods a class must implement, ensuring consistency and allowing for easy swapping of implementations.
Providing Base Functionality: Abstract classes offer a base for shared functionality, allowing subclasses to extend and customize as needed while maintaining a common structure.
Enhancing Flexibility: Combining these techniques allows for a flexible design where classes can implement only the necessary interfaces and use relevant traits, making it easier to extend and adapt your code.
Maintaining Consistency: By using abstract classes and traits, you ensure that your code remains consistent and follows a predictable pattern, which is crucial for long-term maintainability.

Conclusion

Integrating traits, interfaces, and abstract classes into your design provides a powerful way to manage and structure your code. By applying these principles, you create a modular, maintainable, and scalable system that adheres to best practices in object-oriented programming. Whether you're working with DTOs or other components, leveraging these techniques helps ensure that your codebase remains clean and adaptable.

Final Thoughts

Embracing object-oriented principles and patterns such as traits, interfaces, and abstract classes not only improves code quality but also enhances your ability to manage complex systems. By understanding and applying these concepts, you can build robust applications that are both flexible and maintainable.

Explore the Advantages of Data Transfer Objects (DTOs) and How PHP 8.2 Readonly Classes Can Elevate Your Laravel Code

Indunil Peramuna — Mon, 29 Jul 2024 18:10:25 +0000

In modern web application development, efficiently and securely managing and transferring data is crucial. One design pattern that significantly aids in this process is the Data Transfer Object (DTO). This post will delve into the advantages of using DTOs, particularly in a Laravel application, and show how PHP 8.2 readonly classes can further enhance their benefits.

What is a Data Transfer Object (DTO)?

A Data Transfer Object (DTO) is a simple object designed to carry data between processes or systems. Unlike typical models or entities, DTOs are free from business logic. They encapsulate data, providing a clear and structured way to transfer information between different layers of an application or between various systems.

DTO Pattern

The DTO pattern is utilized to transfer data across different subsystems within a software application. The main objectives of using DTOs are to minimize the number of method calls, aggregate the necessary data, and offer a structured approach to managing data transformations and validations.

Benefits of Using DTOs

Separation of Concerns: DTOs isolate business logic from data representation, resulting in cleaner, more maintainable code that’s easier to understand.
Data Validation: DTOs allow for validation of data before it's processed by other application layers, ensuring that only valid data is used.
Consistency: By providing a consistent structure for data transfer, DTOs simplify the management and processing of data from various sources.
Security: DTOs can safeguard your application against unauthorized data manipulation by controlling which data is accessible and modifiable.
Testing: Since DTOs are straightforward objects without embedded business logic, they are simpler to mock and test.
Transformation: DTOs facilitate the transformation of data into formats required by different application layers.
Immutability: DTOs often promote immutability, meaning once created, their state cannot change. This feature brings several advantages:
- Predictability: Immutable objects are predictable and easier to reason about, as their state remains constant post-creation.
- Thread-Safety: Immutability inherently supports thread-safety, simplifying concurrent processing.
- Debugging: Debugging is easier with immutable objects because their state is guaranteed to remain unchanged throughout their lifecycle.

PHP 8.2 and Readonly Classes

With PHP 8.2, the introduction of readonly classes enhances the use of DTOs. Readonly classes eliminate the need to explicitly define properties as readonly, simplifying your DTO implementations. Here’s how PHP 8.2’s readonly classes improve DTOs:

Simplified Code: Readonly classes automatically make properties immutable, reducing boilerplate code and improving clarity.
Enhanced Security: By ensuring properties cannot be modified once set, readonly classes enhance data integrity and security.
Improved Maintainability: The use of readonly classes leads to cleaner, more maintainable code, as the immutability of data is enforced by the language itself.

Example: Using DTOs in a Property Management System

Let's consider a property management system where properties can come from various sources such as an API and CSV imports. We can use DTOs to create the Property model, Subscriptions, Assets, etc., ensuring that the data is consistent and validated across the application.

Defining the PropertyDTO

First, let's define a PropertyDTO class:

app/DTO/PropertyDTO.php

namespace App\DTO;

/**
 * Class PropertyDTO
 *
 * Represents a Data Transfer Object for property data.
 */
readonly class PropertyDTO extends AbstractDTO
{
    /**
     * The name of the property.
     *
     * @var string
     */
    public string $name;

    /**
     * The address of the property.
     *
     * @var string
     */
    public string $address;

    /**
     * The price of the property.
     *
     * @var float
     */
    public float $price;

    /**
     * The subscription status of the property, if applicable.
     *
     * @var string|null
     */
    public ?string $subscription;

    /**
     * The list of assets associated with the property.
     *
     * @var array|null
     */
    public ?array $assets;

    /**
     * Set the properties from a model instance.
     *
     * @param $model The model instance.
     * @return $this
     */
    public function setFromModel($model): self
    {
        $this->name = $model->name;
        $this->address = $model->address;
        $this->price = $model->price;
        $this->subscription = $model->subscription;
        $this->assets = $model->assets;

        return $this;
    }

    /**
     * Set the properties from API data.
     *
     * @param array $data The API data.
     * @return $this
     */
    public function setFromAPI(array $data): self
    {
        $this->name = $data['property_name'];
        $this->address = $data['property_address'];
        $this->price = $data['property_price'];
        $this->subscription = $data['subscription'] ?? null;
        $this->assets = $data['assets'] ?? null;

        return $this;
    }

    /**
     * Set the properties from CSV data.
     *
     * @param array $data The CSV data.
     * @return $this
     */
    public function setFromCSV(array $data): self
    {
        $this->name = $data[0];
        $this->address = $data[1];
        $this->price = (float) $data[2];
        $this->subscription = $data[3] ?? null;
        $this->assets = explode(',', $data[4] ?? '');

        return $this;
    }
}

Using the PropertyDTO

Here's how you can use the PropertyDTO to handle properties from different sources:

// From a Model
$model = Property::find(1);
$propertyDTO = (new PropertyDTO([]))->setFromModel($model);

// From an API
$apiData = [
    'property_name' => 'Beautiful House',
    'property_address' => '1234 Elm Street',
    'property_price' => 450000,
    'subscription' => 'Premium',
    'assets' => ['pool', 'garden']
];
$propertyDTO = (new PropertyDTO([]))->setFromAPI($apiData);

// From a CSV
$csvData = ['Beautiful House', '1234 Elm Street', 450000, 'Premium', 'pool,garden'];
$propertyDTO = (new PropertyDTO([]))->setFromCSV($csvData);

// Convert to Array
$arrayData = $propertyDTO->toArray();

// Convert to JSON
$jsonData = $propertyDTO->toJson();

Summary

Data Transfer Objects (DTOs) offer numerous advantages in Laravel applications by ensuring data consistency, validation, and separation of concerns. By implementing DTOs, you can make your application more maintainable, secure, and easier to test. In a property management system, DTOs help in handling data from various sources like APIs and CSV imports efficiently, ensuring that your business logic remains clean and focused on processing validated data.

Moreover, embracing immutability within DTOs enhances predictability, thread-safety, and simplifies debugging.

Extending DTOs with Abstract Classes for Consistency

To streamline the creation of DTOs and promote code reuse, we can use an abstract class or base class. This approach allows us to define common methods and properties in the abstract class and extend it for specific data sources.

Defining the AbstractDTO

app/DTO/AbstractDTO.php

namespace App\DTO;

/**
 * AbstractDTO
 *
 * An abstract base class for Data Transfer Objects (DTOs).
 * Provides common methods and properties for DTO implementations.
 */
abstract class AbstractDTO
{
    /**
     * AbstractDTO constructor.
     *
     * Initialises the DTO with data from an associative array.
     *
     * @param array $data The data array to initialize the DTO.
     */
    public function __construct(array $data)
    {
        $this->setFromArray($data);
    }

    /**
     * Set the properties of the DTO from a model instance.
     *
     * @param $model The model instance from which to populate the DTO.
     * @return $this
     */
    abstract public function setFromModel($model): self;

    /**
     * Set the properties of the DTO from API data.
     *
     * @param array $data The data array from the API.
     * @return $this
     */
    abstract public function setFromAPI(array $data): self;

    /**
     * Set the properties of the DTO from CSV data.
     *
     * @param array $data The data array from the CSV.
     * @return $this
     */
    abstract public function setFromCSV(array $data): self;

    /**
     * Convert the DTO to an associative array.
     *
     * @return array The DTO data as an associative array.
     */
    public function toArray(): array
    {
        $properties = get_object_vars($this);
        return array_filter($properties, function ($property) {
            return $property !== null;
        });
    }

    /**
     * Convert the DTO to a JSON string.
     *
     * @return string The DTO data as a JSON string.
     */
    public function toJson(): string
    {
        return json_encode($this->toArray());
    }

    /**
     * Set the properties of the DTO from an associative array.
     *
     * @param array $data The data array to populate the DTO.
     */
    protected function setFromArray(array $data): void
    {
        foreach ($data as $key => $value) {
            if (property_exists($this, $key)) {
                $this->$key = $value;
            }
        }
    }
}

Final Thoughts

Using an abstract or base class for DTOs not only ensures consistency across different DTO implementations but also promotes code reuse and maintainability. By defining common methods and properties in an abstract class, you can create a structured and efficient way to manage data transfer within your application. This approach aligns well with the principles of clean code and helps in building scalable and robust applications.

Here’s a revised phrase that includes a call to action:

"By leveraging DTOs and abstract classes together, you can refine your Laravel application's design, improving how data is managed and ensuring a more organised and efficient data flow. If you want to further encapsulate and enhance your DTOs with traits and interfaces, explore our guide on Enhancing Object-Oriented Design with Traits, Interfaces, and Abstract Classes."

Laravel 9 with Inertia.js + Vite + Vue.js + Tailwind CSS from Laravel

Indunil Peramuna — Tue, 13 Dec 2022 06:45:06 +0000

Hello, Here I m writing a guide to setup a Laravel 9 Web App with Inertiajs and Vue3. Here i m not explaining the process much but the steps of getting the example app up and running.

Getting Started

Setting up laravel 9 - Latest

curl -s "https://laravel.build/example-app" | bash

replace 'example-app' with your app name

Install VueJs - Latest

npm install vue@next

Installing Inertia.js in Laravel

composer require inertiajs/inertia-laravel
php artisan inertia:middleware

HandleInertiaRequests.php will be created inside app/Http/Middleware. We'll just need to add this middleware to the web middleware group inside app/Http/Kernel.php:

'web' => [
    // ...
    \App\Http\Middleware\HandleInertiaRequests::class,
],

Coming next is the Inertia's client side. We're using Vue 3, so we'll install Inertia alongside with the Vue 3 adapter:

Installing Inertia.js in NPM

npm install @inertiajs/inertia @inertiajs/inertia-vue3

Let's throw in the Inertia's progress bar. This will be used as a loading indicator between page navigation.

npm install @inertiajs/progress

Ziggy Inertia uses Laravel's routes, so we won't need to use a client side router, but to make use of Laravel's web.php routes, we have to pass them to the DOM somehow. The easiest way to do it to use Ziggy. Let's install Ziggy:

composer require tightenco/ziggy

Ziggy Setup Let's get back to Ziggy and generate the .js file that contains all of our routes. We'll gonna import this into our app.js a bit later.

php artisan ziggy:generate resources/js/ziggy.js

Installing Tailwind CSS

Tailwind requires the least amount of effort. We just need to install postcss and autoprefixer too.

npm install -D tailwindcss postcss autoprefixer
npm i @tailwindcss/forms

Let's create the tailwind config file...

npx tailwindcss init

We also have to add the Tailwind's directives to resources/css/app.css:

@tailwind base;
@tailwind components;
@tailwind utilities;

Tailwind and PostCSS Change the tailwind.config.js with following

module.exports = {
    mode: "jit",
    purge: ['./resources/**/*.{js,jsx,ts,tsx,vue,blade.php}'],
    theme: {},
    variants: {},
    plugins: [],
}

Change the postcss.config.js with following

module.exports = {
    plugins: {
        tailwindcss: {},
        autoprefixer: {},
    },
}

Setting up vite.config.js

Following is the vite config with all the settings.

import { defineConfig } from 'vite';
import laravel from 'laravel-vite-plugin';
import vue from '@vitejs/plugin-vue';

export default defineConfig({
    plugins: [
        laravel({
            input: ['resources/js/app.js'],
            refresh: true,
        }),
        vue({
            template: {
                transformAssetUrls: {
                    base: null,
                    includeAbsolute: false,
                },
            },
        }),
    ],
    resolve: {
        alias: {
            'ziggy': '/vendor/tightenco/ziggy/src/js',
            'ziggy-vue': '/vendor/tightenco/ziggy/src/js/vue'
        },
    },
});

Finally, let's deal with app.js

import { createApp, h } from "vue";
import { createInertiaApp, Link, Head } from "@inertiajs/inertia-vue3";
import { InertiaProgress } from "@inertiajs/progress";
import { resolvePageComponent } from 'laravel-vite-plugin/inertia-helpers';

import { ZiggyVue } from "ziggy-vue";
import { Ziggy } from "./ziggy";
import '../css/app.css';

InertiaProgress.init();

createInertiaApp({
    resolve: async (name) => resolvePageComponent(`./Pages/${name}.vue`, import.meta.glob('./Pages/**/*.vue')),
    setup({ el, App, props, plugin }) {
        createApp({ render: () => h(App, props) })
            .use(plugin)
            .use(ZiggyVue, Ziggy)
            .component("Link", Link)
            .component("Head", Head)
            .mixin({ methods: { route } })
            .mount(el);
    },
});

Setup your Views

app.blade.php

Create file called app.blade.php inside your /resources/views folder and basically it will act as a bootstrap for vue + inertiajs.

<!DOCTYPE html>
<html lang="{{ str_replace('_', '-', app()->getLocale()) }}">

<head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">

    @routes
    @vite('resources/js/app.js')
    @inertiaHead
</head>

<body>
@inertia
</body>

</html>

Vue Pages You will have to create a folder inside your /resources/js called Pages.

sample welcome.vue

<template>
    <head title="Homepage Title"></head>
    <h1>Homepage </h1>
</template>

Building your app

Last thing we need to do is to change our package.json's scripts.

{
    "dev": "vite",
    "build": "vite build"
}

Now, in order to build you will have to firstly generate the ziggy.js file by running:

// You can find this command in the previous guide
php artisan ziggy:generate resources/js/ziggy.js

Then you can run the dev or build:

npm run dev

Also, make sure you clear your view cache because this might cause some issues after the migrations: php artisan view:cache.

DEV Community: Indunil Peramuna

The One-Line MySQL 8 Switch to Auto-Optimize Your Dedicated Database Infrastructure

What Happens Under the Hood?

1. innodb_buffer_pool_size (The Memory Footprint)

2. innodb_flush_method (Eliminating OS Overhead)

3. innodb_log_file_size & innodb_log_files_in_group (Redo Log Optimization)

4. innodb_log_buffer_size

🛠️ The Implementation Rule: Clean Your Config First

⚠️ The Architectural Guardrails (When NOT to use it)

Do NOT turn this on if:

Summary

Supercharge Your PHP Apps with FrankenPHP Classic Mode

Supercharge Your PHP Apps with FrankenPHP Classic Mode

What is Classic Mode?

Why it's better:

Static vs Dynamic (Glibc) Builds

The Tool

The Guide

Manual Steps Summary

Automated Way

Why HTML Fragment Caching is the Performance Game-Changer Your Laravel App Needs

The Hidden Performance Bottleneck

The Traditional Caching Approach (And Why It Falls Short)

Enter HTML Fragment Caching

Real-World Impact

Introducing Laravel HTML Fragment Cache

🎯 Universal Cache Support

🔧 Developer-Friendly

🎨 Blade Directive Support

🚀 Livewire Integration

The Business Case for HTML Fragment Caching

💰 Cost Reduction

📈 User Experience

🛠️ Developer Experience

When to Use HTML Fragment Caching

Getting Started

The Open Source Philosophy

Key Takeaways

What's Your Experience?

🔗 Share This Article

Enhancing Object-Oriented Design with Traits, Interfaces, and Abstract Classes

Understanding the Basics: Traits, Interfaces, and Abstract Classes

Practical Example: Implementing Traits, Interfaces, and Abstract Classes in DTOs

1. Defining the Abstract Base Class

2. Creating Specific Interfaces

3. Implementing Traits for Reusability

4. Implementing the Concrete DTO Class

Best Practices for Using Traits, Interfaces, and Abstract Classes

Conclusion

Final Thoughts

Explore the Advantages of Data Transfer Objects (DTOs) and How PHP 8.2 Readonly Classes Can Elevate Your Laravel Code

What is a Data Transfer Object (DTO)?

DTO Pattern

Benefits of Using DTOs

PHP 8.2 and Readonly Classes

Example: Using DTOs in a Property Management System

Defining the PropertyDTO

Using the PropertyDTO

Summary

Extending DTOs with Abstract Classes for Consistency

Defining the AbstractDTO

Final Thoughts

Laravel 9 with Inertia.js + Vite + Vue.js + Tailwind CSS from Laravel

Getting Started

Setting up vite.config.js

Finally, let's deal with app.js

Setup your Views

Building your app

1. `innodb_buffer_pool_size` (The Memory Footprint)

2. `innodb_flush_method` (Eliminating OS Overhead)

3. `innodb_log_file_size` & `innodb_log_files_in_group` (Redo Log Optimization)

4. `innodb_log_buffer_size`