Sin embargo, HTML ha continuado su evolución y pues en este post quiero mostrarte una lista de sus atributos que probablemente no conoces, pero que pueden ser super útiles.

Si consideras que me he olvidado de algún otro atributo o característica importante, déjame saber en los comentarios y lo incluiré en el post. 😉

1.- Atributo: multiple

El atributo "multiple" nos permite indicarle a un campo input que puede aceptar múltiples valores por lo que el usuario podrá ingresar múltiples valores por ejemplo en un .

Es un atributo "boolean" válido para tipos de entrada de correo electrónico (email) o archivo (file) y el elemento .

Para el caso de un input de tipo "email", si y solo si, se especifica el atributo "multiple", el valor puede ser una lista de direcciones de correo electrónico separadas por comas. Cualquier espacio en blanco será removido de cada email en la lista.

Para la entrada de un archivo, el usuario puede seleccionar varios archivos en la forma habitual (manteniendo presionada la tecla Mayús o Crtl).

<input type="file" multiple>

2.- Atributo: accept

El elemento tiene el atributo "accept" el cual te permite indicarle al usuario los tipos de archivos permitidos que se pueden cargar.

Solo debemos pasarle una cadena de texto que contenga la lista separada por comas, los formatos de archivos permitidos.

También puede usarlo para especificar solo formato de audio, imagen o video.

<input type = "file" accept = ". png, .jpg">

3.- Atributo: contenteditable

"contenteditable" es un atributo global (aplicable a todos los elementos HTML) que hace que el contenido HTML sea o no, editable por el usuario. Sin embargo, hay que tener extremo cuidad con los cambios aplicados solo en el contenido visible frente al contenido del DOM.

<div contenteditable = "true"> Soy un div editable, 😉 </div>
div editable

4.- Atributo: spellcheck

"spellcheck" es otro atributo global que puede utilizar para revisar la ortografía y la gramática en elementos HTML tales como inputs y otros elementos editables.

Nota: Por lo general, los elementos que no son editables, no se comprueban en busqueda de errores ortográficos, aún cuando el atributo "spellcheck" esté establecido a "true" y el navegador del usuario soporta la verificación de ortografía.

<p contenteditable = "true" spellcheck = "true">
Gracias por comprobar mi ortografía :)
</p>

5.- Atributo: translate

"translate" le indica al navegador si el contenido debe o no traducirse.

Por ejemplo, podemos usarlo para evitar que Google Translate intente traducir automáticamente el nombre de su empresa o marca.

<footer> <p translate = "no"> Apple Company, Inc. </p> </footer>

6.- Atributo: poster

El atributo "poster" sirve exclusivamente para controles de video y nos permite asignar una imagen para que sea mostrada mientras se descarga el video o hasta que el usuario presione el botón de reproducción.

Si no se especifica una imagen, entonces no se mostrará nada hasta que el primer fotograma esté disponible, es entonces cuando se utiliza este primer fotograma como poster.

<video controls
src = "https://stockvideos.org/video-available/8046.mp4"
poster = "https://stockvideos.org/thumbnails/108046-rainbow-lorikeet-parrots-occupying-table-at.jpg">
</video>

7.- Atributo: download

El atributo "download" combinado con un elemento nos permite indicarle al navegador para que descargue una URL en lugar de "navegar" hasta ella, de modo que se solicite al usuario el destino donde desea guardar el recurso solicitado en su equipo local.

Nota: También puede especificar el nombre del archivo.

<a href="download.php?file=xyz.rar" download="website">Download Website 📦</a>

8.- Tag: details

El tag "details" proporciona detalles on-demand al usuario. Si necesitas mostrar contenido opcional y que sea a petición del usuario, esta etiqueta es tu mejor opción.

De forma predeterminada, el "widget" está cerrado. Cuando está abierto, se expande y muestra el contenido que contiene.

La etiqueta "summary" se usa con "details" para especificar un encabezado visible.

<details>
     <summary>Click aquí para ver detalles</summary>
         <table>
                <tr>
                    <th>#</th>
                    <th>Producto</th>
                    <th>Descripción</th>
                    <th>Precio</th>
                </tr>
                <tr>
                    <td>1</td>
                    <td>Zapatillas Nike</td>
                    <td>Zapatillas Nike running para entrenamiento</td>
                    <td>€ 119.95</td>
                </tr>
          </table>
  </details>

9.- Tag: output

La etiqueta representa el resultado de un cálculo. Normalmente, este elemento define una región que se utilizará para mostrar la salida de texto de algún cálculo.

<form oninput="total.value=parseInt(price.value) * parseInt(quantity.value)">
   <input type="integer" id="price" value="0">
          * <input type="number" id="quantity" value="0">
                = <output name="total" for="price quantity"></output>
</form>

10.- Tag: datalist

La etiqueta "datalist" nos permite especificar una lista de opciones predefinidas y ademas permitir a los usuarios agregar más. Proporciona una función de auto completar que le permite obtener las opciones deseadas con una escritura anticipada.

<form action="" method="get">
    <label for="product">Elige tus productos de la lista:</label>
    <input list="products" name="product" id="product">
        <datalist id="products">
           <option value="Ordenador">
           <option value="Cascos">
           <option value="Teclado">
           <option value="Ratón">
           <option value="Monitor">
        </datalist>
     <input type="submit">
 </form>

Consejos:

¿En qué se diferencia de la etiqueta "select" - "option" tradicional? Seleccione la etiqueta para seleccionar uno o más elementos de las opciones que necesita para ir a través de la lista para elegir. datalist es una función avanzada con soporte para auto completar.

11.- Tipo: Range (Slider)

El rango es un tipo de entrada que nos permite seleccionar valores utilizando un "slider". Este tipo de entrada (input) es muy útil en muchos casos como por ejemplo para seleccionar rangos de precios, filtros de distancia, entre otros.

<form method="post">
    <input 
         type="range" 
         name="kilometers" 
         min="5" 
         max="50" 
         step="5" 
         value=""
         onchange="changeValue(event)"/>
 </form>
 <div class="range">
      <output id="output" name="result">  </output>
 </div>

function changeValue(event) {
            let value = event.target.value;
            let output = document.getElementById('output');
            output.value = value;
}

12.- Tag: meter

El tag "meter" nos sirve para medir datos dentro de un rango. Nos permite mostrar como una especie de barra de progreso en base a los valores establecidos:

<label for="shipping">Tracking del producto</label>
<meter id="shipping" value="0.6">Enviado!</meter><br>

Si te gustó el post, o te pareció interesante, piensa en que quizás le pueda servir a alguien más, sobre todo si se esta iniciando en el mundo del desarrollo web. Es por esto que sería de muchísima ayuda, tanto para esas personas, como para mi, que compartas este post. Te lo agradecería muchísimo 🤩

Otra característica importante es que los objetos de valor son inmutables, es decir, no se pueden modificar después de la creación.

La única forma válida de crear Value Objects es pasar toda la información requerida al constructor y validando dicha información en algún método interno.

Martin Fowler define los value objects (VO) o objetos de valor de la siguiente manera: un objeto pequeño y simple, como el dinero o un rango de fechas, cuya igualdad no se basa en la identidad.

Esto significa, dos objetos de valor son iguales, no cuándo se refieren al mismo objeto, sino cuándo el valor que tienen es igual.

Por ejemplo, dos billetes diferentes de cien dólares tienen el mismo valor cuando los usamos para comprar algo (la clase Dinero sería un objeto de valor).

Por otro lado, tenemos entidades que se comparan en identidad, por ejemplo: dos personas pueden tener el mismo nombre, pero no son la misma persona (la clase Persona sería una entidad), por lo tanto, no son iguales.

Es muy importante tener en cuenta que si algo debe representarse como un objeto de valor o una entidad, depende del contexto en el que se utilice.

Atributos de los Value Objects:

Inmutabilidad:

Un objeto no puede ser cambiado por nadie. Una vez creado, solo se puede clonar, por lo que la lógica que creó el objeto confía en que los datos nunca se alterarán. Esto agrega durabilidad adicional al sistema por diseño.

Validación incorporada:

Un objeto contiene validadores integrados que imponen su formato interno. Digamos, una dirección debe tener una ciudad, un código postal y una dirección postal.

Cada vez que crea una instancia de un nuevo objeto de dirección, debe proporcionarle datos válidos; de lo contrario, la creación de instancia del objeto falla.

Ejemplo de un Value Object:

final class Money
{
    /** @var int */
    private $value;

    /** @var string */
    private $currency;

    public function __construct(
        int $value, 
        string $currency = 'USD'
    ){
        $this->value = $value;
        $this->currency = $currency;
    }

    public function equals(Money $money): bool
    {
        return $this->value === $money->value
            && $this->currency === $money->currency;
    }

    public function getValue(): int
    {
        return $this->value;
    }

    public function getCurrency(): string
    {
        return $this->currency;
    }
}

Ejemplo de una Entidad:

class Person
{
    /** @var int */
    private $id;

    /** @var string */
    private $name;

    public function __construct(string $name)
    {
        $this->name = $name;
    }

    public function equals(Person $person): bool
    {
        return $this === $person;
    }

    public function getId()
    {
        return $this->id;
    }

    public function getName()
    {
        return $this->name;
    }
}

Por tanto, los value objects son clases que definen tipos de valores que pueden ser utilizados en cualquier parte de nuestro sistema.

Lo interesante de ellos es que encapsulan información valiosa de nuestro core business y por otro lado, que son fácilmente serializables y totalmente desacoplados a cualquier tecnología.

Y por otro lado, como vemos en el ejemplo, las entidades contienen identificadores “ID” que identifican entidades por tanto una entidad nunca sera igual a otra pese a que su contenido relevante sea el mismo.

Referencias sobre los Value Objects

• ValueObject by M.Fowler

Esto corresponde entonces al principio Tell Don’t Ask mostrado en mi post anterior.

Recuerda que si tienes alguna sugerencia o pregunta, no dudes en dejar tus comentarios al final del post.

Si te gustó este post, ayúdame a que pueda servirle a muchas más personas, compartiendo mis contenidos en tus redes sociales.

Espero que este post haya sido de gran ayuda para ti, y como siempre, cualquier inquietud o duda que tengas, puedes contactarme por cualquiera de las vías disponibles, o dejando tus comentarios al final de este post. También puedes sugerir que temas o post te gustaría leer a futuro.

Tenemos el siguiente ejemplo:

class Price
{
    private $amount;
    private $currency;

    public function __construct(float $amount, string $currency)
    {
        $this->checkAmount($amount);
        $this->checkCurrency($currency);
        $this->amount = $amount;
        $this->currency = $currency;
    }

    private function checkAmount(float $amount)
    {
        if (0 >= $amount) {
            throw new RuntimeException();
        }
    }

    private function checkCurrency(string $currency)
    {
        $allowedCurrencies = ['EUR', 'USD', 'GBP'];

        if (!in_array($currency, $allowedCurrencies)) {
            throw new RuntimeException();
        }
    }

    public function amount() : float
    {
        return $this->amount;
    }

    public function currency() : string
    {
        return $this->currency;
    }
}

En este ejemplo podemos ver rápidamente un pequeño “*Value Object*” que representaría un precio. El value object se compone de dos atributos, la cantidad y la divisa a usar.

Más adelante en otro post estaré ampliando un poco más sobre lo que son los value objects ó objetos de valor.

Tal cual está diseñado, este value object nos obliga a conocer detalles de su implementación, como por ejemplo qué divisas soparte y cuáles no.

Implementación de Constructores Semánticos ó Named Constructors

Para aplicar el refactoring de los constructores semánticos ó named constructors hay que seguir unos pocos pasos:

• Convertir el constructor en privado

• Crear uno o varios métodos estáticos que usando el constructor de la forma adecuada, devuelvan un nuevo objeto.

• Darle a los nuevos métodos estáticos un nombre que describa su intencionalidad (Aquí entra la parte semántica).

• Sustituir las antiguas llamas al constructor por llamadas a los nuevos métodos estáticos

Veamos un ejemplo de este refactor:

<?php

class Price
{
    private $amount;
    private $currency;

    public function __construct(float $amount, string $currency)
    {
        $this->checkAmount($amount);
        $this->checkCurrency($currency);
        $this->amount = $amount;
        $this->currency = $currency;
    }

    private function checkAmount(float $amount)
    {
        if (0 >= $amount) {
            throw new RuntimeException();
        }
    }

    private function checkCurrency(string $currency)
    {
        $allowedCurrencies = ['EUR', 'USD', 'GBP'];

        if (!in_array($currency, $allowedCurrencies)) {
            throw new RuntimeException();
        }
    }

    public static function createPricePounds($amount)
    {
        return new self($amount, 'GBP');
    }

    public static function createPriceInDollars($amount)
    {
        return new self($amount, 'USD');
    }

    public static function createPriceInEuros($amount)
    {
        return new self($amount, 'EUR');
    }

    public function amount() : float
    {
        return $this->amount;
    }

    public function currency() : string
    {
        return $this->currency;
    }
}

Como se puede observar, hemos definido el constructor como privado y añadido 3 nuevos métodos:

• createPriceInDollars

• createPriceInPounds

• createPriceInEuros

Y usarlos es tan sencillo como:

$poundsPrice = Price::createPriceInPounds(22.5);
$dollarsPrice = Price::createPriceInDollars(22.5);
$eurosPrice = Price::createPriceInEuros(22.5);

Ahora, la interfaz pública del value object expone las distintas formas de crear un precio que soporta, con lo que el programador no debe de conocer detalles internos de su implementación.

Consideraciones Finales

Esto no deja de ser una variante de implementación del patrón Factory Method, en la que el método constructor se implementa en la misma clase y por tanto, ha de ser estático.

Hay otro caso de uso en el que los constructores semánticos ó named constructors son de utilidad, y es cuando deseamos simular la sobrecarga del constructor como se hace en JAVA por ejemplo u otros lenguajes que lo permiten, pero que en PHP no esta disponible incluso en la versión 7.3 de PHP.

La solución pasa por crear nuevos constructores semánticos que nos permitan implementar diferentes constructores con diferentes parámetros.

Aprovecho también para mencionar que en la próxima versión de PHP, la versión 7.4 que esté próxima por ser liberada, han incluido los incluidos las contravariación de argumentos como algo nativo.

Esto permitiría sobre escribir métodos de una clase, cambiando los tipos de argumentos que recibe, puedes conocer más acerca de esto en **este post**.

