DEV Community: Lito

Database Cache for Laravel

Lito — Tue, 25 Jan 2022 12:39:18 +0000

Today I have released my new Laravel package Laravel Database Cache https://github.com/eusonlito/laravel-database-cache

This package allow to cache database queries from Models without pain.

You can configure the cache to use tags (on redis) and flush all database caches at once: https://github.com/eusonlito/laravel-database-cache#flush-caches

You can install the package via composer:

composer require eusonlito/laravel-database-cache

Publish the default configuration in config/database-cache.php:

php artisan vendor:publish --tag=eusonlito-database-cache

Add this lines to .env file:

DATABASE_CACHE_ENABLED=true
DATABASE_CACHE_DRIVER=redis
DATABASE_CACHE_TTL=3600
DATABASE_CACHE_TAG=database
DATABASE_CACHE_PREFIX=database|

And configure your models to use the cache method with:

<?php declare(strict_types=1);

namespace App\Models;

use Illuminate\Database\Eloquent\Model;
use Eusonlito\DatabaseCache\CacheBuilderTrait;

class User extends Model
{
    use CacheBuilderTrait;

Now, the simple way to use is:

$articles = Article::latest('published_at')->take(10)->cache()->get();

The results will be cached every time you will call this query.

Also you can set a custom cache time for this query:

$articles = Article::latest('published_at')->take(10)->cache(60)->get();

Or a custom cache name:

$articles = Article::latest('published_at')->take(10)->cache(60, 'latest_articles')->get();

You have more info at package https://github.com/eusonlito/laravel-database-cache

Enjoy!

Self-Hosted Password Manager (Laravel 8 + PHP 8 + MySQL 8)

Lito — Wed, 04 Aug 2021 12:12:03 +0000

I have published my personal Password Manager as self-hosted and open source project.

https://github.com/eusonlito/Password-Manager

Technologies are Laravel 8 + PHP 8 + MySQL 8.

Can be used as personal and company.

Main features are:

Users Management.
Teams management.
Access to applications limited by teams.
Multiple types of data records.
Encryption in database.
Authentication by certificate and double factor with Google Authenticator.
Using certificate, you can to disable password auth.
Logged every time a user accesses, consults or updates an application.
Allows private or shared applications.
It has a chrome extension that connects via API and directly accesses the credentials of the web you are visiting.

This project has an extension for Google Chrome that you can download at https://github.com/eusonlito/Password-Manager-Chrome

You can start with english README https://github.com/eusonlito/Password-Manager/blob/master/readme.md

What do you think?

Laravel Domains Panel

Lito — Mon, 28 Jun 2021 09:34:30 +0000

My company has released a tool for the internal control of domains, subdomains, certificates and URLs status.

https://github.com/nitsnets/Domains-Panel

The software is Laravel 8 + PHP 8 + MySQL 8.

Repository README is in spanish, but is easy to follow all steps:

Create the MySQL database.

Clone the repository.


  git clone https://github.com/nitsnets/Domains-Panel.git

Launch first time composer install with (remember to use PHP 8.0 binary).
```
  composer install --no-scripts && composer install
```
Configure the .env file with the necessary data.
```
  cp .env.example .env
```
Generate the application key.
```
  php artisan key:generate
```
Regenerate the cache.
```
  composer artisan-cache
```
Launch the initial migration.
```
  php artisan migrate
```

Launch the seeder.


  php artisan db:seed --class = Database\\Seeders\\Database

Configure the cron task for the user related to the project:


  * * * * * cd /var/www/status.domains.com/httpdocs && php artisan schedule:run >> storage/logs/artisan-schedule-run.log 2>&1

Create the access user (User registration is only available from the terminal).


  php artisan user:create --email=user@domain.com --name=Admin --password=StrongPassword2

Configure the server for web access with DOCUMENT_ROOT in public.

As design pattern we are using a custom domains pattern with factories instead dependency injection: https://github.com/nitsnets/Domains-Panel/tree/master/app/Domains

Feedback is welcome :)

PHP Changes Cheatsheet

Lito — Wed, 30 Dec 2020 14:19:14 +0000

I have created this small project to allow to see all versions changes together and avoid to search into multiple doc pages.

https://eusonlito.github.io/php-changes-cheatsheet/

You can collaborate on design or functionality working on this issues: https://github.com/eusonlito/php-changes-cheatsheet/issues

Regards!

Como guardar una copia de cada email que se envía desde Laravel

Lito — Sat, 17 Oct 2020 15:23:18 +0000

Con este post crearemos un fichero con cada correo enviado por nuestro sistema para poder analizar el contenido de los mismos.

El post anterior sobre debug en Laravel es https://dev.to/lito/como-generar-logs-que-registren-las-consultas-a-base-de-datos-en-laravel-5edl

1. Creamos el Logger de Mail

Lo podemos dar de alta por ejemplo en app/Services/Mail/Logger.php:

<?php declare(strict_types=1);

namespace App\Services\Mail;

use Illuminate\Mail\Events\MessageSending;
use Illuminate\Support\Facades\Event;

class Logger
{
    /**
     * @return void
     */
    public static function listen(): void
    {
        Event::listen(MessageSending::class, static fn ($event) => static::store($event));
    }

