Laravel Octane is an official package for the Laravel framework that dramatically boosts application performance by running Laravel on high-performance application servers like Swoole or RoadRunner.

⚡ What Makes Laravel Octane Special?

Instead of reloading the Laravel framework on every HTTP request (as with traditional PHP-FPM setups), Octane keeps the application in memory, avoiding repeated bootstrapping. This makes your Laravel app much faster.

🔧 How Does It Work?

Laravel Octane uses persistent worker servers (e.g., Swoole or RoadRunner), which:

1. Bootstrap the Laravel application once,

2. Then handle incoming requests repeatedly without restarting the framework.

🚀 Benefits of Laravel Octane

RoadRunner is a high-performance PHP application server developed by Spiral Scout. It serves as a replacement for traditional PHP-FPM (FastCGI Process Manager) and offers a major performance boost by keeping your PHP application running persistently — especially useful with frameworks like Laravel or Symfony.

🚀 What Makes RoadRunner Special?

✅ Worker-Based Performance

• PHP scripts are not reloaded on every request. Instead, they run continuously in persistent worker processes (similar to Node.js or Swoole).

• This eliminates the need to re-bootstrap the framework on every request — resulting in significantly faster response times than with PHP-FPM.

✅ Built with Go

• RoadRunner is written in the programming language Go, which provides high concurrency, easy deployment, and great stability.

✅ Features

• Native HTTP server (with HTTPS, Gzip, CORS, etc.)

• PSR-7 and PSR-15 middleware support

• Supports:

  • Queues (e.g., Redis, RabbitMQ)

  • gRPC

  • WebSockets

  • Static file serving

  • Prometheus metrics

  • RPC between Go and PHP

• Hot reload support with a watch plugin

⚙️ How Does It Work?

1. RoadRunner starts PHP worker processes.

2. These workers load your full framework bootstrap once.

3. Incoming HTTP or gRPC requests are forwarded to the PHP workers.

4. The response is returned through the Go layer — fast and concurrent.

📦 Common Use Cases:

• Laravel + RoadRunner (instead of Laravel + PHP-FPM)

• High-traffic applications and APIs

• Microservices

• Real-time apps (e.g., using WebSockets)

• Low-latency, serverless-like services

📉 RoadRunner vs PHP-FPM

PDO stands for PHP Data Objects and it's a database abstraction layer in PHP. It provides an object-oriented interface to access different types of databases—such as MySQL, PostgreSQL, or SQLite—without needing to change much of your code.

Key Features of PDO:

✅ Consistent API
Same code style regardless of which database you use.

✅ Prepared Statements
Helps prevent SQL injection via bound parameters:

$stmt = $pdo->prepare("SELECT * FROM users WHERE id = :id");
$stmt->execute(['id' => $userId]);

✅ Transactions Support
Great for use cases like banking systems or other operations that need rollback/commit.

✅ Exception-based Error Handling

$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

✅ Easy Database Switching
Switching from MySQL to PostgreSQL? Usually only the DSN and driver need to be changed.

Example: Connecting to MySQL with PDO

$dsn = 'mysql:host=localhost;dbname=testdb;charset=utf8mb4';
$user = 'root';
$pass = '';

try {
    $pdo = new PDO($dsn, $user, $pass);
    $pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
    echo "Connected successfully!";
} catch (PDOException $e) {
    echo "Connection failed: " . $e->getMessage();
}

Summary:

PDO is the recommended way to work with databases in modern PHP applications—especially for its security, flexibility, and ease of use.

Doctrine DBAL (Database Abstraction Layer) is a PHP library that provides an abstraction layer for database access. It is part of the Doctrine project (a popular ORM for PHP), but it can be used independently of the ORM.

Purpose and Benefits of Doctrine DBAL:

Doctrine DBAL offers a unified API to interact with different databases (such as MySQL, PostgreSQL, SQLite, etc.) without writing raw SQL specific to each database system.

Key Features of Doctrine DBAL:

• Connection Management

• • Easily configure and manage connections to various database systems.

  • Supports connection pooling, transactions, and more.