Esto último pudiese ser una variante también como algo adicional a los constructores semánticos ó named constructors.

Recuerda que si tienes alguna sugerencia o pregunta, no dudes en dejar tus comentarios al final del post.

Si te gustó este post, ayúdame a que pueda servirle a muchas más personas, compartiendo mis contenidos en tus redes sociales.

Espero que este post haya sido de gran ayuda para ti, y como siempre, cualquier inquietud o duda que tengas, puedes contactarme por cualquiera de las vías disponibles, o dejando tus comentarios al final de este post. También puedes sugerir que temas o post te gustaría leer a futuro.

Ya falta muy poco para conocer todo lo nuevo de PHP 8, se espera que sea liberada en Diciembre de 2020, es por ello que he querido preparar este artículo en el que resumiré cuales son las mejoras y nuevas características que traerá consigo muy pronto.

Vale la pena destacar, que toda esta información ha sido obtenida durante sus fases de desarrollo por lo que si llega haber un cambio posterior a la publicación de este post, lo estaré actualizando. Te recomiendo estes pendiente de esta entrada por si hay novedades al respecto.

Indice de todo lo nuevo de PHP 8

• JIT

• Mejoras y nuevas características

• Nuevas funciones en PHP

JIT (RFC)

JIT, ó Just In Time por sus siglas, es un compilador que promete significantes mejoras de rendimiento, aunque no siempre dentro del contexto de peticiones web.

Con el compilador JIT activado, el código no sería ejecutado por el VM de Zend, sino directamente por el CPU, lo que supondría una mejora notable en la velocidad de cálculo.

Las mejoras que se obtendrían según Nikita Popov son:

• Un rendimiento significativamente mejor para el código numérico.

• Un rendimiento ligeramente mejor para el código «típico» de una aplicación web PHP.

• El potencial para mover más código de C a PHP, porque PHP será ahora suficientemente rápido.»

Mejoras y nuevas características

Union Types (RFC)

Existen muchos casos en donde es muy útil manejar varios tipos de parámetros utilizando los union types. Bien sea en la definición de los parámetros de entrada, como en los parámetros de retorno de una función

public function foo(Foo|Bar $input): int|float;

Nótese también que el tipo void para métodos que no retornan valores, también puede ser parte de los union types.

Además, las uniones anulables se pueden escribir usando |null, o usando la existente notación ?:

public function foo(Foo|null $foo): void;

public function bar(?Bar $bar): void;

Attributes (RFC)

Los atributos, o comúnmente conocidos como anotaciones en otros lenguajes, ofrecen una vía para añadir o especificar mediante metadatos, las propiedades de una clase, sus propiedades y funciones, sin necesidad de crear los docblock (Bloques de documentación).

Un ejemplo de cómo lucirán los atributos en una clase:

use App\\Attributes\\ExampleAttribute;

<<ExampleAttribute>>
class Foo
{
    <<ExampleAttribute>>
    public const FOO = 'foo';

    <<ExampleAttribute>>
    public $x;

    <<ExampleAttribute>>
    public function foo(<<ExampleAttribute>> $bar) { }
}

<<Attribute>>
class ExampleAttribute
{
    public $value;

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

Constructor property promotion

Esta nueva característica es una de las que más me gusta. Personalmente utilizo Value Objects y DTO’s (Data Transfer Objects ó Objetos de Transferencia de Datos) en mis proyectos como parte de los principios de Domain Driven Design y esta novedad potencia aún más su uso.

En resumen, “property promotion” te permite combinar la definición de propiedades de una clase, la definición del constructor y la asignación de las respectivas variables a cada propiedad, todo en una sola sintaxis en la lista de parámetros del constructor.

Por lo cual, en vez de hacer esto:

class CustomerDTO
{
    public string $name;

public string $email;

public DateTimeImmutable $birth_date;

public function __construct(
        string $name, 
        string $email, 
        DateTimeImmutable $birth_date
    ) {
        $this->name = $name;
        $this->email = $email;
        $this->birth_date = $birth_date;
    }
}

Podrás escribirlo de esta forma:

class CustomerDTO
{
    public function __construct(
        public string $name, 
        public string $email, 
        public DateTimeImmutable $birth_date,
    ) {}
}

Con esta nueva característica, vienen algunas consideraciones importantes:

Solo en constructores

“Promoted properties” pueden ser usadas solo en constructores, esto puede que sea obvio para muchos pero nunca esta demás dejarlo en claro.

No se permiten duplicados

No tendrás permitido declarar propiedades de una clase y “promoted properties” por lo que esto generará un error:

class MyClass
{
    public string $a;

public function __construct(
        public string $a,
    ) {}
}

Propiedades no tipadas están permitidas

Esta permitido utilizar propiedades no tipadas, aún cuando es recomendable y buena práctica mantener nuestras propiedades tipadas:

class MyDTO
{
    public function __construct(
        public $untyped,
    ) {}
}

Valores por defecto simples

“Promoted properties” pueden tener valores por defecto, pero expresiones como new … no están permitidas, por lo que el siguiente ejemplo nos arrojaría un error:

public function __construct(
    public string $name = 'Brent',
    public DateTimeImmutable $date = new DateTimeImmutable(),
) {}

Combinar “promoted properties” y propiedades normales

No todos los constructores deben usar “promotion properties” por lo que puedes hacer un mix de la siguiente forma.

class MyClass
{
    public string $b;

public function __construct(
        public string $a,
        string $b,
    ) {
        $this->b = $b;
    }
}

Lo que si es que hay que tener cuidado de mezclar estas sintaxis, si notas que el código se torna difícil de leer, lo mejor es utilizar constructores normales en su lugar.

Acceso a “promoted properties” desde el cuerpo del constructor

Esta permitido leer los “”promoted properties en el cuerpo del constructor, esto es útil si necesitas añadir validación extra. Puedes utilizar ambas, la variable local y la variable de instancia, ambas funcionan bien.

public function __construct(
    public int $a,
    public int $b,
) {
    assert($this->a >= 100);

if ($b >= 0) {
        throw new InvalidArgumentException('…');
    }
}

Comentarios en promoted properties

Puedes añadir bloques de comentarios en las promoted properties, las cuales estarán disponibles vía reflection:

class MyClass 
{
    public function __construct(
        /** @var string */public $a,
    ) {}
}

$property = new ReflectionProperty(MyClass::class, 'a');

$property->getDocComment(); // "/** @var string */"

Atributos

Tal como los bloques de comentarios, los atributos son permitidos en las promoted properties, este ejemplo:

class MyClass
{
    public function __construct(
        <<MyAttribute>>
        public $a,  
    ) {}
}

Será convertido a:

class MyClass 
{
    <<MyAttribute>>
    public $a;

    public function __construct(
        <<MyAttribute>>
        $a,
    ) {
        $this->a = $a;
    }
}

No esta permitido usarlas en constructores abstractos

El siguiente ejemplo nos arrojaría un error:

abstract class A
{
    abstract public function __construct(
        public string $a,
    ) {}
}

Esta permitido en Traits

No solo esta permitido en clases si no que también en Traits:

trait MyTrait
{
    public function __construct(
        public string $a,
    ) {}
}

var no está soportado

Solo public, protected y private son las únicas palabras válidas, el siguiente ejemplo nos arrojaría un error:

public function __construct(
    var string $a,
) {}

Variadic parameters no pueden ser promovidos

El siguiente ejemplo nos arrojará un error:

public function __construct(
    public string ...$a,
) {}

Reflection para isPromoted

Ambos, ReflectionProperty y ReflectionParameter poseen un nuevo método isPromoted para verificar si una propiedad o método de una clase es promovida

Herencia

Dado que los constructores PHP no necesitan seguir la declaración de su constructor padre, hay poco que decir: se permite la herencia. Sin embargo, si necesita pasar propiedades del constructor secundario al constructor primario, deberá pasarlas manualmente:

class A
{
    public function __construct(
        public $a,
    ) {}
}

class B extends A
{
    public function __construct(
        $a,
        public $b,    
    ) {
        parent::__construct($a);
    }
}

Nuevas funciones en PHP

Nuevo tipo de retorno static (RFC)

Mientras que era posible retornar self, static no era un tipo de retorno válido hasta PHP 8:

class Foo
{
    public function test(): static
    {
        return new static();
    }
}

Nuevo tipo mixed (RFC)

Algunos podrían creer que es un mal necesario: el tipo “mixto” hace que muchos tengan sentimientos encontrados. Sin embargo, hay un muy buen argumento para hacerlo: un tipo faltante puede significar muchas cosas en PHP:

• Una función no devuelve nada o es nula

• Estamos esperando uno de varios tipos

• Esperamos un tipo que no pueda ser insinuado en PHP

Debido a las razones antes mencionadas, es bueno que el tipo mixed sea añadido. mixed en si mismo significa uno de estos tipos:

• array

• bool

• callable

• int

• float

• null

• object

• resource

• string

Note that mixed can also be used as a parameter or property type, not just as a return type.

Also note that since mixed already includes null, it's not allowed to make it nullable. The following will trigger an error:

Ten en cuenta que mixed también se puede usar como parámetro o tipo de propiedad, no solo como tipo de retorno.

También tenga en cuenta que dado que mixed ya incluyenull, no está permitido hacerlo anulable. Lo anterior arrojaría un error como este:

// Fatal error: Mixed types cannot be nullable, null is already part of the mixed type.function bar(): ?mixed {}

Throw expression (RFC)

Este RFC cambia el throw de ser un statement a ser una expresión, lo cual hace posible arrojar una excepción en multiples lugares:

$triggerError = fn () => throw new MyError();

$foo = $bar['offset'] ?? throw new OffsetDoesNotExist('offset');

Permitiendo ::class en objetos (RFC)

Una pequeña pero super útil nueva característica: Ahora es posible usar ::class en objetos, en lugar de tener que usar la función get_class() sobre ellos. Esta nueva característica funciona igual a get_class().

$foo = new Foo();

var_dump($foo::class);

Catches sin captura (RFC)

Cada vez que se requería capturar una excepción antes de PHP 8, se debía almacenar en una variable, independientemente de si usaba esa variable o no. Con Catches sin captura, se puede omitir la variable, por lo que en lugar de esto:

try {
    // Something goes wrong
} catch (MySpecialException $exception) {
    Log::error("Something went wrong");
}

Podremos hacer esto:

try {
    // Something goes wrong
} catch (MySpecialException) {
    Log::error("Something went wrong");
}

Ten en cuenta que es necesario especificar siempre el tipo, no puede tener un catch vacío. Si desea capturar todas las excepciones y errores, puede usar Throwable como tipo de captura.

Coma final en listado de parámetros (RFC)

Ya posible cuando se llama a una función, todavía faltaba el soporte de coma final en las listas de parámetros. Ahora está permitido en PHP 8, lo que significa que puede hacer lo siguiente:

public function(
    string $parameterA,
    int $parameterB,
    Foo $objectfoo,
) {
    // …
}

De cierta forma, esto se asemeja a la definición de arrays en donde sí podemos colocar una coma en el ultimo elemento definido.

Crear objetos DateTime desde interfaz

Ya puede crear un objeto DateTime a partir de un objeto DateTimeImmutable utilizando DateTime::createFromImmutable($immutableDateTime). Al agregar DateTime::createFromInterface() y DatetimeImmutable::createFromInterface() ahora hay una forma generalizada de convertir los objetos DateTime y DateTimeImmutable entre sí.

DateTime::createFromInterface(DateTimeInterface $other);

DateTimeImmutable::createFromInterface(DateTimeInterface $other);

Nueva interfaz Stringable (RFC)

La interfaz Stringable se puede usar para escribir una sugerencia de cualquier cosa que sea una cadena o implemente __toString(). Además, cada vez que una clase implementa __toString(), implementa automáticamente la interfaz detrás de escena y no hay necesidad de implementarla manualmente.

class Foo
{
    public function __toString(): string
    {
        return 'foo';
    }
}

function bar(Stringable $stringable) { /* … */ }

bar(new Foo());
bar('abc');

Mejoras de métodos abstractos en Traits (RFC)

Los Traits pueden especificar métodos abstractos que deben ser implementados por las clases que los usan. Sin embargo, hay una advertencia: antes de PHP 8, la firma de estas implementaciones de métodos no estaba validada. El siguiente ejemplo era válido:

trait Test {
    abstract public function test(int $input): int;
}

class UsesTrait
{
    use Test;

public function test($input)
    {
        return $input;
    }
}

PHP 8 realizará la validación adecuada de la firma del método cuando use un Trait e implemente sus métodos abstractos. Esto significa que deberás escribir esto en su lugar:

class UsesTrait
{
    use Test;

public function test(int $input): int
    {
        return $input;
    }
}

Implementación de Objeto token_get_all() (RFC)

La función token_get_all() devuelve un array de valores. Este RFC agrega una clase PhpToken con un método PhpToken::getAll(). Esta implementación funciona con objetos en lugar de valores simples. Consume menos memoria y es más fácil de leer.

ext-json siempre disponible (RFC)

Anteriormente era posible compilar PHP sin la extensión JSON activa, esto ya no es posible nunca más. Desde que JSON es usado tan ampliamente, es mejor que los desarrolladores puedan siempre confiar en que este siempre allí, en vez de tener que asegurarse primero de que la extensión exista.

Nuevas funciones en PHP

Función str_contains() (RFC)

Algunos podrían decir que esto era posible desde hace mucho tiempo, pero finalmente ya no tenemos que depender de strpos para saber si una cadena contiene otra cadena.

En lugar de hacer esto:

if (strpos('string with lots of words', 'words') !== false) { 
    /* … */ 
}

Podremos hacer esto:

if (str_contains('string with lots of words', 'words')) { 
    /* … */ 
}

Parece algo tonto o sencillo, pero cosas como estas hacen falta en todos los lenguajes, son como especies de helpers que simplifican y optimizan el proceso de desarrollo.

Funciones str_starts_with() y str_ends_with() (RFC)

Estas dos maravillosas funciones han sido añadidas al core de PHP. Un ejemplo vale más que 1000 palabras para describir lo que hacen:

str_starts_with('haystack', 'hay'); // true
str_ends_with('haystack', 'stack'); // true

Función fdiv()

La nueva función fdiv() realiza algo similar a las funciones fmod() y intdiv(), lo cual permite la división por 0. En lugar de errores obtendremos INF, -INF ó NAN, dependiendo del caso.

Función get_debug_type()(RFC)

get_debug_type() retorna el tipo de una variable. Suena como algo que ya gettype() hace?,get_debug_type() retorna un output para arrays, strings, clases anónimas y objetos, mas útil.

For ejemplo, invocar gettype() en la clase \\Foo\\Bar podría retornar object. Usar get_debug_type() retornará el class name.

Función get_resource_id()

Los recursos son variables especiales en PHP, que se refieren a recursos externos. Un ejemplo es una conexión MySQL, otro un identificador de archivo.

A cada uno de esos recursos se le asigna una ID, aunque anteriormente la única forma de saber esa identificación era enviar el recurso a int:

$resourceId = (int) $resource;

PHP 8 añade la función get_resource_id(), haciendo esta operación más obvia y type-safe:

$resourceId = get_resource_id($resource);

Es todo por ahora, recuerda estar pendiente de este post, ya que si aparecen nuevas características, trataré de actualizar el post con lo nuevo.

Recuerda que si tienes alguna sugerencia o pregunta, no dudes en dejar tus comentarios al final del post.

Si te gustó este post, ayúdame a que pueda servirle a muchas más personas, compartiendo mis contenidos en tus redes sociales.

Espero que este post haya sido de gran ayuda para ti, y como siempre, cualquier inquietud o duda que tengas, puedes contactarme por cualquiera de las vías disponibles, o dejando tus comentarios al final de este post. También puedes sugerir que temas o post te gustaría leer a futuro.

Veamos un simple ejemplo:

Lo habitual al crear una función

public function RegisterUser(
    string $name,
    string $lastName,
    string $email,
    string $streetAddress,
    int $streetNumber,
    string $state,
    string $country,
    int $zipCode
) {
    // ...
    // Here comes the implementation 
}

Refactorizando usando Extract Params Into Class

public function RegisterUser(
    User $user,
    Address $address
) {
    // ...
    // Here comes the implementation
}

class User
{
    private $name;
    private $lastName;
    private $email;