    /**
     * @param \Illuminate\Mail\Events\MessageSending $event
     *
     * @return void
     */
    protected static function store(MessageSending $event): void
    {
        $file = storage_path('logs/mails/'.date('Y-m-d/H-i-s').'-'.uniqid().'.log');
        $dir = dirname($file);

        if (is_dir($dir) === false) {
            mkdir($dir, 0755, true);
        }

        file_put_contents($file, (string)$event->message);
    }
}

Ahora podemos crear un ServiceProvider que gestione el debug. Lo haremos en app/Providers/Debug.php:

<?php declare(strict_types=1);

namespace App\Providers;

use Illuminate\Support\ServiceProvider;
use App\Services\Mail\Logger as LoggerMail;

class Debug extends ServiceProvider
{
    /**
     * @return void
     */
    public function boot()
    {
        $this->logging();
    }

    /**
     * @return void
     */
    protected function logging(): void
    {
        $this->loggingMail();
    }

    /**
     * @return void
     */
    protected function loggingMail(): void
    {
        if (config('logging.channels.mail.enabled')) {
            LoggerMail::listen();
        }
    }
}

Una vez tengamos el servicio, lo añadimos en config/app.php en el array de providers:

    ...

    'providers' => [
        ...

        /*
         * Application Service Providers...
         */
        App\Providers\Debug::class,
    ],
];

También añadimos su opción de configuración en config/logging.php:

    ...

    'channels' => [
        ...

        'mail' => [
            'enabled' => env('LOG_MAIL', false),
        ],
    ],

Y lo completamos con el valor en .env:

LOG_MAIL=true

De este modo nos creará una carpeta en storage/logs/mails/ con cada día y dentro un fichero cada correo ordenados por hora.

El código completo lo podeis encontrar aquí https://gist.github.com/eusonlito/773bd0ef3de74ba998e0fb6f8cc42d9a

Y ya sabes, si te ha parecido interesante, comparte!

Como generar logs que registren las consultas a base de datos en Laravel

Lito — Thu, 15 Oct 2020 10:18:37 +0000

Con este post crearemos un fichero de log por cada día y URL que nos permitirá descubrir problemas como consultas N+1 y analizar si estamos ejecutando una carga excesiva a la base de datos.

1. Creamos el Logger propio de Base de Datos

Lo podemos dar de alta por ejemplo en app/Services/Database/Logger.php:

<?php declare(strict_types=1);

namespace App\Services\Database;

use DateTime;
use Illuminate\Support\Facades\DB;
use Illuminate\Support\Facades\Request;

class Logger
{
    /**
     * @var string
     */
    protected static string $file = '';

    /**
     * @return void
     */
    public static function listen(): void
    {
        if (static::$file) {
            return;
        }

        static::load();
        static::write('['.date('Y-m-d H:i:s').'] ['.Request::method().'] '.Request::fullUrl());

        DB::listen(static function ($sql) {
            foreach ($sql->bindings as $i => $binding) {
                if ($binding instanceof DateTime) {
                    $sql->bindings[$i] = $binding->format('Y-m-d H:i:s');
                } elseif (is_string($binding)) {
                    $sql->bindings[$i] = "'${binding}'";
                } elseif (is_bool($binding)) {
                    $sql->bindings[$i] = $binding ? 'true' : 'false';
                }
            }

            static::write(vsprintf(str_replace(['%', '?'], ['%%', '%s'], $sql->sql), $sql->bindings));
        });
    }

    /**
     * @return void
     */
    protected static function load(): void
    {
        static::file();

        if (is_dir($dir = dirname(static::$file)) === false) {
            mkdir($dir, 0755, true);
        }
    }

    /**
     * @return void
     */
    protected static function file(): void
    {
        $file = array_filter(explode('-', preg_replace('/[^a-z0-9]+/i', '-', Request::path())));
        $file = implode('-', array_map(static fn ($value) => substr($value, 0, 20), $file)) ?: '-';

        static::$file = storage_path('logs/query/'.date('Y-m-d').'/'.substr($file, 0, 150).'.log');
    }

    /**
     * @param string $message
     *
     * @return void
     */
    protected static function write(string $message): void
    {
        file_put_contents(static::$file, "\n\n".$message, FILE_APPEND | LOCK_EX);
    }
}

Ahora podemos crear un ServiceProvider que gestione el debug. Lo haremos en app/Providers/Debug.php:

<?php declare(strict_types=1);

namespace App\Providers;

use Illuminate\Support\ServiceProvider;
use App\Services\Database\Logger as LoggerDatabase;

class Debug extends ServiceProvider
{
    /**
     * @return void
     */
    public function boot()
    {
        $this->logging();
    }

    /**
     * @return void
     */
    protected function logging(): void
    {
        $this->loggingDatabase();
    }

    /**
     * @return void
     */
    protected function loggingDatabase(): void
    {
        if (config('logging.channels.database.enabled')) {
            LoggerDatabase::listen();
        }
    }
}

En este mismo ServiceProvider podríamos, por ejemplo, añadir también un log que registre los envíos de correos (esto irá en un nuevo post).

Una vez tengamos el servicio, lo añadimos en config/app.php en el array de providers:

    ...

    'providers' => [
        ...

        /*
         * Application Service Providers...
         */
        App\Providers\Debug::class,
    ],
];