• SQL Query Builder

• • Build SQL queries programmatically using an object-oriented API:

$qb = $conn->createQueryBuilder();
$qb->select('u.id', 'u.name')
   ->from('users', 'u')
   ->where('u.age > :age')
   ->setParameter('age', 18);
$stmt = $qb->executeQuery();

• Database Independence

  • The same code works with different database systems (e.g., MySQL, PostgreSQL) with minimal changes.

• Schema Management

  • Tools to create, update, and compare database schemas.

  • Useful for migrations and automation.

• Data Type Conversion

  • Automatically converts data between PHP types and database-native types.

use Doctrine\DBAL\DriverManager;

$conn = DriverManager::getConnection([
    'dbname' => 'test',
    'user' => 'root',
    'password' => '',
    'host' => 'localhost',
    'driver' => 'pdo_mysql',
]);

$result = $conn->fetchAllAssociative('SELECT * FROM users');

When to Use DBAL Instead of ORM:

You might choose DBAL without ORM if:

• You want full control over your SQL.

• Your project doesn't need complex object-relational mapping.

• You're working with a legacy database or custom queries.

Summary:

Doctrine DBAL is a powerful tool for clean, portable, and secure database access in PHP. It sits between raw PDO usage and a full-featured ORM like Doctrine ORM, making it ideal for developers who want abstraction and flexibility without the overhead of ORM logic.

The Whoops PHP library is a powerful and user-friendly error handling tool for PHP applications. It provides clear and well-structured error pages, making it easier to debug and fix issues.

Key Features of Whoops

✅ Beautiful, interactive error pages
✅ Detailed stack traces with code previews
✅ Easy integration into existing PHP projects
✅ Support for various frameworks (Laravel, Symfony, Slim, etc.)
✅ Customizable with custom handlers and loggers

Installation

You can install Whoops using Composer:

composer require filp/whoops

Basic Usage

Here's a simple example of how to enable Whoops in your PHP project:

require 'vendor/autoload.php';

use Whoops\Run;
use Whoops\Handler\PrettyPageHandler;

$whoops = new Run();
$whoops->pushHandler(new PrettyPageHandler());
$whoops->register();

// Trigger an error (e.g., calling an undefined variable)
echo $undefinedVariable;

If an error occurs, Whoops will display a clear and visually appealing debug page.

Customization & Extensions

You can extend Whoops by adding custom error handling, for example:

use Whoops\Handler\CallbackHandler;

$whoops->pushHandler(new CallbackHandler(function ($exception, $inspector, $run) {
    error_log($exception->getMessage());
}));

This version logs errors to a file instead of displaying them.

Use Cases

Whoops is mainly used in development environments to quickly detect and fix errors. However, in production environments, it should be disabled or replaced with a custom error page.

What is Twig?

Twig is a powerful and flexible templating engine for PHP, commonly used in Symfony but also in other PHP projects. It helps separate logic from presentation and offers many useful features for frontend development.

Key Features of Twig

1. Simple Syntax with Placeholders ({{ }})

Twig uses double curly braces to output variables:

<p>Hello, {{ name }}!</p>

→ If name = "Max", the output will be:
"Hello, Max!"

2. Control Structures ({% %})

Twig supports if-else statements, loops, and other control structures.

If-Else

{% if user.isAdmin %}
    <p>Welcome, Admin!</p>
{% else %}
    <p>Welcome, User!</p>
{% endif %}

Loops (for)

<ul>
{% for user in users %}
    <li>{{ user.name }}</li>
{% endfor %}
</ul>

3. Template Inheritance

Twig supports "Base Layouts", similar to Laravel's Blade.

Parent Template (base.html.twig)

<!DOCTYPE html>
<html>
<head>
    <title>{% block title %}My Page{% endblock %}</title>
</head>
<body>
    <header>{% block header %}Default Header{% endblock %}</header>
    <main>{% block content %}{% endblock %}</main>
</body>
</html>

Child Template (page.html.twig)

{% extends 'base.html.twig' %}