    public function  __constructor(
        string $name,
        string $lastName,
        string $email
    ) {
        $this->name = $name;
        $this->lastName = $lastName;
        $this->email = $email;
    }

    // ... semantic getters
}

class Address
{
    private $streetAddress;
    private $streetNumber;
    private $state;
    private $country;
    private $zipCode;

    public function  __constructor(
        string $streetAddress,
        int $streetNumber,
        string $state,
        string $country,
        int $zipCode
    ) {
        $this->streetAddress = $streetAddress;
        $this->streetNumber = $streetNumber;
        $this->state = $state;
        $this->country = $country;
        $this->zipCode = $zipCode;
    }

    // ... semantic getters
}

Consideraciones Finales

Particularmente, es uno de los patrones que uso cuando de refactoring se trata siempre que me encuentro frente una aplicación que fue implementada por alguien más.

O porque en muchos casos, cuando estamos implementando un requerimiento, vamos dejando un esqueleto previo donde debe ir cada cosa, sobre todo cuando se trata de cosas complejas.

Pero que al final, al tener una vista general de donde debe ir cada cosa, siempre encontramos una mejor forma de refactorizar y aquí es donde entra este patrón el cual nos puede ser de muchísima ayuda.

Es por esto que con el uso del patrón de refactoring “Extract Params Into Class” estaremos ante una implementación más limpia, aprovechando siempre la programación orientada a objetos.

A su vez, estaríamos contribuyendo hacia el uso de los principios de un código limpio (Clean Code), legible, fácil de entender y por supuesto siguiendo una arquitectura limpia (Clean Architecture).

Así que no me queda más que recomendarte que lo pongas en práctica en cada uno de tus desarrollos y verás como poco a poco iras añadiendo mas skills a tu carrera profesional.

Recuerda que si tienes alguna sugerencia o pregunta, no dudes en dejar tus comentarios al final del post.

Si te gustó este post, ayúdame a que pueda servirle a muchas más personas, compartiendo mis contenidos en tus redes sociales.

Espero que este post haya sido de gran ayuda para ti, y como siempre, cualquier inquietud o duda que tengas, puedes contactarme por cualquiera de las vías disponibles, o dejando tus comentarios al final de este post. También puedes sugerir que temas o post te gustaría leer a futuro.

El principio de este patrón es convertir operaciones o requests en objetos.

Encapsular una petición como un objeto, de modo que puedan parametrizarse otros objetos con distintas peticiones o colas de peticiones. *Command Pattern*

La idea se basa en la necesidad de ejecutar una acción, para la cual creamos un objeto el cual es denominado Command con la información requerida (Propiedades) para ser luego procesada por un handler.

Cada comando al ser despachado, tendrá su propio handler el cual sabra que acción debe realizar con los datos recibidos por el comando.

Los actores que están involucrados en este patrón son:

• Cliente/Invoker: Es quien inicia la acción a ejecutar, puede ser un controlador o comando de shell.

• Command: Es la clase que encapsula todos los datos requeridos para la ejecución de la acción. Los Command actúan como simples DTO’s por lo que son clases que tienen que ser fácilmente serializables.

• CommandHandler/Handler: Es la clase que es invocada en función del comando despachado y la cual contiene toda la lógica de la acción a realizar.

Por convención, todos los handlers deben tener un método en común para ejecutar los comandos. Este método puede llamarse “handle” ó “execute”, o simplemente podemos aprovechar el método mágico de php y llamar al método __invoke*.*

Adicionalmente, los comandos deberían implementar una misma interfaz Command y todos los handlers una interfaz CommandHandler con un método handle, execute o __invoke por ejemplo.

De esta manera podemos aprovechar el type hinting para que cada handler sepa a qué comando le corresponde atender.

Por razones de comodidad y estandarización, yo particularmente prefiero utilizar el método mágico __invoke de php para los handlers pero es cuestión de cada quien cómo más cómodo con la implementación se sienta.

Pero realmente lo recomiendo usar puesto que se ha convertido en una buena práctica de implementación para este patrón de diseño.

Puedes leer un poco más sobre el [**método mágico de php __invoker](http://php.net/manual/es/language.oop5.magic.php#object.invoke) *Lectura recomendada*

Ejemplo de implementación

namespace Application\Command\User;

final class RegisterUserCommand
{
    private $name
    private $email;
    private $password;

    public function __construct
    (
        string $name, 
        string $email, 
        string $password
    ){
        $this->name = $name;
        $this->email = $email;
        $this->password = $password;
    }

    public function name(): string
    {
        return $this->name;
    }

    public function email(): string
    {
        return $this->email;   
    }

    public function password(): string
    {
        return $this->password;   
    }
}

namespace Application\CommandHandler;

interface CommandHandlerInterface 
{
    public function __invoke();
}

namespace Application\CommandHandler\User;

use Application\Command\User\RegisterUserCommand;
use Application\CommandHandler\CommandHandlerInterface
use Application\Domain\Repository\UserRepository;
use Application\Entity\User;

final class RegisterUserHandler implements CommandHandlerInterface
{
    const MINIMUM_LENGHT = 15;

    private $repository;

    public function __construct (UserRepository $repository)
    {
        $this->repository = $repository;   
    }

    public function __invoke(RegisterUserCommand $command)
    {
        $name = $command->name();
        $email = $command->email();
        $password = $command->password();

        $this->checkEmail();
        $this->checkPassword();

        $user = new User($name, $email, $password);
        $this->repository->save($user);
    }

    private function checkEmail($email)
    {
        if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
            throw new \Exception('Invalid email');
        }

        if ($this->repository->userExists($email)) {
            throw new \Exception('User already exist');
        }
    }

    private function checkPassword($password)
    {
        if (self::MINIMUM_LENGHT > strlen($password)) {
            throw new \Exception('Password too short');
        }
    }
}

namespace Application\Controller\User;

use Application\Command\User\RegisterUserCommand;
use Application\CommandHandler\User\RegisterUserHandler;
use Symfony\Component\HttpFoundation\JsonResponse;
use Symfony\Component\HttpFoundation\Request;

final class UserController
{
    public function registerUser(Request $request): Response
    {
        $name = $request->request->get('name');
        $email = $request->request->get('email');
        $password = $request->request->get('password');

        $command = new RegisterUserCommand($name, $email, $password);

        $userRepository = $this->get('redis.user.respository');
        $handler = new RegisterUserHandler($userRepository);

        try {
            $handler($command);
        } catch (\Exception $e) {
            return new Response($e->getMessage(), Response::HTTP_BAD_REQUEST);
        }

        return JsonResponse::create('', Response::HTTP_CREATED);
    }
}

Casos de uso

• En la arquitectura *CQRS*, se maneja la separación de 2 contextos principales, contextos de lectura y contextos de escritura. Por ende se utiliza este patrón para definir comandos para lectura de datos y comandos para escritura de datos los cuales hacen uso de buses para que de cierta forma podamos ejecutarlos de forma síncrona o asíncrona según se requiera para nuestro caso de uso.

• Las librerías de CommandBus mas conocidas como Tactician o Broadway hacen uso de este patrón.

Conclusión

Particularmente puedo decirte que este patrón es muy potente y que viene a resolver muchísimas situaciones que de otro modo quizás se complicaría y terminaríamos haciendo un código spaguetti.

En sí este patrón es muy limpio y 100% testable, su implementación es prácticamente fácil y sencilla y en combinación con el uso de un CommandBus como el de la librería Tactician o Broadway harán de este patrón tu mejor aliado

El patrón Command es una herramienta muy potente, que nos permite crear código muy limpio y testable, su implementación básica es muy sencilla, y el hacer uso de un CommandBus como Tactician es muy sencillo también.

En lo personal lo utilizo muchísimo sobre todo con la arquitectura CQRS. He experimentado como utilizar el **componente Messenger de Symfony** para tratar de reemplazar las librerías mencionadas y la verdad es que va muy bien.

He logrado implementar el componente para hacer uso de su CommandBus e incluso de sus Transports para encolar los comandos con RabbitMQ. Todo sin acoplarme al framework y mantener los principios de la arquitectura hexagonal intactos.

Hasta aquí dejaré este post sobre este maravilloso patrón de diseño.

Recuerda que si tienes alguna sugerencia o pregunta, no dudes en dejar tus comentarios al final del post.

Si te gustó este post, ayúdame a que pueda servirle a muchas más personas, compartiendo mis contenidos en tus redes sociales.

Espero que este post haya sido de gran ayuda para ti, y como siempre, cualquier inquietud o duda que tengas, puedes contactarme por cualquiera de las vías disponibles, o dejando tus comentarios al final de este post. También puedes sugerir que temas o post te gustaría leer a futuro.

La aplicación es solo de ejemplo y se trata de un API Rest sencillo el cual nos permitirá mostrar cómo desplegar nuestra aplicación en dos instancias de .

¿Qué es Clouding.io?

Clouding.io es una empresa española que nos provee de una excelente plataforma de servicios de infraestructura para nuestras aplicaciones, lo que se traduce en: un proveedor de servicios en la nube que nos permite disponer de Cloud Servers ó los comúnmente llamados: VPS (Servidores privados virtuales).

¿Qué me gusta de Clouding.io?

• Sus instancias son totalmente configurables en base a las necesidades de tu aplicación

• Nos permite crecer y escalar fácilmente en el tiempo.

• Su interfaz de configuración es super minimalista y sencilla, lo cual nos permite intuitivamente aprender a usarla rápidamente.

• El rendimiento de sus instancias es increíble.

• Me proveen de un servidor de nombres (DNS) gratuito. Por ende podrás gestionar tu dominio para que apunte a tus instancias fácilmente.

Desplegar contenedores de Docker en Clouding.io: API Rest con Symfony 4 y Redis

Para mostrar un poco el ecosistema entre una infraestructura con Clouding.io y nuestro software, tomaremos los siguientes requerimientos para demostrar un poco la interacción entre estos aspectos:

1. Dispondremos de un endpoint GET para obtener un listado de productos el cual:

2. Si no esta cacheado en REDIS, los datos se obtendrán desde MYSQL.

3. Si los datos estan cacheados, se tomarán de REDIS.

4. Dispondremos de un endpoint POST para añadir un nuevo producto.

5. Dispondremos de un endpoint POST para invalidar la cache de Redis y poder ver el funcionamiento entre MYSQL Y Redis de una forma clara.