También añadimos su opción de configuración en config/logging.php:

    ...

    'channels' => [
        ...

        'database' => [
            'enabled' => env('LOG_DATABASE', false),
        ],
    ],

Y lo completamos con el valor en .env:

LOG_DATABASE=true

De este modo nos creará una carpeta en storage/logs/query/ con cada día y dentro un fichero con el slug del path de cada petición.

El código completo lo podeis encontrar aquí https://gist.github.com/eusonlito/c0a87467b55165a9585a640f1ba4083e

Y ya sabes, si te ha parecido interesante, comparte!

Utilizando tus propios helpers en Laravel (o cualquier proyecto PHP)

Lito — Tue, 29 Sep 2020 18:22:37 +0000

En Laravel, al igual que en cualquier proyecto PHP, puedes incluir tus propios helpers o funciones globales para facilitar ciertas tareas comunes y que se usan en diferentes partes.

Este artículo mostrará dos formas de hacerlo, y después cada uno ya decide según sus preferencias.

La parte común

Comenzamos indicando a composer que usaremos un fichero con una serie de funciones globales que debe cargar en el autoload junto con el resto de definiciones.

En este caso mi fichero es app/Services/Helper/functions.php:

"autoload": {
    "classmap": [
        "database/migrations"
    ],
    "psr-4": {
        "App\\": "app/"
    },
    "files": [
        "app/Services/Helper/functions.php"
    ]
}

A partir de este momento lo que incluya este fichero ya estará disponible en toda la aplicación.

La forma tradicional

Básicamente la forma tradicional significa colocar tus funciones directamente, como por ejemplo:

<?php declare(strict_types=1);

if (function_exists('ids') === false) {
    /**
     * @param array $ids
     *
     * @return array
     */
    function ids(array $ids): array
    {
        return array_values(array_filter(array_map('intval', $ids)));
    }
}

if (function_exists('uniqidReal') === false) {
    /**
     * @param int $length
     * @param bool $safe = false
     *
     * @return string
     */
    function uniqidReal(int $length, bool $safe = false): string
    {
        if ($safe) {
            $string = '23456789bcdfghjkmnpqrstwxyzBCDFGHJKMNPQRSTWXYZ';
        } else {
            $string = '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ';
        }

        return substr(str_shuffle(str_repeat($string, rand((int)($length / 2), $length))), 0, $length);
    }
}

if (function_exists('dateLocal') === false) {
    /**
     * @param string $date
     * @param string $format = 'Y-m-d'
     *
     * @return string
     */
    function dateLocal(string $date, string $format = 'd/m/Y'): string
    {
        return date($format, strtotime($date));
    }
}

if (function_exists('arrayMapRecursive') === false) {
    /**
     * @param array $array
     * @param callable $callback
     *
     * @return array
     */
    function arrayMapRecursive(array $array, callable $callback): array
    {
        return array_map($func = static function ($value) use ($callback, &$func) {
            return is_array($value) ? array_map($func, $value) : $callback($value);
        }, $array);
    }
}

Ahora ya podrás utilizar estas funciones de en cualquier parte de la aplicación como si fuera una función nativa de PHP más.

La forma encapsulada o libre de conflictos

La alternativa a la forma tradicional es mediante una función única que nos sirva el acceso al resto de helpers.

Esto nos permitirá crear todos los métodos que necesitemos sin temer por conflictos con otros métodos nativos de PHP y también con otros métodos globales que puedan definir el resto de paquetes de nuestro proyecto.

Para hacer esto crearemos el fichero de app/Services/Helper/functions.php con una única función:

<?php declare(strict_types=1);

/**
 * @return \App\Services\Helper\Helper
 */
function helper(): App\Services\Helper\Helper
{
    static $helper;

    return $helper ??= new App\Services\Helper\Helper();
}

y a partir de aquí crearemos los métodos que necesitemos dentro de la clase App\Services\Helper\Helper:

<?php declare(strict_types=1);

namespace App\Services\Helper;

class Helper
{
    /**
     * @param array $ids
     *
     * @return array
     */
    public function ids(array $ids): array
    {
        return array_values(array_filter(array_map('intval', $ids)));
    }

    /**
     * @param int $length
     * @param bool $safe = false
     *
     * @return string
     */
    public function uniqidReal(int $length, bool $safe = false): string
    {
        if ($safe) {
            $string = '23456789bcdfghjkmnpqrstwxyzBCDFGHJKMNPQRSTWXYZ';
        } else {
            $string = '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ';
        }

        return substr(str_shuffle(str_repeat($string, rand((int)($length / 2), $length))), 0, $length);
    }

    /**
     * @param string $date
     * @param string $format = 'Y-m-d'
     *
     * @return string
     */
    public function dateLocal(string $date, string $format = 'd/m/Y'): string
    {
        return date($format, strtotime($date));
    }

    /**
     * @param array $array
     * @param callable $callback
     *
     * @return array
     */
    public function arrayMapRecursive(array $array, callable $callback): array
    {
        return array_map($func = static function ($value) use ($callback, &$func) {
            return is_array($value) ? array_map($func, $value) : $callback($value);
        }, $array);
    }
}

De este modo para llamar a cualquier método del helper haremos por ejemplo: helper()->uniqidReal(6) o podemos renombrar a la función global helper como h para acortar las llamadas h()->uniqidReal(6).

Yo personalmente prefiero la segunda opción, pero eso ya es cosa de cada uno :)