{% block title %}Homepage{% endblock %}

{% block content %}
    <p>Welcome to my website!</p>
{% endblock %}

→ The blocks override the default content from the base template.

4. Including Templates

You can include reusable components like a navbar or footer:

{% include 'partials/navbar.html.twig' %}

5. Filters & Functions

Twig provides many filters to format content:

6. Security & Escaping

Twig automatically escapes HTML to prevent XSS attacks:

{{ "<script>alert('XSS');</script>" }}

→ Outputs: <script>alert('XSS');</script>

To output raw HTML, use |raw:

{{ "<strong>Bold</strong>"|raw }}

7. Extensibility

• Twig supports custom filters & functions.
• You can use PHP objects and arrays directly inside Twig.

PSR-12 is a coding style guideline defined by the PHP-FIG (PHP Framework Interoperability Group). It builds on PSR-1 (Basic Coding Standard) and PSR-2 (Coding Style Guide), extending them to include modern practices and requirements.

Purpose of PSR-12

PSR-12 aims to establish a consistent and readable code style for PHP projects, facilitating collaboration between developers and maintaining a uniform codebase.

Key Guidelines of PSR-12

1. Indentation

• Use 4 spaces for indentation (no tabs).

2. Line Length

• Maximum line length should not exceed 120 characters.
• Code may be broken into multiple lines for better readability.

3. Namespace and Use Statements

• Add one blank line after the namespace declaration.
• use statements should follow the namespace declaration.
• Imported classes, functions, and constants should be alphabetically sorted without blank lines between them.

namespace App\Controller;

use App\Service\MyService;
use Psr\Log\LoggerInterface;

4. Classes