   El API Rest que usaré es a modo de ejemplo por lo que no incorpora ninguna seguridad mediante token (JWT ó OAuth2) para cada petición. Y por tanto se omiten también muchos de los requerimientos y buenas prácticas sugeridas. Acotación

En cuanto a la infraestructura que usaremos utilizando Clouding.io sera:

• Una instancia (servidor) en donde desplegaremos 2 contenedores, un contenedor para PHP-FPM, otro para NGINX.

• Una instancia (servidor) en donde desplegaremos 2 contenedores. Uno para MySQL y otro para Redis.

Ahora sí, manos a la obra y pongámonos a Desplegar contenedores de Docker en Clouding.io.

A partir de aquí, es necesario tener una cuenta en Clouding.io activada y con saldo suficiente para poder crear las instancias necesarias. Consideraciones iniciales

Lo primero que debemos hacer es crear la instancia en donde albergaremos el contenedor de nginx y el contenedor del API Rest en Symfony 4.

Para ello, vamos a acceder a nuestro panel de Clouding.io a la sección de “ Servidores “:

Hacemos click en el botón “ Haz click aquí para crear tu primer servidor “:

En la sección “ Seleccione un Nombre” le asignaremos el nombre a la instancia, en mi caso le pondré: API Rest Symfony 4

Si navegamos un poco más abajo, podremos elegir las especificaciones que tendrá nuestra instancia, para este ejemplo, usaré una instancia con las mínimas características posibles. Sólo aumentaré el tamaño del disco a 10GB de espacio.

Por ahora, no podemos activar la opción de red privada, pero una vez configuremos la segunda instancia, podremos hacerlo para poder comunicarnos entre ambas instancias. Activar Red Privada

Le damos al botón enviar y con esto se creará nuestra primera instancia de servidor.

Una vez terminado todo el proceso veremos nuestra instancia en la lista de servidores en donde podremos posteriormente ver información pertinente, asi como también podremos escalar ( redimensionar) las características de nuestra instancia en caso de ser necesario y a demás realizar una que otra configuración pertinente.

Podremos también apagar o reiniciar nuestra instancia en caso de que sea necesario.

Si hacemos click en el nombre de nuestro servidor, podremos acceder entonces a información importante, así como también podremos configurar mas a fondo nuestra instancia.

Como podemos observar, nos muestra detalles como la IP Pública de nuestra instancia, el nombre de HOST asignado, podrémos descargar nuestras llaves SSH para acceder a nuestra instancia remotamente por la terminal, entre otras cosas más com cambiar la contraseña del usuario root.

Tendremos también acceso a configuración de RED en el respectivo tab situado en la parte superior:

Aquí es donde más adelante debemos configurar la red privada para permitir la comunicación entre los distintos contenedores de cada instancia de servidor.

Adicionalmente, podremos indicar cuales puertos y protocolos estarán abiertos públicamente para su acceso desde el exterior.

Una vez hecho esto, nuestra lista de servidores quedará de la siguiente forma:

Configuración instancia para el API Rest en Symfony 4

Lo siguiente que haremos será configurar nuestros contenedores en la instancia creada para ello. Lo siguiente que haremos es hacer click sobre el nombre de la instancia “ Api Rest Symfony 4 “ en la lista de servidores.

Una vez allí, podremos obtener los datos para conectarnos vía SSH a la instancia del servidor:

Necesitaremos la IP pública, el usuario para linux y la contraseña (Debemos darle click al icono de “ ojo “ para ver la clave asignada). La clave puede ser cambiada por la que queramos. Acotación

Para conectarnos a la instancia basta con ejecutar el siguiente comando:

ssh root@185.166.215.90

Una vez ingresemos el comando, nos solicitará la contraseña de acceso.

Una vez conectados a la instancia, lo primero que haremos será crear el directorio en donde vamos a deplegar el código del API Rest en Symfony 4.

En mi caso desplegaré el código en /var/www/html/clouding.io

mkdir -p /var/www/html

Nos situamos en el directorio:

cd /var/www/html

Paso 1: Clonamos el Repositorio del API Rest

Ahora clonemos el repositorio del API Rest:

git clone https://github.com/franciscougalde-com/sf4-mysql-redis-example.git clouding.io

Nos situamos en el directorio:

cd clouding.io

Antes de seguir, quiero comentarte la estructura de directorios. Dentro del directorio veremos:

• Application: Aquí es donde reside el código del API Rest en Symfony 4

• Infrastructure: Aquí es donde esta toda la configuración requerida para levantar nuestros contenedores de Docker.

• docker-compose-symfony.yml: Docker compose file para levantar los contenedores para el API (Nginx y PHP-FPM).

• docker-compose-mysql-redis.yml: Docker compose file para levantar los contenedores de MySQL y Redis.

Paso 2: Verificar instalación de Docker en la instancia

Como hemos creado la instancia de servidor desde la opción que incluye Docker, ya debemos tener instalado lo requerido. Para verificar que todo está en orden ejecutamos:

docker --version

Efectivamente tenemos instalado Docker. Necesitamos ahora instalar docker-compose, para ello:

# Descargamos docker-compose
sudo curl -L https://github.com/docker/compose/releases/download/1.24.1/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose

# Damos permisos de ejecución
sudo chmod +x /usr/local/bin/docker-compose

# Comprobamos versión
docker-compose --version

Paso 3: Crear contenedores para el API Rest

docker-compose -f docker-compose-symfony.yml build

Esto va a realizar el proceso de Build en donde se descargaran las imágenes de Docker requeridas y se instalarán los recursos esenciales para nuestra configuración requerida.

Una vez que este proceso finalice, procedemos a ejecutar:

docker-compose -f docker-compose-symfony.yml up -d

Para comprobar que todo va en orden, podemos visualizar los contenedores que están en ejecución:

docker container ls

#Otra alternativa es
docker ps

Podemos ver que nuestros dos contenedores están en ejecución correctamente.

docker exec -it sf4_redis_app bash

Y procedemos ahora así a instalar las dependencias del API Rest en Symfony:

composer install

Una vez finalizado esto, podremos verificar que tenemos acceso a nuestro API Rest utilizando Postman o desde cUrl. Para esto debemos realizar una petición **GET al path `/check**, en mi caso, utilizando el IP de la instancia sería:https://185.166.215.90/check`

Deberíamos obtener la respuesta: “ OK “

Por ahora tenemos casi listo nuestro API Rest. Vamos ahora a repetir los mismos pasos para la instancia de MySQL y Redis.

Para ello debemos buscar los datos de acceso (IP, usuario root y contraseña de acceso) de la instancia que hemos llamado “ Mysql + Redis “

Una vez dentro de ella mediante SSH, vamos a crear el mismo directorio que creamos anteriormente:

mkdir -p /var/www/html

Accedemos al directorio:

cd /var/www/html/

Ahora repetiremos el “ Paso 1” y “ Paso 2 “ y en este caso, nuestro paso 3 será:

docker-compose -f docker-compose-mysql-redis.yml build

Esto va a realizar el proceso de Build en donde se descargaran las imágenes de Docker requeridas y se instalarán los recursos esenciales para nuestra configuración requerida.

Una vez que este proceso finalice, procedemos a ejecutar:

docker-compose -f docker-compose-mysql-redis.yml up -d

Para comprobar que todo va en orden, podemos visualizar los contenedores que están en ejecución:

docker container ls

#Otra alternativa es
docker ps

Ahora vemos que se han levantados dos contenedores adicionales, el de MySQL y el de Redis, pero esta es en otra instancia de servidor.

Configurar acceso privado entre instancias

Debemos entrar desde nuestro panel de Clouding.io a cada instancia de servidor, haciendo click en el nombre y seleccionando la pestaña “ RED “.

Una vez alli, debemos habilitar la opción “ Red Privada “ tal como se muestra a continuación:

Configuración Adicional

Necesitamos ahora realizar algunos cambios para que nuestro API Rest funcione como debe ser.

Configuración MySQL

Procedemos a conectamos al contenedor de MySQL:

docker exec -it sf4_redis_mysql bash

Nos conectamos a MySQL:

mysql -uroot -proot

Ahora debemos cambiar algunos privilegios a nuestros usuarios debido a que estamos usando MySQL versión 8. Para ello ejecutamos las siguientes sentencias SQL:

ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'root';

ALTER USER 'root'@'%' IDENTIFIED WITH mysql_native_password BY 'root';

ALTER USER 'api'@'%' IDENTIFIED WITH mysql_native_password BY 'api';

Listo, podemos desconectarnos de MySQL, ejecutamos:

exit

Configuración API Rest

Necesitamos nuevamente acceder vía SSH a la instancia que hemos llamado: Api Rest Symfony 4 para configurar nuestro API Rest y poder indicarle en los parámetros de nuestro fichero de entornos (.env), cómo acceder a MySQL y Redis.

Una vez dentro, nos conectamos al contenedor donde reside nuestro API Rest:

docker exec -it sf4_redis_app bash

Editamos nuestro .env debido a que debemos cambiar los siguientes valores:

# DO NOT DEFINE PRODUCTION SECRETS IN THIS FILE NOR IN ANY OTHER COMMITTED FILES.
#
# Run "composer dump-env prod" to compile .env files for production use (requires symfony/flex >=1.2).
# https://symfony.com/doc/current/best_practices/configuration.html#infrastructure-related-configuration

###> symfony/framework-bundle ###
APP_ENV=dev
APP_SECRET=70652e6d1a682fac64b38a0d26d96fa6
#TRUSTED_PROXIES=127.0.0.1,127.0.0.2
#TRUSTED_HOSTS='^localhost|example\.com$'
###< symfony/framework-bundle ###

###> doctrine/doctrine-bundle ###
# Format described at https://www.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/configuration.html#connecting-using-a-url
# For an SQLite database, use: "sqlite:///%kernel.project_dir%/var/data.db"
# For a PostgreSQL database, use: "postgresql://db_user:db_password@127.0.0.1:5432/db_name?serverVersion=11"
# IMPORTANT: You MUST also configure your db driver and server_version in config/packages/doctrine.yaml
DATABASE_URL=mysql://api:api@IP_PRIVADA_INSTANCIA:3306/api_db
###< doctrine/doctrine-bundle ###

###> snc/redis-bundle ###
# passwords that contain special characters (@, %, :, +) must be urlencoded
REDIS_URL=redis://IP_PRIVADA_INSTANCIA
###< snc/redis-bundle ###

En mi caso, mi fichero .env quedó de la siguiente forma:

# DO NOT DEFINE PRODUCTION SECRETS IN THIS FILE NOR IN ANY OTHER COMMITTED FILES.
#
# Run "composer dump-env prod" to compile .env files for production use (requires symfony/flex >=1.2).
# https://symfony.com/doc/current/best_practices/configuration.html#infrastructure-related-configuration

###> symfony/framework-bundle ###
APP_ENV=dev
APP_SECRET=70652e6d1a682fac64b38a0d26d96fa6
#TRUSTED_PROXIES=127.0.0.1,127.0.0.2
#TRUSTED_HOSTS='^localhost|example\.com$'
###< symfony/framework-bundle ###

###> doctrine/doctrine-bundle ###
# Format described at https://www.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/configuration.html#connecting-using-a-url
# For an SQLite database, use: "sqlite:///%kernel.project_dir%/var/data.db"
# For a PostgreSQL database, use: "postgresql://db_user:db_password@127.0.0.1:5432/db_name?serverVersion=11"
# IMPORTANT: You MUST also configure your db driver and server_version in config/packages/doctrine.yaml
DATABASE_URL=mysql://api:api@ 10.20.10.5:3306/api_db
###< doctrine/doctrine-bundle ###

###> snc/redis-bundle ###
# passwords that contain special characters (@, %, :, +) must be urlencoded
REDIS_URL=redis://10.20.10.5
###< snc/redis-bundle ###

Migraciones de Doctrine

Necesitamos ahora ejecutar las migraciones de Doctrine en nuestro API Rest para crear la tabla necesaria de productos:

Estando conectados al contenedor “ sf4_redis_app “ ejecutamos ahora lo siguiente:

php bin/console doc:mig:mig

Nos mostrará un mensaje de advertencia y nos solicitará que confirmemos la ejecución del proceso, por lo que vamos a escribir “Y” para continuar.

Y con esto ya tendríamos desplegada nuestro API Rest en contenedores utilizando la plataforma Clouding.io

Hasta ahora, ¿Qué hemos logrado hacer?

• Aprendimos a conocer como utilizar la plataforma de clouding.io

• Aprendimos a crear dos instancias de servidor.

• Vimos como instalar lo necesario para desplegar nuestros contenedores.

• Hemos desplegado dos contenedores, uno con nginx y otro con php-fpm en nuestra instancia del API Rest.

• Desplegamos dos contenedores, uno con MySQL y otro para Redis en nuestra instancia destinada para los datos.

• Hemos aprendido cómo configurar las instancias para que puedan comunicarse localmente entre sí mediante la red privada.

• Hemos configurado nuestro proyecto en Symfony 4 para que se conecte a los contenedores de MySQL y Redis. A su vez hemos hecho las migraciones respectivas.

¿Que sigue ahora?

Lo siguiente será probar nuestra API Rest en Symfony 4 con Redis para el cache y MySQL para albergar los datos.

Todo el código de la aplicación en Symfony 4 + Redis lo puedes descargar desde **mi repositorio**

¿Cómo probar el API Rest?

Para demostrar cómo funciona el despliegue de los contenedores en dos instancias separadas de Couding.io, he desarrollado un endpoint que permite consultar la lista de productos.

Si los productos no están en cache, se consultan de la base de datos MySQL y se cachean en Redis con un tiempo de expiración de una hora.

Para poder conocer si los datos vienen de la cache de Redis o de Mysql, la respuesta de la petición incluye en su cuerpo el parámetro “ source” indicando si los datos provienen de MySQL o Redis.

Adicionalmente incorporé el endpoint para añadir mas productos y poder ver el funcionamiento un poco más claro, ya que una vez cacheado los productos, podemos añadir unos cuantos más y no los veremos en la respuesta hasta tanto invalidemos el cache ó el cache expire (en una hora para nuestro caso).

Para probar el API Rest puedes hacer las siguientes peticiones:

Método: GET Url: https://ip_o_host_publico_de_instancia_symfony/check Este endpoint te permite verificar que tienes acceso al API Rest.

Método: GET Url: https://ip_o_host_publico_de_instancia_symfony/api/v1/products Nos va a listar los productos que tengamos en MySQL ó Redis

Método: POST Url: https://ip_o_host_publico_de_instancia_symfony/api/v1/products Nos permite añadir un producto a la Base de Datos. Body: Debes enviar un json en el cuerpo de la petición

#Body para añadir un producto nuevo
{
    "name":"Product 1",
    "price":1256,
    "stock":111
}

Método: POST Url: https://ip_o_host_publico_de_instancia_symfony/api/v1/products/cache-invalidate Nos permite invalidar la cache de redis para poder demostrar su funcionamiento.

Pila de Pruebas para demostrar el funcionamiento

1. Realiza una petición al Post para añadir unos 3 o 4 productos usando el body indicado.

2. Realiza la petición al listado de productos y verás que la primera vez los datos vienen desde la base de datos MySQL.

3. Nuevamente ejecuta la misma petición del listado de productos y verás que provienen de Redis puesto que en la anterior petición fueron cacheados.

4. Prueba añadiendo unos productos más.

5. Intenta nuevamente obtener la lista de productos, verás que si no ha pasado 1 hora desde que la lista inicial ha sido cacheada, los productos que añadas luego, no aparecerán en la petición del listado de productos.

6. Ahora ejecuta la petición para invalidar la cache.

7. Prueba nuevamente obtener el listado de productos, verás que ahora vendrán nuevamente desde MySQL y aparecerán los últimos productos que añadiste y que no habían sido cacheados.

Recuerda que si tienes alguna sugerencia o pregunta, no dudes en dejar tus comentarios al final del post.

Si te gustó este post, ayúdame a que pueda servirle a muchas más personas, compartiendo mis contenidos en tus redes sociales.

Espero que este post haya sido de gran ayuda para ti, y como siempre, cualquier inquietud o duda que tengas, puedes contactarme por cualquiera de las vías disponibles, o dejando tus comentarios al final de este post. También puedes sugerir que temas o post te gustaría leer a futuro.

*Importante: No confundir el Factory Pattern con el patrón Abstract Factory, aunque del mismo tipo, resuelven distintos problemas de distinta forma. A considerar…*

El patrón de diseño Factory viene a solucionar los inconvenientes con la creación o instanciación de nuestros objetos. La idea es encapsular u ocultar al cliente los detalles internos para la creación de ciertos objetos, o dicho de una mejor manera:

Desacoplar la lógica de creación de la lógica de negocio, evitando al cliente conocer detalles de la instanciación de los objetos de los que depende. Propósito del patrón

Implementación del Factory Pattern

Caso de ejemplo

Supongamos que necesitamos desarrollar un sistema para una tienda apple el cual permita mostrar la ficha informativa de cada ordenador fabricado por Apple. Una primera aproximación del código sería:

class AppleTechnicalSheet

class AppleTechnicalSheet
{
    const MACBOOK = 'MAC';
    const MACBOOK_AIR = 'MACAIR';
    const MACBOOK_PRO = 'MACPRO';
    const IMAC = 'IMAC';