Si te ha parecido interesante, compárteme!

Optimizando los Modelos de Laravel

Lito — Mon, 31 Aug 2020 22:25:41 +0000

Laravel es un framework de PHP muy pesado a nivel computacional. Está pensado para falicitar la vida al desarrollador, lo cual se agradece mucho, pero de ningún modo está pensado para ser ni rápido ni óptimo en el consumo de procesador o memoria, y los modelos son un claro reflejo de esto.

Es por esto que los modelos es de lo que primero se prescinde cuando en un proyecto se presenta una alta carga de peticiones por segundo o bien una importante carga de datos en memoria para ciertos procesos.

En este artículo vamos a presentar ciertos cambios que aliviarán de manera notable el consumo de procesador y memoria en tu código.

Iterar sobre elementos usando `cursor`

Cuando realizas una selección de registros de base de datos, todos los registros se cargan directamente en memoria al mismo tiempo dentro de una colección de modelos. Cuando trabajas con miles de registros esto puede ser demoledor para el tiempos de ejecución del proceso.

Para evitar eso puedes iterar por cada uno de los registros mediante el método cursor, el cual te permitirá mantener sólo en memoria un registro en cada iteración.

foreach (UserModel::withRelations()->cursor() as $user) {
    actionWithEveryUser($user);
}

Desactivar los attributos mágicos

Eloquent aplica demasiada magia en los modelos, y una de esas son los Mutators:

class User extends Model
{
    /**
     * @return string
     */
    public function getFullNameAttribute(): string
    {
        return $this->first_name.' '.$this->last_name;
    }

    /**
     * @param string $value
     *
     * @return void
     */
    public function setFirstNameAttribute(string $value): void
    {
        $this->attributes['first_name'] = strtolower($value);
    }
}

Esto implica que cada acceso al atributo $user->full_name suponga un montón de operaciones (a parte de lo confuso de acceder a propiedades que realmente no existen en el modelo de datos).

Con lo cual vamos a desactivar los métodos que utiliza Eloquent para la comprobación de estos métodos mágicos.

Para eso lo ideal es siempre disponer de un ModelAbstract propio al que extiendan todos los demás modelos:

<?php declare(strict_types=1);

namespace App\Models;

use Illuminate\Database\Eloquent\Model;

abstract class ModelAbstract extends Model
{
}

Sobre este modelo podemos aplicar un trait que desactive el acceso a los mutators.

<?php declare(strict_types=1);

namespace App\Models\Traits;

trait MutatorDisabled
{
    /**
     * @param string $key
     *
     * @return bool
     */
    public function hasGetMutator($key)
    {
        return false;
    }

    /**
     * @param string $key
     *
     * @return bool
     */
    public function hasSetMutator($key)
    {
        return false;
    }
}

y este trait se lo aplicamos al modelo base:

<?php declare(strict_types=1);

namespace App\Models;

use Illuminate\Database\Eloquent\Model;

abstract class ModelAbstract extends Model
{
    use Traits\MutatorDisabled;
}

Una vez desactivados los mutators, utilizamos métodos tradicionales para el acceso a estos valores:

<?php declare(strict_types=1);

namespace App\Models;

class User extends ModelAbstract
{
    /**
     * @return string
     */
    public function getFullName(): string
    {
        return $this->first_name.' '.$this->last_name;
    }

    /**
     * @param string $value
     *
     * @return void
     */
    public function setFirstName(string $value): void
    {
        $this->attributes['first_name'] = strtolower($value);
    }
}

<h1>{{ $user->getFullName() }}</h1>

Desactivar la gestión de fechas

Por defecto Eloquent inicializa como objetos Carbon todas las fechas que están definidas en nuestros modelos (que por defecto son created_at y updated_at).

Carbon es una librería muy potente pero también bastante lenta, y esta inicialización supone una carga muy alta cuando se trabaja con cantidad de registros importante.

La idea sería desactivar las funcionalidad de cast de fechas desde el modelo, y realizarla según se necesite mediante un helper, y a poder ser, usando directamente DateTime, ya que la diferencia de rendimiento es notable.

Para eso creamos un trait que después añadimos al ModelAbstract:

<?php declare(strict_types=1);

namespace App\Models\Traits;

trait DateDisabled
{
    /**
     * @return array
     */
    public function getDates(): array
    {
        return [];
    }

    /**
     * @param string $key
     *
     * @return bool
     */
    public function isDateCastable($key)
    {
        return false;
    }
}

Esto anulará el cast de todas las fechas, incluidas las definidas en $casts.

<?php declare(strict_types=1);

namespace App\Models;

use Illuminate\Database\Eloquent\Model;

abstract class ModelAbstract extends Model
{
    use Traits\MutatorDisabled;
    use Traits\DateDisabled;
}

Evitar la transformación de claves de atributos en la exportación a `JSON`

En la conversión de valores de un modelo a JSON, Laravel realiza un cambio a snake_case, esto supone, a demás de un problema de rendimiento, un problema en la referencia claves de datos en su exportación.

Para evitar esto y que mantenga la definición propia del modelo debemos añadir un parámetro en el ModelAbstract:

<?php declare(strict_types=1);

namespace App\Models;

use Illuminate\Database\Eloquent\Model;