• The opening { for a class or method must be placed on the next line.
• Visibility (public, protected, private) is mandatory for all methods and properties.

class MyClass
{
    private string $property;

    public function myMethod(): void
    {
        // code
    }
}

5. Methods and Functions

• Each parameter must be placed on a new line if the parameter list is wrapped.
• Return types should be explicitly declared.

public function myFunction(
    int $param1,
    string $param2
): string {
    return 'example';
}

6. Control Structures (if, while, for, etc.)

• The opening { must be on the same line as the control structure.
• A space is required between the control structure and the condition.

if ($condition) {
    // code
} elseif ($otherCondition) {
    // code
} else {
    // code
}

7. Arrays

• Use the short syntax ([]) for arrays.
• In multiline arrays, each element should appear on a new line.

$array = [
    'first' => 'value1',
    'second' => 'value2',
];

8. Type Declarations

• Parameter, return, and property types are mandatory (where possible).
• Nullable types are prefixed with ?.

public function getValue(?int $id): ?string
{
    return $id !== null ? (string) $id : null;
}

9. Files

• PHP files must start with the <?php tag and must not include a closing ?> tag.
• Add blank lines between declarations like classes or functions.

Differences from PSR-2

PSR-12 extends PSR-2 by:

• Supporting modern PHP features (e.g., nullable types, declare(strict_types=1), traits, type hinting).
• Clarifying rules for line lengths, wrapped method parameters, and arrays.
• Requiring explicit type declarations.

Benefits of PSR-12

• Simplifies code reviews.
• Improves readability and maintainability.
• Enhances interoperability between PHP projects.
• Ensures consistency with modern PHP practices.

Summary

PSR-12 is the standard for modern and consistent PHP code. It improves code quality and simplifies collaboration, especially in team environments. Tools like PHP_CodeSniffer or PHP-CS-Fixer can help ensure adherence to PSR-12 effortlessly.

PSR-11 is a PHP Standard Recommendation (PHP Standard Recommendation) that defines a Container Interface for dependency injection. It establishes a standard way to interact with dependency injection containers in PHP projects.

Purpose of PSR-11

PSR-11 was introduced to ensure interoperability between different frameworks, libraries, and tools that use dependency injection containers. By adhering to this standard, developers can switch or integrate various containers without modifying their code.

Core Components of PSR-11

PSR-11 specifies two main interfaces:

1. ContainerInterface
   This is the central interface providing methods to retrieve and check services in the container.

namespace Psr\Container;

interface ContainerInterface {
    public function get(string $id);
    public function has(string $id): bool;
}

• • get(string $id): Returns the instance (or service) registered in the container under the specified ID.
  • has(string $id): Checks whether the container has a service registered with the given ID.

• 2. NotFoundExceptionInterface
  This is thrown when a requested service is not found in the container.

namespace Psr\Container;

interface NotFoundExceptionInterface extends ContainerExceptionInterface {
}

3. ContainerExceptionInterface
A base exception for any general errors related to the container.

Benefits of PSR-11

• Interoperability: Enables various frameworks and libraries to use the same container.
• Standardization: Provides a consistent API for accessing containers.
• Extensibility: Allows developers to create their own containers that comply with PSR-11.

Typical Use Cases

PSR-11 is widely used in frameworks like Symfony, Laravel, and Zend Framework (now Laminas), which provide dependency injection containers. Libraries like PHP-DI or Pimple also support PSR-11.

Example

Here’s a basic example of using PSR-11:

use Psr\Container\ContainerInterface;

class MyService {
    public function __construct(private string $message) {}
    public function greet(): string {
        return $this->message;
    }
}

$container = new SomePSR11CompliantContainer();
$container->set('greeting_service', function() {
    return new MyService('Hello, PSR-11!');
});

if ($container->has('greeting_service')) {
    $service = $container->get('greeting_service');
    echo $service->greet(); // Output: Hello, PSR-11!
}

Conclusion

PSR-11 is an essential interface for modern PHP development, as it standardizes dependency management and resolution. It promotes flexibility and maintainability in application development.

PSR-7 is a PHP Standard Recommendation (PSR) that focuses on HTTP messages in PHP. It was developed by the PHP-FIG (Framework Interoperability Group) and defines interfaces for working with HTTP messages, as used by web servers and clients.

Key Features of PSR-7:

1. Request and Response:
   PSR-7 standardizes how HTTP requests and responses are represented in PHP. It provides interfaces for:

   • RequestInterface: Represents HTTP requests.
   • ResponseInterface: Represents HTTP responses.

2. Immutability:
   All objects are immutable, meaning that any modification to an HTTP object creates a new object rather than altering the existing one. This improves predictability and makes debugging easier.

3. Streams:
   PSR-7 uses stream objects to handle HTTP message bodies. The StreamInterface defines methods for interacting with streams (e.g., read(), write(), seek()).

4. ServerRequest:
   The ServerRequestInterface extends the RequestInterface to handle additional data such as cookies, server parameters, and uploaded files.

5. Middleware Compatibility:
   PSR-7 serves as the foundation for middleware architectures in PHP. It simplifies the creation of middleware components that process HTTP requests and manipulate responses.

Usage:

PSR-7 is widely used in modern PHP frameworks and libraries, including:

• Zend Diactoros
• Guzzle
• Slim Framework
• Laravel (via middleware)

Purpose:

The goal of PSR-7 is to improve interoperability between different PHP libraries and frameworks by defining a common standard for HTTP messages.

PSR-6 is a PHP-FIG (PHP Framework Interoperability Group) standard that defines a common interface for caching in PHP applications. This specification, titled "Caching Interface," aims to promote interoperability between caching libraries by providing a standardized API.

Key components of PSR-6 are:

1. Cache Pool Interface (CacheItemPoolInterface): Represents a collection of cache items. It's responsible for managing, fetching, saving, and deleting cached data.

2. Cache Item Interface (CacheItemInterface): Represents individual cache items within the pool. Each cache item contains a unique key and stored value and can be set to expire after a specific duration.

3. Standardized Methods: PSR-6 defines methods like getItem(), hasItem(), save(), and deleteItem() in the pool, and get(), set(), and expiresAt() in the item interface, to streamline caching operations and ensure consistency.

By defining these interfaces, PSR-6 allows developers to easily switch caching libraries or integrate different caching solutions without modifying the application's core logic, making it an essential part of PHP application development for caching standardization.