    public function getTechnicalSheet(string $model)
    {
        switch ($model) {
            case self::MACBOOK:
                $processor = 'Intel Core i5';
                $model = 'Macbook';
                $cores = 4;
                $ssd = '256GB';
                $memory = '4GB'; 
                break;

            case self::MACBOOK_AIR:
                $processor = 'Intel Core i3';
                $model = 'Macbook Air';
                $cores = 2;
                $ssd = '128GB';
                $memory = '4GB';
                break;

            case self::MACBOOK_PRO:
                $processor = 'Intel Core i7';
                $model = 'Macbook Pro';
                $cores = 6;
                $ssd = '512GB';
                $memory = '16GB';
                break;

            case self::IMAC:
                $processor = 'Intel Core i7';
                $model = 'iMac';
                $cores = 6;
                $ssd = '512GB';
                $memory = '8GB';
                break;

            default:
            throw new InvalidArgumentException("The model you requested doesn't exist");
        }

        $format = 'Model: %s \n Processor: %s \n Cores: %d \n SSD: %s \n Memory: %s';

        return sprintf($format, $model, $processor, $cores, $ssd, $memory);
    }
}

Como se puede observar, esta implementación contiene evidentes problemas y el principal es el uso del switch case encargado de gestionar el modelo a mostrar.

Ya que si a futuro necesitamos añadir nuevos modelos, habra que estar editando el switch para añadirlos por lo que esta implementación no es limpia pero si dependiente de muchísimo mantenimiento.

Ademas de que visto de otra forma, estaríamos rompiendo el principio de responsabilidad única (Single Responsability Principle) de SOLID puesto que una misma clase esta gestionando lo que debería estar separado en varias clases, en nuestro ejemplo, una clase por modelo.

Implementando Factory Pattern

Los pasos a seguir para implementar en este caso el patrón Factory son:

• Encapsular en objetos la información relativa a cada modelo de ordenador. No tiene sentido el tener esas constantes y variables dentro del switch.

• En pro de estandarizar las acciones a realizar, crear una interfaz que todos los objetos implementen. Debido a que los rubros de información a mostrar son iguales, es preferible que todos implementen una misma interfaz que le indique a cada clase qué métodos debe definir.

• Extraer la lógica de creación a una factoría. El cliente (la ficha técnica en este caso) no tiene por qué conocer cómo se instancian estos objetos, no es su responsabilidad, y además no es reutilizable. Saquemos ese código a una clase nueva.

• Usar la factoría en la ficha técnica. Hagamos uso de la factoría en el cliente.

ModelFactory Class

ModelFactory Class

class ModelFactory
{
    const MACBOOK = 'MAC';
    const MACBOOK_AIR = 'MACAIR';
    const MACBOOK_PRO = 'MACPRO';
    const IMAC = 'IMAC';

    public function create(string $model)
    {
        switch ($model) {
            case self::MACBOOK:
                return new Macbook();

            case self::MACBOOK_AIR:
                return new MacbookAir();

            case self::MACBOOK_PRO:
                return new MacbookPro();

            case self::IMAC:
                return new Imac();

            default:
                throw new InvalidArgumentException("The model you requested doesn't exist");
        }
    }
}

TechnicalSheetInterface Interface

interface TechnicalSheetInterface
{
    public function getModel(): string;

    public function getProcessor(): string;

    public function getCores(): int;

    public function getSsd(): string;

    public function getMemory(): string;
}

TechnicalSheet Class

class TechnicalSheet
{
    private $modelFactory;

    public function __construct(ModelFactory $modelFactory)
    {
        $this->modelFactory = $modelFactory;
    }

    public function getTechnicalSheet(string $model)
    {
        /** @var TechnicalSheetInterface $model */
        $model = $this->modelFactory->create($model);

        $format = 'Model: %s \n Processor: %s \n Cores: %d \n SSD: %s \n Memory: %s';

        return sprintf(
            $format,
            $model->getModel(),
            $model->getProcessor(),
            $model->getCores(),
            $model->getSsd(),
            $model->getMemory()
        );
    }
}

Macbook Class

class Macbook implements TechnicalSheetInterface
{
    public function getModel(): string
    {
        return 'Macbook';
    }

    public function getProcessor(): string
    {
        return 'Intel Core i5';
    }

    public function getCores(): int
    {
        return 4;
    }

    public function getSsd(): string
    {
        return '256GB';
    }

    public function getMemory(): string
    {
        return '4GB';
    }
}

MacbookAir Class

class MacbookAir implements TechnicalSheetInterface
{
    public function getModel(): string
    {
        return 'Macbook Air';
    }

    public function getProcessor(): string
    {
        return 'Intel Core i3';
    }

    public function getCores(): int
    {
        return 2;
    }

    public function getSsd(): string
    {
        return '128GB';
    }

    public function getMemory(): string
    {
        return '4GB';
    }
}

Macbook Pro Class

class MacbookPro implements TechnicalSheetInterface
{
    public function getModel(): string
    {
        return 'Macbook Pro';
    }

    public function getProcessor(): string
    {
        return 'Intel Core i7';
    }

    public function getCores(): int
    {
        return 6;
    }

    public function getSsd(): string
    {
        return '512GB';
    }

    public function getMemory(): string
    {
        return '16GB';
    }
}

IMac Class

class IMac implements TechnicalSheetInterface
{
    public function getModel(): string
    {
        return 'iMac';
    }

    public function getProcessor(): string
    {
        return 'Intel Core i7';
    }

    public function getCores(): int
    {
        return 6;
    }

    public function getSsd(): string
    {
        return '256GB';
    }

    public function getMemory(): string
    {
        return '8GB';
    }
}

Resumamos un poco lo implementado

• Definimos la interfaz TechnicalSheetInterface, que permite definir los getters necesarios para generar la información técnica de cada modelo.

• Se ha creado una clase por cada uno de los modelos de ordenadores disponibles.

• Hemos creado una clase ModelFactory que se encarga de construir el modelo según el código que se envíe y de lanzar una excepción en caso de no existir el modelo que se intenta mostrar.

• El cliente TechnicalSheet ahora recibe en el constructor la factoría y hace uso de ella para obtener un objeto que implementa TechnicalSheetInterface con el que muestra la ficha técnica correspondiente.

Ventajas del Factory Pattern

• La factoría es altamente reutilizable, solo hay que pasarla como dependencia.

• El testing del cliente es mucho más sencillo, podemos usar mocks para la factoría y simular cualquier tipo de repuesta por parte de la misma, permitiendo testear todos los casos de uso posibles.

• Si queremos añadir un nuevo modelo, solo hay que editar la factoría y añadirlo ahí, pasará a estar disponible para todos los usuarios de la factoría sin tener que replicar código.

Contras del Factory Pattern

• En este ejemplo, si la cantidad de opciones crece en exceso, la factoría puede llegar a ser una clase difícil de mantener y habría que encontrar otras alternativas al switch como por ejemplo utilizar la clase ReflectionClass de PHP para instanciar la clase correspondiente basado en el nombre del modelo de ordenador a mostrar.

Consideraciones finales

Abstraer al cliente de la creación de los objetos de los que depende es un principio básico en la creación de software de calidad. Esto nos permite cumplir con dos principios SOLID de un plumazo y además seguir uno de los principios de la programación orientada a objetos: la encapsulación de los datos en objetos.

Recuerda que si tienes alguna sugerencia o pregunta, no dudes en dejar tus comentarios al final del post.

Si te gustó este post, ayúdame a que pueda servirle a muchas más personas, compartiendo mis contenidos en tus redes sociales.

Espero que este post haya sido de gran ayuda para ti, y como siempre, cualquier inquietud o duda que tengas, puedes contactarme por cualquiera de las vías disponibles, o dejando tus comentarios al final de este post. También puedes sugerir que temas o post te gustaría leer a futuro.

Por el contrario, el principio nos sugiere es decirles a los objetos que hagan cosas y estos objetos internamente tomaran sus propias decisiones según de su estado actual.

Este principio encaja perfectamente con la idea de que un objeto se define por su comportamiento; y además es fundamental para sacar provecho al polimorfismo y la inversión de control.

Es decir si nos dedicamos a preguntar y tomar nosotros las decisiones estaremos acoplándonos, será prácticamente imposible hacer cambios al objeto en un futuro.

Estaríamos también incumpliendo el “principio Open/Close” de los “principios de SOLID”, nuestro sistema será más difícil de mantener, y por lo tanto poco escalable.

Al ser expuesto el estado de una clase a las demás para que pueda ser manipulada estamos violando su encapsulamiento y por ende moviendo las responsabilidades a las clases de mayor nivel.

¿Usas GETTERS y SETTERS en tus Clases?

Si tu respuesta es sí lo mas probable es que estés inclumpliendo el principio “ Tell Don’t Ask “. Ya que por lo general tendemos a usar estos métodos de nuestras clases para asignar y devolver datos.

Por lo que entonces, desde las clases desde donde instanciemos los objetos, seguramente estaremos haciendo uso de un getter para comprobar su estado o valor, y dependiendo del esto, hacer uso del setter para modificar su estado.

Estaríamos también delegando al controlador aplicar reglas y validaciones que quizás sean de negocio y por ende deban encapsularse en nuestros objetos de clase.

Para solucionar esto, lo mejor sería utilizar métodos semánticos y aplicar el principio de “ Tell Don´t Ask “ para delegar la responsabilidad de validaciones y comprobaciones al objeto como tal, manteniendo entonces nuestros objetos encapsulados.

Ejemplo de violación del principio Tell Don´t Ask

class InvoiceController 
{
    public function payAction()
    {
        // ...     
        $userBalance = $user->getBalance();
        if ($userBalance < $invoiceTotal) {
            throw new NotEnoughFundsException();
        }

        $newBalance = $userBalance - $invoiceTotal;
        $user->setBalance($newBalance);

        // ...
    }
}

Podemos ver en el ejemplo anterior, usamos un getter ($user->getBalance()) para obtener un valor, y luego en base a ese valor, del lado del controlador, realizamos comprobaciones. Aquí estamos violando el principio.

Ejemplo correcto del principio Tell Don´t Ask

class InvoiceController
{
    public function payAction()
    {
        // ...
        try {
            $user->payInvoice($invoice);
        } catch (NotEnoughFundsException $e) {
            // ...
        }
        // ...
    }
}

Y en el objeto user, dentro del método “**payInvoice(...)**" realizar las comprobaciones pertinentes, y si todo va bien, procedemos a realizar el action requerido, de lo contrario, arrojar una excepción la cual debe ser controlada en el lado del controlador.

Y de esta forma podemos entonces aplicar este principio en nuestros desarrollo para cumplir con una arquitectura de código limpia y acoplándonos a los principios de la POO.

Recuerda que si tienes alguna sugerencia o pregunta, no dudes en dejar tus comentarios al final del post.

Si te gustó este post, ayúdame a que pueda servirle a muchas más personas, compartiendo mis contenidos en tus redes sociales.

Espero que este post haya sido de gran ayuda para ti, y como siempre, cualquier inquietud o duda que tengas, puedes contactarme por cualquiera de las vías disponibles, o dejando tus comentarios al final de este post. También puedes sugerir que temas o post te gustaría leer a futuro.

El componente de Symfony fue introducido en la versión 4.3 y aún esta considerado un feature experimental Nota a considerar antes de comenzar a usarlo en producción.

Otra de las necesidades más comunes en cada aplicación que desarrollamos, es el uso de una librería que nos provea un cliente de correo.

Symfony, como era de esperarse, nos provee siempre de herramientas y componente muy útiles que nos permiten desarrollar nuestras aplicaciones con una garantía de calidad impecable.

Es por esto, que quiero mostrarte como funciona este nuevo componente que se introduce en el framework desde la versión de Symfony 4.3

Vale la pena destacar que el componente es quién permite crear los mensajes de correo a enviar, y Mailer es quien realmente se encarga de enviarlos.

Los mensajes se envían mediante “transports”, que pueden ser desde un servidor SMTP local hasta un servicio de terceros para envío masivo de emails.

Este componente nos provee de integración con los siguientes servicios: Amazon SES, MailChimp, Mailgun, Gmail, Postmark y SendGrid. Cada uno de estos se instala por separado así que para este post te mostraré un ejemplo de como usar en tu aplicación Amazon SES.

Instalación del componente Mailer para Amazon SES

composer require symfony/amazon-mailer

Este paquete, al terminar su instalación, añade algunas variables a nuestro fichero de entorno .env para poder configurar los parámetros requeridos para su funcionamiento:

# .env
AWS_ACCESS_KEY=...
AWS_SECRET_KEY=...
MAILER_DSN=smtp://$AWS_ACCESS_KEY:$AWS_SECRET_KEY@ses

Y con esto ya tenemos todo listo. Lo siguiente es inyectar el servicio de email en cualquier parte donde sea requerido gracias al **autowiring de symfony**, añadiendo tan solo el argumento MailerInterface en el constructor de tu clase eso es todo

use Symfony\Component\Mailer\MailerInterface;
use Symfony\Component\Mime\Email;

class SomeService
{
    private $mailer;

    public function __construct(MailerInterface $mailer)
    {
        $this->mailer = $mailer;
    }