abstract class ModelAbstract extends Model
{
    use Traits\MutatorDisabled;
    use Traits\DateDisabled;

    /**
     * @var bool
     */
    public static $snakeAttributes = false;
}

Si deseas aplicar cierta conversión del modelo en la salida JSON (lo cual es SIEMPRE lo recomendable), puedes usar Presenters, Transformers o Fractals (aquí cada cual le pone un nombre diferente a la misma cosa).

Mover los `scopes` hacia Query Builders

Eloquent mezcla en los modelos la gestión de datos con la selección de los mismos, lo cual es un claro antipatrón en la S de SOLID (Single Responsibility Principle).

La idea es sacar todo lo que tiene que ver con selección de datos en la base de datos (excepto relaciones) a clases auxiliares para la separación de conceptos.

También nos ayudará a evitar métodos mágicos que se llaman de una manera pero se referencian de otra, evitando el uso de scope y dándole un respiro a nuestro IDE.

Necesitaremos dar de alta un Builder por cada modelo, con lo cual vamos a crear un BuilderAbstract que nos permitirá añadir algunas acciones genéricas:

<?php declare(strict_types=1);

namespace App\Models\Builder;

use Illuminate\Database\Eloquent\Builder;
use App\Models\User as UserModel;

abstract class BuilderAbstract extends Builder
{
    /**
     * @param int $id
     *
     * @return self
     */
    public function byId(int $id): self
    {
        $this->where('id', $id);

        return $this;
    }

    /**
     * @param \App\Models\User $user
     *
     * @return self
     */
    public function byUser(UserModel $user): self
    {
        $this->where('user_id', $user->id);

        return $this;
    }

    /**
     * @return self
     */
    public function enabled(): self
    {
        $this->where('enabled', 1);

        return $this;
    }
}

Una vez definido nuestro BuilderAbstract, generamos uno por cada modelo:

<?php declare(strict_types=1);

namespace App\Models\Builder;

class User extends BuilderAbstract
{
    /**
     * @param string $email
     *
     * @return self
     */
    public function byEmail(string $email): self
    {
        $this->where('email', $email);

        return $this;
    }

    /**
     * @return self
     */
    public function withRelations(): self
    {
        $this->with(['posts', 'comments']);

        return $this;
    }
}

y con esto ya podemos indicar a nuestro modelo que debe usar un Builder de Eloquent personalizado:

<?php declare(strict_types=1);

namespace App\Models;

use Illuminate\Auth\Authenticatable as AuthenticatableTrait;
use Illuminate\Contracts\Auth\Authenticatable;
use Illuminate\Database\Eloquent\Relations;
use Illuminate\Database\Eloquent\SoftDeletes;

class User extends ModelAbstract implements Authenticatable
{
    use AuthenticatableTrait, SoftDeletes;

    /**
     * @var string
     */
    protected $table = 'user';

    /**
     * @var string
     */
    public static string $foreign = 'user_id';

    /**
     * @var array
     */
    protected $casts = [
        'enabled' => 'boolean',
    ];

    /**
     * @var array
     */
    protected $hidden = ['password'];

    /**
     * @param \Illuminate\Database\Query\Builder $builder
     *
     * @return \Illuminate\Database\Eloquent\Builder|static
     */
    public function newEloquentBuilder($builder)
    {
        return new Builder\User($builder);
    }

    /**
     * @return \Illuminate\Database\Eloquent\Relations\HasMany
     */
    public function comments(): Relations\HasMany
    {
        return $this->hasMany(Comment::class, static::$foreign);
    }

    /**
     * @return \Illuminate\Database\Eloquent\Relations\HasMany
     */
    public function posts(): Relations\HasMany
    {
        return $this->hasMany(Post::class, static::$foreign);
    }
}

Con esto conseguiremos unos modelos mucho más limpios, de rendimiento más óptimo y más cerca de SOLID.

Si te ha parecido interesante, compárteme!

Pruebas de Rendimiento en Laravel 5.6 5.7 5.8 6.0 vs PHP 7.1 7.2 7.3 7.4

Lito — Fri, 20 Sep 2019 22:19:35 +0000

Aprovechando el lanzamiento de Laravel 6.0 he realizado unos tests para analizar los tiempos y capacidad de respuesta de diferentes versiones de Laravel sobre diferentes versiones de PHP.

Como proyecto base he utilizado un proyecto personal llamado BeMyCrown que es compatible con todas las versiones de Laravel y PHP seleccionadas.

No ha sido posible incluir Laravel 5.4 debido a que el código del framework no es del todo compatible con las siguientes versiones.

La idea es analizar si las mejoras aplicadas en las diferentes versiones de Laravel y PHP se notan realmente en el rendimiento de la aplicación.

El servidor de pruebas dispone de una CPU un Intel Core i5–8600K @ 3.60GHz con 16 GB de RAM y discos NVME.

La configuración de dependencias Composer es la siguiente:

"require": {
 "php": ">=7.1.3",
 "laravel/framework": "X.X.*",
 "predis/predis": "^1.1",
 "eusonlito/disposable-email-validator": "^0.1",
 "eusonlito/laravel-packer": "^2.1",
 "eusonlito/laravel-meta": "^3.1",
 "eusonlito/laravel-gettext": "^2.0",
 "eusonlito/laravel-form-manager": "^1.0",
 "eusonlito/amazon-mws": "dev-master",
 "h4cc/wkhtmltopdf-amd64": "0.12.3",
 "mikehaertl/phpwkhtmltopdf": "^2.3",
 "sentry/sentry-laravel": "^1.0",
 "braintree/braintree_php": "^3.39"
}

Y para el testing he creado el siguiente script https://gist.github.com/eusonlito/b8ca1e80220f3791b3ae8bfa1d3c8d76

La ejecución genera una serie de logs de la herramienta ab y crea además los CSV que me permitirán generar las gráficas de comparación.

Como servidor uso una serie de virtualhosts de apache como proxy con las diferentes versiones de PHP-FPM, todas configuradas de la misma manera.

Aquí están los resultados al completo https://docs.google.com/spreadsheets/d/e/2PACX-1vRt4dYPz0YPg4FjKjYOCtk71n91IstKIIneFxM8aEJJEviXqFkV5SKXXkOpZv9x5htR4DuzJvigsptg/pubhtml

500 peticiones - 50 concurrentes

500 peticiones - 100 concurrentes

1000 peticiones - 50 concurrentes

1000 peticiones - 100 concurrentes

Como se puede ver, la llegada de Laravel 6.0 no ha aportado nada en cuanto a mejoras de rendimiento, incluso se situa muy por detrás de la 5.6 o 5.7, y tal y como se puede apreciar, con cada nueva versión el rendimiento desciende de manera notable.

Como conclusión, creo que Laravel debería ponerse las pilas de manera seria con el rendimiento global del framework, quizá quitando algo de magia en Eloquent, minimizando el uso de Facades, optimizando el Service Container o un poco de todo.

Aunque su rendimiento está por encima de otros frameworks de PHP, siendo un proyecto ya maduro debería enfocar su desarrollo en acercarse lo máximo posible a Symfony, el cual aún está muy muy por encima y ya no digamos pensar en ser la competencia de Express (NodeJS).

Por ahora, lo que lo salva es la sencillez y facilidades que ofrece al desarrollador, pero esto podría ofrecerlo en un futuro no muy lejano cualquier otro, y ya sólo nos quedaría considerar uno u otro según su rendimiento.

Eso es todo amigos!

PHP + nginx + caché + tmpfs, una combinación ganadora

Lito — Mon, 24 Jun 2019 10:36:29 +0000

Supongamos que tenemos un proyecto sencillo sin sistema de usuarios y queremos que suponga una carga muy muy baja para el servidor así como conseguir unos tiempos de respuesta super rápidos.

Una solución podría ser delegar la caché en el backend de PHP a través de código propio o alguna librería externa.

Otra solución más óptima es bajar un nivel y dejar que nginx se encarge de generar las cachés.

Esta opción tiene sus ventajas, ya que es mucho más rápida (no hay petición a backend, es una capa menos) y sus inconvenientes (no es posible gestionar esta caché desde PHP).

Si optamos por esta segunda, la configuración es bastante sencilla.

Lo primero es crear un punto de montaje basado en tmpfs que nos permitirá reducir las peticiones a disco y optimizar su lectura.

$> mkdir /var/cache/nginx
$> chown www-data:www-data /var/cache/nginx
$> echo 'tmpfs /var/cache/nginx tmpfs defaults,size=256M 0 0' >> /etc/fstab
$> mount /var/cache/nginx

Ahora, configuramos nginx:

/etc/nginx/sites-enabled/example.com

# Creamos una zona de caché con un límite de de 256 megas apuntando al directorio tmpfs
# Todo fichero con más de 60 minutos desde el último acceso será descartado
fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=EXAMPLE:256m inactive=60m;
# Indicamos con qué parametros se deben generar las cachés
fastcgi_cache_key "$scheme$request_method$host$request_uri";

server {
    listen 443 ssl http2;

    server_name example.com www.example.com;

    root /var/www/example.com/httpdocs/public;
    index index.php;

    include sites/example.com/base.conf;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_trusted_certificate /etc/letsencrypt/live/example.com/fullchain.pem;

    access_log /var/log/nginx/example.com_access.log combined buffer=32k flush=60;
    error_log  /var/log/nginx/example.com_error.log;
}

/etc/nginx/sites/example.com/base.conf

rewrite ^/(.*)/$ /$1 permanent;

location / {
    try_files $uri $uri/ /index.php?$query_string;
}

location ~ \.php$ {
    fastcgi_split_path_info ^(.+\.php)(/.+)$;
    fastcgi_pass unix:/var/run/php/php7.3-fpm.sock;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

    include fastcgi_params;

    include sites/example.com/cache.conf;
}

/etc/nginx/sites/example.com/cache.conf

# Añadimos una cabecera con el status de cada petición
add_header X-Cache $upstream_cache_status;

# Configuramos la zona de caché a usar
fastcgi_cache EXAMPLE;
# Configuramos que tipo de respuesta es válida para ser cacheada y los tiempos en caché
fastcgi_cache_valid 200 301 302 60m;
# Configuramos con que tipo de errores podemos mostrar una caché obsoleta
fastcgi_cache_use_stale error timeout updating invalid_header http_500 http_503;
# Configuramos los usos mínimos por caché
fastcgi_cache_min_uses 1;
# Si entran varias peticiones simultáneas a una ruta sin caché, esperar
# a que la primera de ellas genere la caché y el resto responda lo mismo
fastcgi_cache_lock on;
# Evitamos las cabeceras de Cache-Control
fastcgi_ignore_headers Cache-Control;