    public function sendNotification()
    {
        $email = (new Email())
            ->from('hello@example.com')
            ->to('you@example.com')
            ->subject('Time for Symfony Mailer!')
            ->text('Sending emails is fun again!')
            ->html('<p>See Twig integration for better HTML integration!</p>');

        $this->mailer->send($email);
    }
}

Cuando llamas a $this->mailer->send($email), el mensaje se envía inmediatamente. Si quieres mejorar el rendimiento, usa el componente Messenger para enviar los mensajes de manera asíncrona. Lee ademas este artículo de la documentación de Symfony para aprender más sobre cómo hacerlo.

Es todo por ahora con todo lo relacionado con este maravilloso componente de Symfony. Estaré publicando actualizaciones a medida que el componente vaya incorporando nuevas funcionalidades.

Recuerda que si tienes alguna sugerencia o pregunta, no dudes en dejar tus comentarios al final del post.

Si te gustó este post, ayúdame a que pueda servirle a muchas más personas, compartiendo mis contenidos en tus redes sociales.

Espero que este post haya sido de gran ayuda para ti, y como siempre, cualquier inquietud o duda que tengas, puedes contactarme por cualquiera de las vías disponibles, o dejando tus comentarios al final de este post. También puedes sugerir que temas o post te gustaría leer a futuro.

En este post quiero enseñarte otro patrón de diseño que utilizo comúnmente en los proyectos que he tenido la oportunidad de trabajar y es el patrón de diseño DECORATOR o Decorador.

Este patrón nos permite resolver el problema de agregar comportamiento o funcionalidad específica a los objetos de una clase. La POO nos permite recurrir a la herencia cuando se trata de añadir funcionalidad extra a nuestra clase.

Pero, el problema radica en que no podemos heredar de más de una clase, es decir, dada una clase C, no podrá heredar a la vez de una clase A y B.

Es por eso que el patrón de diseño Decorator nos permite añadir comportamiento específico a los objetos de una clase sin tener que añadirlo a la clase como tal.

Por otro lado, nos permite conservar el principio de Open/Closed del patrón de diseño SOLID visto en este post. En donde cada entidad o clase esta abierta para su extensión pero cerrada para su modificación.

También nos permite mantener nuestras clases con responsabilidades únicas por ende nuestras clases evitan complejidad y se mantienen ligeras de código. Se acopla también al principio Single Responsability de SOLID

Ejemplo de implementación del patrón de diseño DECORATOR en PHP

Para este ejemplo imaginemos que necesitamos calcular el precio de una Macbook basado en su versión y tamaño de pantalla.

Lo primero seria definir nuestra clase Macbook la cual implementa el getter para obtener el precio base del producto.

class Macbook
{
    protected $basePrice = 1500;