set $no_cache 0;

# Aquí puedes añadir todas tus condiciones para evitar la caché

# No se cachea ninguna petición POST
if ($request_method = POST) {
    set $no_cache 1;
}

fastcgi_cache_bypass $no_cache;
fastcgi_no_cache $no_cache;

Si quieres profundizar en este tema, tienes muchos posts interesantes, como por ejemplo Make your PHP site fly. Even on small VM instance.

Y con esto y un bizcocho tienes un sistema de caché sencillo y muy eficiente para tus sitios semi-estáticos.

MySQL 8 en Docker de manera fácil y para toda la familia

Lito — Mon, 06 May 2019 10:34:35 +0000

Estaba yo por aquí con mi feliz vida de programador y usuario Linux (GNU/Linux para los puristas) cuando de repente se muestra ante mí una situación que no sucede de manera habitual (dentro de mi bonito mundo): Necesitar dos versiones diferentes de un mismo servicio corriendo al mismo tiempo y sin entrar en conflicto.

Como usuario Linux siempre he tenido opciones sencillas para disponer de versiones de cierto software según necesidades, o bien no depender de versiones.

Servicios como Apache, nginx o Redis, con tener siempre la última ya vas servido. Otros como PHP o PostgreSQL puedes instalar todas las versiones que quieras sin que entren en conflicto entre sí, pero con MySQL no hay esa posibilidad "sencilla".

Para un nuevo proyecto necesitaba MySQL 8 ya que dispone de muchas mejoras en funcionalidades de geoposicionamiento, a parte de un mejor rendimiento en general cuando se trabaja con gran cantidad de datos, así que finalmente opté por la vía Docker.

Si no te metes en fregaos, es bastante más sencillo de lo que parece :)

Estos son los pasos a seguir:

# Instalamos los paquetes necesarios desde los repositorios oficiales de Ubuntu
$> sudo apt install docker.io

# Iniciamos el servicio
$> sudo systemctl start docker

# Activamos Docker al inicio del sistema
$> sudo systemctl enable docker

# Descargamos la imagen de MySQL
$> sudo docker pull mysql/mysql-server

# Creamos un volumen para almacenar los datos de manera persistente
# La localización será /var/lib/docker/volumes/mysql-8-data
$> sudo docker volume create mysql-8-data

# Iniciamos la instancia con la última versión de MySQL 8
# Mapeamos el puerto 3307 de nuestra máquina para 3306 de Docker
# Asignamos el volumen anterior para que las bases de datos sean persistentes
$> sudo docker run \
    -p 3307:3306 \
    -v mysql-8-data:/var/lib/mysql \
    --name mysql-8 \
    --restart always \
    -d mysql/mysql-server:latest

# Esperamos unos segundos y veremos la contraseña que se genera durante la instalación
$> sudo docker logs mysql-8 2>&1 | grep GENERATED
[Entrypoint] GENERATED ROOT PASSWORD: exTeNg0L9uMuquwWyP4DaebPAdr

# Accedemos por bash de Docker a la instalación
$> sudo docker exec -it mysql-8 bash

# Nos autenticamos en MySQL usando las credenciales de los logs (exTeNg0L9uMuquwWyP4DaebPAdr)
bash-4.2# mysql -uroot -p

# Creamos un usuario root para conexión externa a Docker con contraseña diferente
mysql> CREATE USER 'root'@'%' IDENTIFIED BY '!dC^:kI4*wT:|UE';
ERROR 1820 (HY000): You must reset your password using ALTER USER statement before executing this statement.

# Ups! no podemos, debemos actualizar primero nuestro usuario y mantenemos la contraseña
mysql> ALTER USER USER() IDENTIFIED BY 'exTeNg0L9uMuquwWyP4DaebPAdr';
Query OK, 0 rows affected (0.03 sec)

# Ahora sí, creamos un usuario root para conexión externa a Docker con contraseña diferente
mysql> CREATE USER 'root'@'%' IDENTIFIED BY '!dC^:kI4*wT:|UE';
Query OK, 0 rows affected (0.04 sec)

# Le asignamos los privilegios de puto amo
mysql> GRANT ALL PRIVILEGES ON *.* TO 'root'@'%';
Query OK, 0 rows affected (0.03 sec)

# Creamos la base de datos de nuestro proyecto
mysql> CREATE DATABASE `project` CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
Query OK, 1 row affected (0.06 sec)

# Creamos el usuario con el que nos autenticaremos en ella desde nuestra aplicación
mysql> CREATE USER 'project'@'%' IDENTIFIED WITH mysql_native_password BY '*43i0;l+6=7:*lA';
Query OK, 0 rows affected (0.04 sec)

# Le asignamos los permisos
mysql> GRANT ALL PRIVILEGES ON `project`.* TO 'project'@'%';
Query OK, 0 rows affected (0.02 sec)

mysql> exit

bash-4.2# exit

# Probamos la conexión desde fuera de Docker con la contraseña de usuario (*43i0;l+6=7:*lA)
# Recuerda indicar el puerto de esta instalación con -P3307
$> mysql --protocol=tcp -P3307 -uproject -p project

Tal y como indica @frandieguez, podemos pasarle directamente los parámetros a MySQL para comenzar con unos ya preestablecidos por nosotros, simplemente hay que lanzar docker run de la siguiente manera:

$> sudo docker run \
    -p 3307:3306 \
    -v mysql-8-data:/var/lib/mysql \
    -e MYSQL_ROOT_PASSWORD=XXXX -e MYSQL_USER=XXXX -e MYSQL_DATABASE=XXXX \
    --name mysql-8 \
    --restart always \
    -d mysql/mysql-server:latest \

Si todo ha ido bien (que debería) pues ya tenemos una instancia Docker en nuestro equipo/servidor que nos provee de MySQL 8.

Si necesitas toquetear la configuración de MySQL no podrás hacerlo directamente desde docker shell ya que no dispone de editor.

La solución más sencilla (para mí) es la siguiente:

# Copiamos el fichero de configuración desde el contenedor a nuestro equipo
$> sudo docker cp mysql-8:/etc/my.cnf my.cnf

# Editamos la configuración a nuestro gusto
$> sudo vi my.cnf

# Pasamos de nuevo el fichero al contenedor
$> sudo docker cp my.cnf mysql-8:/etc/my.cnf

# Reiniciamos el contenedor
$> sudo docker restart mysql-8

Así ya tendremos nuestro MySQL totalmente customizado.

Enjoy!

Redimensionado de imágenes según la resolución del cliente

Lito — Wed, 27 Mar 2019 19:20:19 +0000

Una vez tenemos claro como utilizar una herramienta como Packer para el redimensionado de imágenes en tiempo de ejecución:

Article No Longer Available

Vamos a dar un paso más aplicando la redimensión según la resolución del dispositivo del cliente.

Esta mejora permitirá enviar fotos posiblemente mucho más reducidas en tamaño para optimizar sobre todo la navegación móvil en, como mínimo, cuatro puntos:

el cliente usa menos ancho de banda con lo cual la descarga será más rápida y la web se visualizará antes
el uso de CPU del dispositivo será menor al tener que renderizar imágenes más ligeras
evitamos guardar en la caché de disco del cliente imágenes a alta resolución
el feeling en el scroll mejorará cuanto más reducidas sean las imágenes

Lo primero es añadir un trozo de código javascript en el HTML:

(function() {
    function setCookie(value) {
        document.cookie = value
            + '; path=/'
            + '; max-age=' + (3600 * 24 * 30 * 12)
            + '; SameSite=Strict'
            + '; secure';
    }

    function setResolution() {
        var width = document.documentElement.clientWidth || window.innerWidth,
            height = document.documentElement.clientHeight || window.innerHeight,
            dpr = window.devicePixelRatio || 1;

        setCookie('resolution=' + width + ',' + height + ',' + dpr);
    }

    setResolution();

    window.addEventListener('resize', function() {
        setResolution();
    });
})();

Con esto ya tenemos una cookie que registra la resolución del dispositivo conectado.

Ahora vamos por la parte de backend.

Primero creamos un servicio que nos permita realizar las transformaciones desde las plantillas de manera sencilla:

<?php declare(strict_types=1);

namespace App\Services\Html;

class Html
{
    /**
     * @param string $image
     * @param string $options = ''
     *
     * @return string
     */
    public static function img(string $image, string $options = ''): string
    {
        return Image::transform($image, $options);
    }
}

Y lo añadimos como alias en app/config.php:

    'aliases' => [
        ...,
        'Html' => App\Services\Html\Html::class,
    ],

Ahora preparamos el servicio de procesado de imágenes:

<?php declare(strict_types=1);

namespace App\Services\Html;

use Packer;

class Image
{
    /**
     * @param string $image
     * @param string $options
     *
     * @return string
     */
    public static function transform(string $image, string $options): string
    {
        if ($options = static::options($options)) {
            return (string)Packer::img($image, $options);
        }

        return $image;
    }

    /**
     * @param string $options
     *
     * @return string
     */
    protected static function options(string $options): string
    {
        if (empty($resolution = $_COOKIE['resolution'])) {
            return $options;
        }

        list($widthMax, $heightMax, $dpr) = array_pad(array_map('intval', explode(',', $resolution, 3)), 3, 1);

        if (empty($widthMax) || empty($heightMax)) {
            return $options;
        }

        $options = $options ?: 'resize,0,0,center,middle';

        $widthMax *= ($dpr ?: 1);
        $heightMax *= ($dpr ?: 1);

        list($action, $width, $height, $horizontal, $vertical) = array_pad(explode(',', $options, 5), 5, null);

        if ($width > $widthMax) {
            $height = intval(($widthMax * $height) / $width);
            $width = $widthMax;
        } elseif ($height > $heightMax) {
            $width = intval(($heightMax * $width) / $height);
            $height = $heightMax;
        }

        return $action.','.$width
            .($height ? (','.$height) : '')
            .($horizontal ? (','.$horizontal) : '')
            .($vertical ? (','.$vertical) : '');
    }
}

Ahora sólo queda usarlo en las plantillas y comparar las imágenes generadas según el dispositivo con el que nos conectemos:

<img src="{{ Html::img('/storage/images/background.jpg') }}" />
<img src="{{ Html::img('/storage/images/slider.jpg', 'resize,1920') }}" />