    public function getPrice()
    {
        return $this->basePrice;
    }
}

Lo siguiente es generar nuestra clase abstracta decoradora la cual llamaremos MacbookDecorator

abstract class MacbookDecorator
{
    protected $price;
    protected $macbook;
    public function __construct($macbook)
    {
        $this->macbook = $macbook;
    }
    public function getPrice()
    {
        return $this->macbook->getPrice() + $this->price;
    }
}

Como podemos ver, añade una nueva funcionalidad la cual es calcular el precio base de la macbook en donde sumamos el precio base con el precio según la versión y tamaño de la pantalla. Verémos mas adelante como funciona.

Ahora vamos a crear una versión nueva del macbook el cual incrementará el precio de la macbook base. Añadiremos la versión MacbookPro, para ello creamos nuestra clase MacbookPro la cual va a extender de nuestro decorador.

class MacbookPro extends MacbookDecorator 
{ 
  protected $price = 950; 
}

De igual forma crearemos dos clases para nuestros tamaños de pantalla disponible.

class WithDisplaySize15 extends MacbookDecorator 
{ 
  protected $price = 350; 
}

class WithDisplaySize17 extends MacbookDecorator 
{ 
  protected $price = 700; 
}

Gracias al decorator podemos combinar nuestras clases para generar variantes de nuestro producto por ejemplo para nuestra tienda de e-commerce.

Probando la implementación anterior

Para probar veamos lo siguiente:

$macbook = new Macbook();
echo 'Una Macbook con pantalla de 13 pulgadas cuesta ' . $macbook->getPrice() . ' euros' . PHP_EOL;

$macbook15Pulg = new WithDisplaySize15(new Macbook());
echo 'Una Macbook con pantalla de 15 pulgadas cuesta ' . $macbook15Pulg->getPrice() . ' euros' . PHP_EOL;

$macbook17Pulg = new WithDisplaySize17(new Macbook());
echo 'Una Macbook con pantalla de 17 pulgadas cuesta ' . $macbook17Pulg->getPrice() . ' euros' . PHP_EOL;

$macbookPro = new MacbookPro(new Macbook());
echo 'Una Macbook Pro con pantalla de 13 pulgadas cuesta ' . $macbookPro->getPrice() . ' euros' . PHP_EOL;

$macbookPro15Pulg = new WithDisplaySize15(new MacbookPro(new Macbook()));
echo 'Una Macbook Pro con pantalla de 15 pulgadas cuesta' . $macbookPro15Pulg->getPrice() . ' euros' . PHP_EOL;

$macbookPro17Pulg = new WithDisplaySize17(new MacbookPro(new Macbook()));
echo 'Una Macbook Pro con patanlla de 17 pulgadas cuesta ' . $macbookPro17Pulg->getPrice() . ' euros' . PHP_EOL;

Con esta implementación, podremos tener el precio de la macbook base ( que viene con 13 pulgadas), la misma versión pero con pantalla de 15 y 17 pulgadas respectivamente.

Lo mismo con la versión MacbookPro. Puedes ver el de este ejemplo en mi **github**

Otra forma de implementar en este patrón de diseño es por ejemplo en nuestros ApplicationServices o UseCases en donde cada uno tiene una funcionalidad específica pero queremos que cuando se ejecuten, se registre un log y se notifique por email sobre la acción realizada.

Aquí el approach seria, crear un decorator para nuestros ApplicationServices en donde inyectemos nuestra clase Logger y nuestra clase Mailer y de cierta forma añadimos funcionalidad extra de una forma simple y sutil, sin sobrecargar nuestras clases y sin repetir funcionalidad.

Hasta aqui todo lo relacionado con este patrón de diseño super útil y que debemos tener en cuenta para nuestros desarrollos.

Todo el contenido del ejemplo puedes conseguirlo en este **gist** de Github.

Recuerda que si tienes alguna sugerencia o pregunta, no dudes en dejar tus comentarios al final del post.

Si te gustó este post, ayúdame a que pueda servirle a muchas más personas, compartiendo mis contenidos en tus redes sociales.

Espero que este post haya sido de gran ayuda para ti, y como siempre, cualquier inquietud o duda que tengas, puedes contactarme por cualquiera de las vías disponibles, o dejando tus comentarios al final de este post. También puedes sugerir que temas o post te gustaría leer a futuro.

Arquitectura de Software

Antes de empezar, es importante saber que la arquitectura de software es un conjunto de convenciones, reglas y normas que se deben cumplir durante el desarrollo de software para garantizar calidad, rendimiento y escalabilidad a lo largo del tiempo.

El implementar una arquitectura de software nos va a permitir entre otras cosas, que todos los involucrados en el proyecto, desarrolladores, analistas, devops, etc. puedan compartir una misma linea de trabajo y de cierta manera ir hacia una misma dirección.

Vale la pena resaltar que la arquitectura de software representa un pilar fundamental en la creación de software y que debe situarse en la parte mas alta del diseño de software.

Una arquitectura de software bien definida nos va a garantizar entre otras cosas, escalabilidad, rendimiento y sobre todo éxito al momento de desarrollar el proyecto.

Algunos ejemplos de arquitecturas que ya muchos de ustedes conocen y utilizan en sus proyectos son el Modelo Vista Controlador ( MVC), que ya muchos frameworks lo incorporan nativamente. Arquitectura Orientada a Servicios ( SOA por sus siglas en ingles) o tan sencillo como la arquitectura Cliente-Servidor.

Arquitectura Hexagonal

Dado que la complejidad de los sistemas a desarrollar hoy dia se ha incrementado notablemente, se ha requerido cada vez mas el uso de “ Arquitecturas Limpias” o “ Clean Architecture “ que nos permitan separar las responsabilidades en capas y por ende la definición de reglas entre ellas.

La arquitectura hexagonal, también conocida como “ Arquitectura de Puertos y Adaptadores “ por si gustas leer un poco mas en profundidad.

Se refiere a Puertos y Adaptadores por:

• Puerto: definición de una interfaz pública.

• Adapter: especialización de un puerto para un contexto concreto. Es decir, una clase que implemente una interfaz o puerto.

Esta arquitectura también se basa precisamente en un conjunto de normas, patrones y reglas, expresadas en capas que se añaden para identificar responsabilidades, definir la forma en que se accede a ellas y el flujo que tendrán a lo largo del proyecto.

Lo interesante de esta arquitectura es que pese a que nos obliga a seguir lineamientos y reglas, es totalmente flexible al momento de ser implementada en nuestros proyectos.

He visto cómo en distintos proyectos su implementación, la estructura de directorios, la identificación de las capas, varia y sin embargo sigue manteniendo y haciendo caso fiel a sus principios.

Beneficios de la Arquitectura Hexagonal

• Mediante sus reglas, nos guía netamente hacia la construcción de un software de Calidad.

• La Arquitectura Hexagonal abraza al patrón SOLID por lo que estamos ante una arquitectura que fomenta el uso de patrones de diseño altamente efectivos.

• Nos obliga a que el core business o nuestra lógica de negocios no este acoplada a ninguna tecnología o framework.

• Facilita estar desacoplado del método de entrega haciendo que sea más sencillo que un caso de uso funcione para una aplicación móvil, un API Rest, una web tradicional, una web SPA por , etc…

• Como cualquier arquitectura basada en la inversión de dependencias facilita que los componentes se puedan unit testear.

Entendiendo la Arquitectura Hexagonal

Ahora bien, muy bonito eso de las capas, de los puertos y adaptadores, de las reglas y principios, pero y de que va todo esto?

Pues bien, en esta Introducción a la Arquitectura Hexagonal, quiero mostrarte cuales son esas capas que se añaden, cuál es la función de cada capa y cuál es el flujo entre ellas.

La arquitectura hexagonal, como su nombre lo dice, puede ser vista como un simple hexágono, sin importar el numero de lados, es solo a manera representativa.

También, he visto algunos artículos donde explican la arquitectura hexagonal basándose en el diagrama de cebolla.

En este tipo de diagrama, cada capa de la cebolla representa una capa de la arquitectura visualizándolas desde lo mas externo a lo más interno.

Capas de la Arquitectura Hexagonal

• Infrastructure

• Application

• Domain

Infrasctructure: Corresponde a todo lo que tenga que ver con tecnologías y frameworks, por ejemplo un servicio o adaptador de Email, o un sistema de colas RabbitMQ, los controladores, migraciones de doctrine, los Commands de terminal, entre otros.

Application: Aquí es donde residen los Casos de Uso ó Application Services que son los encargados de orquestar cada funcionalidad de la aplicación.

Domain: El domain es el núcleo de esta arquitectura y en esta capa reside todo lo que debemos proteger de nuestro core business.

Por ejemplo, los modelos, objetos de valor, interfaces, validaciones, entre otros.

Por último y no menos importante, es importante conocer el flujo entre ellas, ya que las capas mas externas pueden conocer lo que hay en las capas mas internas, pero una capa interna no conoce lo que se implementa en su capa mas externa.

Esto último cumple con el principio de inversión de dependencias de los principios **SOLID. Si quieres leer un poco más sobre este patrón, puedes ir a [este post](https://www.franciscougalde.com/2019/07/26/patrones-de-diseno-en-php-solid/)**.

Consideraciones finales

He de decirte estimado lector, que hoy en día, la tecnología avanza a pasos agigantados, y es por ello que debemos mantenernos al pie del cañon con todo este tema de lo contrario quedaremos deprecados.

No obstante es importante que incorporemos arquitectura de software en nuestros proyectos independientemente del framework o tecnología que utilicemos.

Esto para garantizar y proteger nuestro legado más preciado que es el núcleo de la aplicación, para que si el día de mañana la tecnología o framework muere, nuestro desarrollo pueda ser re-implementado nuevamente sin tanto trauma.

A simple vista esto es lo que representa la arquitectura hexagonal. En próximos post trataré de ampliar un poco más la información y de añadir un poco más como por ejemplo: Domain Driven Design ( DDD) y como combinarlo con la arquitectura hexagonal.

Recuerda que si tienes alguna sugerencia o pregunta, no dudes en dejar tus comentarios al final del post.

Si te gustó este post, ayúdame a que pueda servirle a muchas más personas, compartiendo mis contenidos en tus redes sociales.

Espero que este post haya sido de gran ayuda para ti, y como siempre, cualquier inquietud o duda que tengas, puedes contactarme por cualquiera de las vías disponibles, o dejando tus comentarios al final de este post. También puedes sugerir que temas o post te gustaría leer a futuro.

La arquitectura basada en Microservicios en PHP es un concepto que esta muy de moda y que ha sido implementado por muchos gigantes tecnológicos como Amazon, eBay, Netflix Twitter, Paypal entre otros.

En este post quiero adentrarte un poco sobre lo que es un microservicios en comparación a los sistemas monolíticos, cuales son sus ventajas y desventajas y sobre todo, cuando debemos implementar la arquitectura de Microservicios en PHP.

Microservices, Microservices Everywhere!

Pero y… ¿Qué son los Microservicios en PHP?

Generalmente, los grandes y complejos sistemas se han desarrollado siguiendo lo que hasta ahora conocemos como sistemas monolíticos (mono-proceso) donde el mantenimiento, escalabilidad y evolución, se tornaba en algo traumático.

Es aquí en donde aparece la arquitectura basada en microservicios el cual su principio se basa en identificar y separar funcionalidad del sistema en micro proyectos o servicios autónomos que trabajan de forma independiente.

Es decir, cada micro servicio corresponde por así decirlo a un módulo o bundle cuya funcionalidad es específica. Y que se estará ejecutando de forma paralela en distintos servidores y comunicándose entre ellos por diferentes vías disponibles: Http Request, Proyecciones, Colas de Mensajes, entre otros.

Cada microservicio es responsable de brindar solución a un área de negocio concreta, abstrayendo al resto del sistema de los detalles concretos de la implementación, favoreciendo su independencia, el mantenimiento y la evolución de cada uno de ellos.

Al gestionar cada micro servicio como un pequeño sistema, nos da la posibilidad de ser desplegados sin perjudicar a los demás, favoreciendo así la escalabilidad.

¿Cuáles son sus ventajas?

• Potencia la diversidad tecnológica: es decir, podemos utilizar distintos stacks tecnológicos para cada microservicio, incluso, distintos lenguajes de programación.

• Permite despliegues independientes.

• La capacidad de testing de cada microservicio es mayor.

• Permite que los desarrollos sean independientes y puedan avanzar en paralelo.

• La escalabilidad se torna mas eficiente y continua.

• Facilita el mantenimiento a lo largo del tiempo.

¿Cuáles son sus desventajas?

Las desventajas de los microservicios se deben en gran parte a la introducción del concepto de sistemas distribuidos, algunas de estas son:

• Aumentará la complejidad en la gestión de la configuración y despliegue por lo que cada microservicio va a requerir su propia configuración de build, testing, despliegue (Jenkins, CircleCI, Git, etc.).

• Aumenta la complejidad para mantener la transaccionalidad de cada operación.

• El rendimiento se puede ver afectado debido a saturaciones de la red o a procesos de (de)serialización.

• Monitorizar el sistema será más complejo.

• Será más difícil gestionar los errores correctamente.

¿Cuándo implementar la arquitectura de Microservicios en PHP?

La arquitectura de microservicios supone un esfuerzo extra a los desarrolladores no solo a nivel de implementación si no a nivel de configuración, comunicación, monitorización, manejo de los errores, registro y log de transacciones, entre otros, ademas de otros factores derivados de los sistemas distribuidos.

Todo esto supone un coste de esfuerzo/tiempo añadido al proyecto que debe ser estimado debidamente antes de tomar la decisión final de si implementar o no esta arquitectura de microservicios.

La decisión de si utilizar o no este tipo de diseño a la hora de desarrollar nuestro software se fundamenta básicamente en el nivel complejidad que va a alcanzar.

Si el nivel de complejidad del software es bajo, no es aconsejable dedicar esfuerzos en implementar esta arquitectura.

Como mencioné anteriormente la finalidad de esta arquitectura de microservicios es tratar de distribuir la complejidad de los sistemas en pequeñas piezas cuya responsabilidad o función sea única.

A partir de cierto nivel de complejidad del sistema, las ventajas que ofrecen los microservicios harán viable el esfuerzo necesario que la productividad del equipo sea mayor.

Consideraciones Finales

La arquitectura de microservicios viene a resolver importantes retos y problemas relacionados a la complejidad de los sistemas actuales.

Y es que gracias a una buena implementación de los mismos garantizan que sistemas complejos, puedan ser gestionados y administrados de forma eficiente.

Sin embargo, hay que tener pulso y mucho tacto a la hora de decidir si utilizar o no esta arquitectura.

Si tienes dudas en cuanto a si utilizar o no esta arquitectura yo te sugiero que pienses en el siguiente flujo de decisiones:

1. Inicies el desarrollo del software como un simple sistema monolítico.

2. Si la complejidad aumenta con cada versión y sientes que se esta convirtiendo en algo insostenible, puedes proceder a pasar de monolítico a microservicios.

Lo interesante de la arquitectura de microservicios es que es totalmente flexible y puede ser usado también como patrón de refactoring.

Ya que permite que un sistema monolítico se convierta en multiple microservicios.

Algunas Referencias

Puedes leer más al respecto en los siguientes artículos.

• Enterprise Approaches to Microservices: Choose Yours Wisely, SIDDHARTHA BHATIA

• Microservices. James Lewis y Martin Fowler.

• Sam Newman, «The Principles of Microservices», 2015

• Microservices in a Nutshell. Pros and Cons. Philipp Hauer.

Recuerda que si tienes alguna sugerencia o pregunta, no dudes en dejar tus comentarios al final del post.

Si te gustó este post, ayúdame a que pueda servirle a muchas más personas, compartiendo mis contenidos en tus redes sociales.

Espero que este post haya sido de gran ayuda para ti, y como siempre, cualquier inquietud o duda que tengas, puedes contactarme por cualquiera de las vías disponibles, o dejando tus comentarios al final de este post. También puedes sugerir que temas o post te gustaría leer a futuro

El componente **Mime de Symfony fue introducido en la versión 4.3** y aún esta considerado un feature experimental Nota a considerar antes de comenzar a usarlo en producción.

Otro de los componentes nuevos creados por Symfony e incluidos en su versión 4.3 es el componente MIME.

Este componente nos permite crear y manipular mensajes MIME, que es el formato utilizado para enviar emails.

Por otro lado, incluye algunas utilidades relacionadas con “los tipos MIME”. El estandar MIME completo (Multipurpose Internet Mail Extensions) es una serie de estándares que definen las funcionalidades añadidas con el paso del tiempo a los emails originales basados en texto (como la posibilidad de adjuntar archivos o formatear los contenidos con HTML).

El componente Mime abstrae toda esa complejidad por nosotros para proporcionar dos formas de crear mensajes MIME. La primera es una API de alto nivel basada en la clase Symfony\Component\Mime\Email y que nos permite de forma fácil y sencilla crear emails con requerimientos básicos y comunes:

use Symfony\Component\Mime\Email;

$email = (new Email())
    ->from('fabien@symfony.com')
    ->to('foo@example.com')
    ->subject('Important Notification')
    ->text('Lorem ipsum...')
    ->html('<h1>Lorem ipsum</h1> <p>...</p>')
;

Como se puede ver en el ejemplo anterior, de una forma sencilla nos permite mediante un objeto de la clase Symfony\Component\Mime\Email, configurar los parámetros de envío a los que estamos acostumbrados normalmente.

La otra forma de crear los mensajes MIME es con una API de bajo nivel basada en la clase Symfony\Component\Mime\Message y que te brinda el control absoluto sobre todas y cada una de las partes del mensaje.

El siguiente ejemplo que veremos a continuación esta basado en el anterior pero profundizando a un nivel mas bajo la API y configurando en detalle las opciones que queremos para el envío:

use Symfony\Component\Mime\Header\Headers;
use Symfony\Component\Mime\Message;
use Symfony\Component\Mime\Part\Multipart\AlternativePart;
use Symfony\Component\Mime\Part\TextPart;

$headers = (new Headers())
    ->addMailboxListHeader('From', ['fabien@symfony.com'])
    ->addMailboxListHeader('To', ['foo@example.com'])
    ->addTextHeader('Subject', 'Important Notification')
;

$textContent = new TextPart('Lorem ipsum...');
$htmlContent = new TextPart('<h1>Lorem ipsum</h1> <p>...</p>', 'html');
$body = new AlternativePart($textContent, $htmlContent);

$email = new Message($headers, $body);

Funcionalidades extra del componente MIME:

• Puedes definir las direcciones de email mediante cadenas de texto y objetos, con o sin nombre, etc.

• Soporta la posibilidad de embeber imágenes, que es muy útil al crear mensajes HTML complejos.

• Soporta los archivos adjuntos usando tanto archivos físicos como recursos/streams PHP.

Integración con Twig

Otra de las tantas funcionalidades del componente Mime es su integración total con Twig.

La clase Symfony\Bridge\Twig\Mime\TemplatedEmail por ejemplo permite renderizar una plantilla Twig para generar los contenidos del email:

use Symfony\Bridge\Twig\Mime\TemplatedEmail;

$email = (new TemplatedEmail())
    ->from('fabien@symfony.com')
    ->to('foo@example.com')
    // ...

    // pasa la ruta donde está la plantilla con los contenidos
    ->htmlTemplate('messages/user/signup.html.twig')

    // este método define los parámetros (nombre => valor) pasados a la plantilla
    ->context([
        'expiration_date' => new \DateTime('+7 days'),
        'username' => 'foo',
    ])
;

Funcionalidades extras del componente MIME con TWIG

• Permite adjuntar de forma más sencilla las imágenes.

• Creación automática de estilos CSS inline: esto es super importante puesto que no todos los clientes de email soportan estilos CSS embebidos entre las etiquetas <style> ... </style>.

• Permite el Renderizado de contenidos Markdown si quieres definir el contenido de tus emails con este popular formato.

• Soporte del lenguaje de plantillas Inky, que es uno de los más populares para crear mensajes HTML con diseño responsive.

El componente Mime definitivamente es tan completo que te provee de absolutamente todo lo que necesitas para crear cualquier email que requieras para tus desarrollos

Lo que sí tienes que tener en cuenta es que no envía los emails. El envío de los mensajes esta delegado a otro de los componentes de Symfony llamado “” y que se incluye también desde la versión 4.3 de Symfony. Estaré publicando acerca de este componente más adelante.

Serializando Mensajes de Email

Los mensajes de email creados con las clases de Email o Message, pueden ser fácilmente serializadas puesto que ellas son objetos simple de datos.

$email = (new Email())
    ->from('fabien@symfony.com')
    // ...
;

$serializedEmail = serialize($email);

Un caso de uso particular es para almacenar los mensajes de email serializados, incluirlos luego en un Message y ser enviado con el Componente Messenger y ser recreado luego nuevamente cuando se vaya a enviar.

Debes usar la clase RawMessage para recrear el mensaje de email desde nuestros contenidos serializados:

use Symfony\Component\Mime\RawMessage;

// ...
$serializedEmail = serialize($email);

// later, recreate the original message to actually send it
$message = new RawMessage(unserialize($serializedEmail));

Es todo por ahora con todo lo relacionado con este maravilloso componente de Symfony. Estaré publicando actualizaciones a medida que el componente vaya incorporando nuevas funcionalidades.

Recuerda que si tienes alguna sugerencia o pregunta, no dudes en dejar tus comentarios al final del post.

Si te gustó este post, ayúdame a que pueda servirle a muchas más personas, compartiendo mis contenidos en tus redes sociales.

Espero que este post haya sido de gran ayuda para ti, y como siempre, cualquier inquietud o duda que tengas, puedes contactarme por cualquiera de las vías disponibles, o dejando tus comentarios al final de este post. También puedes sugerir que temas o post te gustaría leer a futuro.

En su núcleo, Slim es un despachador que recibe una petición HTTP, invoca un rutina callback, y devuelve una respuesta HTTP Así de sencillo!

Cuando usar Slim?

Slim Framework es una herramienta ideal para crear API´ s que consuman, reutilicen o publiquen datos.

También es recomendada cuándo requieras hacer un prototyping de una aplicación en poco tiempo, es decir, cuando necesites poner en marcha un proyecto lo antes posible.

Es que, incluso puedes crear aplicaciones web que incluyan interfaces de usuario. Sinceramente este framework es potente y lo interesante de todo es que es rápido y muy ligero de código.

Otro punto a favor es que su curva de aprendizaje es muy corta por lo que de seguro te podrás adentrar en él en pocos días, e incluso hasta en una misma tarde.

Cómo funciona?

Lo primero que necesitamos es un servidor web como Nginx o Apache. Para ello, te sugiero leer el siguiente .

Debes configurar tu servidor web de tal forma que envíe todas las peticiones apropiadas a un archivo PHP que actúa de “ controlador frontal” ó “ front-controller “.

Desde este fichero PHP es que iniciamos y ejecutamos nuestra app con Slim Framework

Una aplicación Slim contiene rutas que responden a una petición HTTP específica. Cada ruta invoca un “ callback” que no es más que un método que se ejecuta y retorna una respuesta HTTP.

Para comenzar, lo primero que hay que hacer es instanciar y configurar la aplicación Slim. Luego, definir las rutas de la aplicación y finalmente ejecutar la aplicación Slim.

Un ejemplo de como quedaría nuestro controlador frontal sería:

<?php
use Psr\Http\Message\ResponseInterface as Response;
use Psr\Http\Message\ServerRequestInterface as Request;
use Slim\Factory\AppFactory;

require __DIR__ . '/../vendor/autoload.php';

/**
 * Instantiate App
 *
 * In order for the factory to work you need to ensure you have installed
 * a supported PSR-7 implementation of your choice e.g.: Slim PSR-7 and a supported
 * ServerRequest creator (included with Slim PSR-7)
 */
$app = AppFactory::create();

// Add Routing Middleware
$app->addRoutingMiddleware();

/*
 * Add Error Handling Middleware
 *
 * @param bool $displayErrorDetails -> Should be set to false in production
 * @param bool $logErrors -> Parameter is passed to the default ErrorHandler
 * @param bool $logErrorDetails -> Display error details in error log
 * which can be replaced by a callable of your choice.

 * Note: This middleware should be added last. It will not handle any exceptions/errors
 * for middleware added after it.
 */
$errorMiddleware = $app->addErrorMiddleware(true, true, true);

// Define app routes
$app->get('/hello/{name}', function (Request $request, Response $response, $args) {
    $name = $args['name'];
    $response->getBody()->write("Hello, $name");
    return $response;
});

// Run app
$app->run();

Request y Response

Cuando creamos una aplicación Slim, a menudo estaremos trabajando directamente con los objetos Request y Response. Estos objetos representan la solicitud HTTP real recibida por el servidor web y la eventual respuesta HTTP devuelta al cliente.

Cada ruta de la aplicación Slim recibe los objetos de Request y Response actuales como argumentos del callback. Es decir, nuestro método invocado cuando se recibe un request, tendrá como argumentos el Request y Response de la petición actual.

Estos objetos implementan las populares interfaces PSR-7. La ruta de la aplicación Slim puede inspeccionar o manipular estos objetos según sea necesario. En definitiva, cada ruta de aplicación Slim DEBE devolver un objeto de respuesta PSR-7.

Muy bien, y como empiezo a usar Slim framework?

Instalación de Slim Framework

Requerimientos del Sistema

• Servidor Web con reescritura de URL

• PHP 7.1 ó superior

Paso 1: Instalar Composer

No tienes instalado Composer? Es sencillo de instalar, puedes ir a **pagina de descarga** de su web y seguir las instrucciones de instalación.

Paso 2: Instalar Slim Framework

Se recomienda instalar Slim Framework usando .

Sitúate en el directorio raíz del proyecto y ejecuta el siguiente comando:

composer require slim/slim:4.0.0

Este comando descarga Slim Framework y todas sus dependencias de terceros en la carpeta vendor de tu directorio raíz del proyecto.

Paso 3: Instalar una implementación de PSR-7 y ServerRequest Creator

Antes de ponerte en marcha con Slim Framework necesitas elegir una implementación PSR-7 que se adapte mejor a los requerimientos y necesidades de tu aplicación.

Para que la detección automática funcione y te permita usar AppFactory::create(…) y App::run(…) sin tener que crear manualmente un ServerRequest, es necesario instalar una de las siguientes implementaciones:

Slim PSR-7

composer require slim/psr7

Nyholm PSR-7 y Nyholm PSR-7 Server

composer require nyholm/psr7 nyholm/psr7-server

Guzzle PSR-7 y Guzzle HTTP Factory

composer require guzzlehttp/psr7 http-interop/http-factory-guzzle

Zend Diactoros

composer require zendframework/zend-diactoros

Paso 4: ¡Hello World!

<?php
use Psr\Http\Message\ResponseInterface as Response;
use Psr\Http\Message\ServerRequestInterface as Request;
use Slim\Factory\AppFactory;

require __DIR__ . '/../vendor/autoload.php';

$app = AppFactory::create();

$app->get('/', function (Request $request, Response $response, $args) {
    $response->getBody()->write("Hello world!");
    return $response;
});

$app->run();

Y con esto, ya tienes todo lo necesario para empezar a construir aplicaciones usando Slim Framework.

Recuerda que si tienes alguna sugerencia o pregunta, no dudes en dejar tus comentarios al final del post.

Si te gustó este post, ayúdame a que pueda servirle a muchas más personas, compartiendo mis contenidos en tus redes sociales.

Espero que este post haya sido de gran ayuda para ti, y como siempre, cualquier inquietud o duda que tengas, puedes contactarme por cualquiera de las vías disponibles, o dejando tus comentarios al final de este post. También puedes sugerir que temas o post te gustaría leer a futuro.

En este episodio quiero compartir contigo algunas herramientas que utilizo día a día para aumentar mi productividad.

Quizás algunas ya las conozcas pero para mí es un honor presentarte las que utilizo tanto en proyectos de trabajo como algunas otras para mi vida y planificación personal.

Acompáñame a escuchar este nuevo episodio y conocer un poco más sobre este interesante tema.

Lista de las 11 Herramientas para ser más productivos.

Gestión de Proyectos.

• Trello

• Asana

Meetings ó Comunicación

• Whereby.com (Antes appear.in)

• Jitsi

Creación de Diagramas

• Draw.io

• Canva

Gestión de Tiempos

• Clockify

• Pomodoro Tracker

• Forest

Aplicaciones para Notas

• Dash

Recuerda que si tienes alguna sugerencia o pregunta, no dudes en dejar tus comentarios al final del post.

Si te gustó este post, ayúdame a que pueda servirle a muchas más personas, compartiendo mis contenidos en tus redes sociales.

Espero que este post haya sido de gran ayuda para ti, y como siempre, cualquier inquietud o duda que tengas, puedes contactarme por cualquiera de las vías disponibles, o dejando tus comentarios al final de este post. También puedes sugerir que temas o post te gustaría leer a futuro.

El objetivo principal del patrón de diseño FACADE en PHP es el de simplificar nuestro sistema gracias a que permite exponer una interfaz mas amigable y fácil de digerir sin necesidad de conocer a fondo cada uno de los sub sistemas que se agrupan en esta “fachada”.

Para tratar de entender mejor el concepto, veamos un diagrama para visualizar mejor el patrón FACADE:

Aquí podemos ver que tenemos 3 subsistemas el cual son la clase Twitter, Instagram y Facebook, el cual cuya funcionalidad puede ser agrupada en la clase FACADE que hemos llamado: SocialNetworksClass quien posteriormente sera utilizada por cualquier clase de servicio.

Continuando con lo presentado en el diagrama, te muestro un ejemplo de código:

Ejemplo de implementación del Patrón de diseño FACADE en PHP

interface SocialNetworksInterface
{
    public function publish();
    public function follow();
    public function unfollow();
    public function addLike();
    public function retweet();
}

interface TwitterAPIClientInterface
{
    public function tweet();
    public function follow();
    public function unfollow();
    public function addLike();
    public function retweet();
}

interface InstagramAPIClientInterface
{
    public function publish();
    public function follow();
    public function unfollow();
    public function addLike();
}

interface FacebookAPIClientInterface
{
    public function addPost();
    public function addLike();
}

class SocialNetworks implements SocialNetworksInterface
{
    /**
     * @var TwitterAPIClientInterface
     */
    protected $twitterApiClient;

    /**
     * @var InstagramAPIClient
     */
    protected $instagramApiClient;

    /**
     * @var FacebookAPIClient
     */
    protected $facebookApiClient;

    public function __construct(
        TwitterAPIClientInterface $twitterApiClient,
        InstagramAPIClientInterface $instagramApiClient,
        FacebookAPIClientInterface $facebookApiClient
    ) {
    }

    public function publish()
    {
        $this->twitterApiClient->tweet();
        $this->instagramApiClient->publish();
        $this->facebookApiClient->addPost();
    }

    public function follow()
    {
        $this->twitterApiClient->follow();
        $this->instagramApiClient->follow();
    }

    public function unfollow()
    {
        $this->twitterApiClient->unfollow();
        $this->instagramApiClient->unfollow());
    }

    public function addLike()
    {
        $this->twitterApiClient->addLike();
        $this->instagramApiClient->addLike();
        $this->facebookApiClient->addLike();
    }

    public function retweet()
    {
        $this->twitterApiClient->retweet();
    }

}

class TwitterAPIClient implements TwitterAPIClientInterface
{
    public function tweet()
    {
        // tweet() method implementation
    }

    public function follow()
    {
        // follow() method implementation
    }

    public function unfollow()
    {
        // unfollow() method implementation
    }

    public function addLike()
    {
        // addLike() method implementation
    }

    public function retweet()
    {
        // retweet() method implementation
    }

}

class InstagramAPIClient implements InstagramAPIClientInterface
{
    public function publish()
    {
        // publich() method implementation
    }

    public function follow()
    {
        // follow() method implementation
    }

    public function unfollow()
    {
        // unfollow() method implementation
    }

    public function addLike()
    {
        // addLike() method implementation
    }

}

class FacebookAPIClient implements FacebookAPIClientInterface
{
    public function addPost()
    {
        // addPost() method implementation
    }

    public function addLike()
    {
        // addLike() method implementation
    }
}

El ejemplo que expongo es a manera ilustrativa de cómo implementar el patrón de diseño FACADE en tus proyectos.

En el ejemplo expuesto se puede apreciar como toda la funcionalidad de tres sub sistemas, Twitter, Facebook e Instagram, quedan envueltas en una clase FACHADA o FACADE.

Esto permite simplificar radicalmente la implementación de uno o varios sub sistemas en clases de servicios o en cualquier otro punto donde sea requerido.

Ademas que la clase que implementa nuestra clase FACADE no necesita saber internamente cómo funciona cada sub sistema.

Recuerda que si tienes alguna sugerencia o pregunta, no dudes en dejar tus comentarios al final del post.

Si te gustó este post, ayúdame a que pueda servirle a muchas más personas, compartiendo mis contenidos en tus redes sociales.

Espero que este post haya sido de gran ayuda para ti, y como siempre, cualquier inquietud o duda que tengas, puedes contactarme por cualquiera de las vías disponibles, o dejando tus comentarios al final de este post.

También puedes sugerir que temas o post te gustaría leer a futuro.

En este episodio titulado “ Costo por Tecnología vs Costo por Conocimiento “ quiero debatir un poco sobre el costo y valor de tu trabajo, es decir, el costo en base a la tecnología y el valor del conocimiento aplicado, dos factores importantes a la hora de ponerle precio a tu trabajo como desarrollador.

Doy mi punto de vista particular, es algo que opino sobre este tema que es super importante y que entre todos debemos poco a poco empujar para hacer que las empresas reflexionen sobre el valor y el costo de nuestro trabajo.

Acompáñame a escuchar este nuevo episodio y conocer un poco más sobre este interesante tema.

Recuerda que si tienes alguna sugerencia o pregunta, no dudes en dejar tus comentarios al final del post.

Si te gustó este post, ayúdame a que pueda servirle a muchas más personas, compartiendo mis contenidos en tus redes sociales.

Espero que este post haya sido de gran ayuda para ti, y como siempre, cualquier inquietud o duda que tengas, puedes contactarme por cualquiera de las vías disponibles, o dejando tus comentarios al final de este post. También puedes sugerir que temas o post te gustaría leer a futuro.

Puede ver la lista completa de funciones y novedades en la **página oficial de RFC.**

Aún cuando PHP 7.4 aumenta de forma notable el desempeño y mejora la forma en leer y entender el código, PHP 8 será la versión con más logros importantes en cuanto a rendimiento de PHP se refiere, ya que la propuesta para la **inclusión de JIT** ya ha sido aprobada actualmente. A tomar en cuenta…

Y para no extendernos mucho e ir al grano, haré un resumen sencillo de lo nuevo que trae esta versión 7.4 de PHP.

Arrow Functions en PHP 7.4

Esta actualización ha sido añadida a mi lista de favoritas para esta versión. ?

Arrow functions, también llamadas “ short closures “, permiten definir funciones one-liner menos verbosas.

Anteriormente hacíamos cosas como:

array_map(function (User $user) { 
    return $user->id; 
}, $users)

Ahora, podrás definir lo anterior como:

array_map(fn (User $user) => $user->id, $users)

Una sintaxis un poco parecida a como se hace en typescript :).

Adicionalmente, hay algunas notas acerca de los Arrow Functions:

• Ellas pueden acceder al ámbito principal sin necesidad de utilizar la palabra clave “use”.

• $this esta disponible como un closure normal.

• Pueden contender solo una linea, que también es la linea de retorno.

Typed Properties en PHP 7.4

Una de mis favoritas, algo que deseaba tener desde hace tiempo. ?

Ahora las propiedades pueden ser tipadas al igual que como ya se implementó con los argumentos de los métodos y funciones.

class User
{
    private int $id;

    private string $name;

    private int $age;

    private float $salary;
}

Consideraciones adicionales

class User
{
    private ?string $address = null;
}

Listado de tipados disponibles:

• bool

• int

• float

• string

• array

• iterable

• object

• ? (nullable)

• self & parent

• Classes & interfaces

Improved type variance en PHP 7.4

Esta es otra de mis favoritas!!!

Type variance propone poder usar tipos de retornos covariantes y argumentos contra variantes.

Esto significa que podremos definir el tipo de retorno de un método pero al ser implementado o sobre escrito por una clase, podemos variar el tipo de retorno. O en el caso de los argumentos de un método, podemos igualmente variarlo. Veamos un ejemplo:

Covariación de tipos de retorno

class ParentType {}
class ChildType extends ParentType {}

class A
{
    public function covariantReturnTypes(): ParentType
    { /* … */ }
}

class B extends A
{
    public function covariantReturnTypes(): ChildType
    { /* … */ }
}

Contravariación de argumentos

class ParentType {}
class ChildType extends ParentType {}

class A
{
    public function contraVariantArguments(ChildType $type)
    { /* … */ }
}

class B extends A
{
    public function contraVariantArguments(ParentType $type)
    { /* … */ }
}

Null coalescing assignment operator en PHP 7.4

El operador de coalescencia nos permitía de una forma corta, asignar un valor null en caso de que la primera condición no se cumpliera, ejemplo:

$variable = $this->getParameter('id') ?? null;

Ahora podremos resumirlo aún más usando:

$variable ??= $this->getParameter('id');

Array spread operator RFC

Ahora es posible usar el operador de propagación en arrays, veamos un ejemplo:

$arrayA = [1, 2, 3];

$arrayB = [4, 5];

$result = [0, ...$arrayA, ...$arrayB, 6 ,7];

//output will be..
[0, 1, 2, 3, 4, 5, 6, 7]

Esto solo funciona con arrays que contengan keys numéricos. Nota.

Numeric Literal Separator RFC

PHP 7.4 permite usar underscores o guiones bajos para visualmente separar valores numéricos, ejemplo:

$unformattedNumber = 107925284.88;

$formattedNumber = 107_925_284.88;

Los “_” serán ignorados por el motor de PHP.

Preloading

Otro de los features de bajo nivel es el precargado. Es una adición sorprendente al núcleo de PHP, lo cual puede resultar en una significante mejora de rendimiento.

En pocas palabras, si utilizas un framework, los archivos de clases y demás deben ser cargados y enlazados en cada petición. La Precarga le permite al servidor cargar los archivos PHP en memoria en el arranque, y luego ponerlos permanentemente disponibles para todas las peticiones posteriores.

La ganancia de rendimiento tiene, por supuesto, un costo: si se cambia la fuente de los archivos precargados, el servidor debe reiniciarse.

Custom object serialization

Dos nuevos métodos mágicos han sido añadidos para el release de esta versión: __serializey __unserialize. La diferencia entre estos metodos y __sleep y __wakeup es tan expuestas en el RFC discussed in the **RFC**.

Deprecations

Las siguientes funciones/funcionalidades serán deprecadas con PHP 7.4. para ver una lista más detallada puedes leer las notas de Actualización de PHP 7.4.

Estas son las novedades mas importantes que vendrán en noviembre, si quieres conocer más sobre lo que vendrá puedes echarle un ojo a este **link**.

Recuerda que si tienes alguna sugerencia o pregunta, no dudes en dejar tus comentarios al final del post.

Si te gustó este post, ayúdame a que pueda servirle a muchas más personas, compartiendo mis contenidos en tus redes sociales.

Espero que este post haya sido de gran ayuda para ti, y como siempre, cualquier inquietud o duda que tengas, puedes contactarme por cualquiera de las vías disponibles, o dejando tus comentarios al final de este post. También puedes sugerir que temas o post te gustaría leer a futuro.

Acompáñame en este nuevo episodio a conocer un poco mas sobre este tema y a mejorar día a día tus habilidades como programador web.

Recuerda que si tienes alguna sugerencia o pregunta, no dudes en dejar tus comentarios al final del post.

Si te gustó este post, ayúdame a que pueda servirle a muchas más personas, compartiendo mis contenidos en tus redes sociales.

Espero que este post haya sido de gran ayuda para ti, y como siempre, cualquier inquietud o duda que tengas, puedes contactarme por cualquiera de las vías disponibles, o dejando tus comentarios al final de este post. También puedes sugerir que temas o post te gustaría leer a futuro.