Contratos – Documentación de Laravel 6

Introducción

Los Contratos de Laravel son un conjunto de interfaces que definen los servicios principales proporcionados por el framework. Por ejemplo, un contrato Illuminate\Contracts\Queue\Queue define los métodos necesarios para las colas de trabajo, mientras que el contrato Illuminate\Contracts\Mail\Mailer define los métodos necesarios para el envío de correos electrónicos.

Cada contrato tiene una implementación correspondiente provista por el framework. Por ejemplo, Laravel proporciona una implementación de cola con una variedad de conductores (drivers), y una implementación de envío de correo electrónico que funciona con SwiftMailer.

Todos los contratos de Laravel residen en su repositorio de GitHub propio. Esto proporciona un punto de referencia rápido para todos los contratos disponibles, así como un paquete único y desacoplado que puede ser utilizado por los desarrolladores de paquetes.

Ver post

Facades – Documentación de Laravel 6

Introducción

Las Facades proveen una interfaz «estática» a las clases disponibles en el contenedor de servicios de la aplicación. Laravel viene con numerosas facades, las cuales brindan acceso a casi todas las características de Laravel. Las facades de Laravel sirven como «proxies estáticas» a las clases subyacentes en el contenedor de servicios, brindando el beneficio de una sintaxis tersa y expresiva, manteniendo mayor verificabilidad y flexibilidad que los métodos estáticos tradicionales.

Todas las facades de Laravel se definen en el namespace Illuminate\Support\Facades. Entonces, podemos fácilmente acceder a una facade de esta forma:

use Illuminate\Support\Facades\Cache;

Route::get('/cache', function () {
    return Cache::get('key');
});

A través de la documentación de Laravel, muchos de los ejemplos usarán facades para demostrar varias características del framework.

Cuándo usar facades

Las Facades tienen múltiples beneficios. Brindan una sintaxis tersa y memorizable que permite utilizar las características de Laravel sin tener que recordar nombres de clase largos que deben ser inyectados o configurados manualmente. Además, debido a su uso único de los métodos dinámicos PHP, son fáciles de probar.

Sin embargo, deben guardarse ciertas precauciones al hacer uso de facades. El peligro principal de las facades es la corrupción de alcance de clases. Como las facades son tan fáciles de usar y no requieren inyección, puede resultar fácil dejar que tus clases sigan creciendo y usar muchas facades en una sola clase. Usando inyección de dependencias, este potencial es mitigado por la retroalimentación visual que un constructor grande te da cuando tu clase está creciendo demasiado. Entonces, al usar facades, pon especial atención al tamaño de tu clase para que su alcance de responsabilidades permanezca limitado.

Cuando se construye un paquete de terceros que interactúa con Laravel, es mejor inyectar contratos de Laravel en vez de usar facades. Como los paquetes son construidos fuera de Laravel, no tendrás acceso a las funciones (helpers) de testing para facades de Laravel.

Ver post

Proveedores de Servicios – Documentación de Laravel 6

Introducción

Los proveedores de servicios son la parte central del inicio básico de una aplicación Laravel (bootstrapping). Tu propia aplicación, así como todos los servicios principales de Laravel son iniciados rápidamente usando proveedores de servicios.

Pero, ¿qué queremos decir por «inicio básico (bootstrapped)»? En general, nos referimos a registrar cosas, incluyendo registrar enlaces de contenedores de servicios, listeners de eventos, middleware e incluso rutas. Los proveedores de servicios son el lugar principal para configurar tu aplicación.

Si abres el archivo config/app.php incluido con Laravel, verás un arreglo providers. Estas son todas las clases de proveedores de servicios que serán cargados por tu aplicación. Observa que muchos de éstos son proveedores «diferidos», lo que significa que no serán cargados en cada solicitud, sino sólo cuando los servicios que proporcionan sean necesarios.

En este resumen aprenderás a escribir tus propios proveedores de servicio y registrarlos en tu aplicación de Laravel.

Escribiendo proveedores de servicios

Todos los proveedores de servicios extienden de la clase Illuminate\Support\ServiceProvider. La mayoría de los proveedores de servicio contienen un método register y boot. Dentro del método register, debes enlazar cosas sólo al contenedor de servicios. Nunca debes tratar de registrar ningún listener de eventos, rutas o cualquier otra pieza de funcionalidad dentro del método register.

La línea de comandos Artisan puede generar un nuevo proveedor mediante el comando make:provider:

php artisan make:provider RiakServiceProvider

Ver post

Contenedor de servicios – Documentación de Laravel 6

Introducción

El contenedor de servicios de Laravel es una herramienta poderosa para administrar dependencias de clases y realizar inyección de dependencias. La inyección de dependencias es una frase bonita para básicamente decir: las dependencias de clases son «inyectadas» en la clase mediante el constructor o, en algunos casos, métodos «setter».

Demos un vistazo a un ejemplo sencillo:

<?php

namespace App\Http\Controllers;

use App\Http\Controllers\Controller;
use App\Repositories\UserRepository;
use App\User;

class UserController extends Controller
{
    /**
    * The user repository implementation.
    *
    * @var UserRepository
    */
    protected $users;

    /**
    * Create a new controller instance.
    *
    * @param  UserRepository  $users
    * @return void
    */
    public function __construct(UserRepository $users)
    {
        $this->users = $users;
    }

    /**
    * Show the profile for the given user.
    *
    * @param  int  $id
    * @return Response
    */
    public function show($id)
    {
        $user = $this->users->find($id);

        return view('user.profile', ['user' => $user]);
    }
}

En este ejemplo, UserController necesita retornar usuarios desde un origen de datos. Así que, inyectaremos un servicio que sea capaz de retornar los usuarios. En este contexto, nuestro UserRepository probablemente use Eloquent para retornar la información de los usuarios desde la base de datos. Sin embargo, dado que el repositorio es inyectado, seremos capaces de cambiarlo fácilmente con otra implementación. También seremos capaces de «simular» o crear una implementación de ejemplo de UserRepository al probar nuestra aplicación.

Un conocimiento profundo del contenedor de servicios de Laravel es esencial para construir aplicaciones grandes y poderosas así como también contribuir al núcleo de Laravel.

Enlaces

Ver post

Ciclo de vida de la solicitud – Documentación de Laravel 6

Introducción

Al usar cualquier herramienta en el «mundo real», te sientes más cómodo si entiendes cómo funciona esa herramienta. El desarrollo de aplicaciones no es diferente. Cuando entiendes cómo funcionan tus herramientas de desarrollo, te sientes más cómodo y seguro usándolas.

El objetivo de este documento es darte un buen resumen sobre cómo funciona el framework Laravel. Al conocer mejor el framework, todo lo demás se siente menos «mágico» y te sentirás más cómodo construyendo tus aplicaciones. Si no entiendes todos los términos de una sola vez, ¡no te desesperes! Sólo trata de obtener una comprensión básica de lo que está sucediendo y tus conocimientos crecerán a medida que explores otras secciones de la documentación.

Resumen del ciclo de vida

Lo primero

El punto de entrada para todas las solicitudes a una aplicación de Laravel es el archivo public/index.php. Todas las solicitudes son dirigidas a este archivo por la configuración de tu servidor web (Apache / Nginx). El archivo index.php no contiene mucho código. En su lugar, es un punto de partida para cargar el resto del framework.

El archivo index.php carga la definición de autocarga generada por Composer, y luego retorna una instancia de la aplicación de Laravel desde el script bootstrap/app.php. La primera acción tomada por Laravel es crear una instancia de la aplicación / contenedor de servicios.

Ver post

Despliegue – Documentación de Laravel 6

Introducción

Una vez que estés listo para hacer deploy de tu aplicación de Laravel a producción, deberías considerar algunos aspectos importantes para hacer que tu aplicación se ejecute de la forma más eficientemente posible. En este documento, vamos a cubrir muy buenos puntos para hacer que tu aplicación de Laravel sea desplegada correctamente.

Configuración del servidor

Nginx

Si estás haciendo deploy de tu aplicación hacia un servidor que está ejecutando Nginx, puedes utilizar el siguiente archivo de configuración como punto de inicio para configurar tu servidor web. Principalmente, este archivo tendrá que ser personalizado dependiendo de la configuración de tu servidor. Si deseas asistencia en la administración de tu servidor, considera utilizar un servicio como Laravel Forge:

server {
    listen 80;
    server_name example.com;
    root /example.com/public;

    add_header X-Frame-Options "SAMEORIGIN";
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Content-Type-Options "nosniff";

    index index.html index.htm index.php;

    charset utf-8;

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

    location = /favicon.ico { access_log off; log_not_found off; }
    location = /robots.txt  { access_log off; log_not_found off; }

    error_page 404 /index.php;

    location ~ \.php$ {
        fastcgi_pass unix:/var/run/php/php7.2-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        include fastcgi_params;
    }

    location ~ /\.(?!well-known).* {
        deny all;
    }
}

Optimización

Ver post

Estructura de Directorios – Documentación de Laravel 6

Introducción

La estructura por defecto de aplicación de Laravel está pensada para proporcionar un buen punto de inicio para aplicaciones grandes y pequeñas. Pero, eres libre de organizar tu aplicación como quieras. Laravel no impone casi ninguna restricción sobre dónde una clase es ubicada – siempre y cuando Composer pueda cargar automáticamente la clase.

¿Donde está el directorio de modelos?

Al comenzar con Laravel, muchos desarrolladores son confundidos por la falta de un directorio models. Sin embargo, la falta de dicho directorio es intencional. Encontramos la palabra «models» ambigua dado que significa muchas cosas diferentes para muchas personas. Algunos desarrolladores se refieren al «modelo» de una aplicación como la totalidad de toda su lógica de negocio, mientras que otros se refieren a los «modelos» como clases que interactúan con una base de datos relacional.

Por esta razón, elegimos ubicar los modelos de Eloquent por defecto en el directorio app y permitir al desarrollar ubicarlos en algún otro sitio si así lo eligen.

Directorio Raíz

Directorio App

El directorio app contiene el código principal de tu aplicación. Exploraremos este directorio con más detalle pronto; sin embargo, casi todas las clases en tu aplicación estarán en este directorio.

Directorio Bootstrap

El directorio bootstrap contiene el archivo app.php que maqueta el framework. Este directorio también almacena un directorio cache que contiene archivos generados por el framework para optimización de rendimiento como los archivos de caché de rutas y servicios.

Directorio Config

El directorio config, como el nombre implica, contiene todos los archivos de configuración de tu aplicación. Es una buena idea leer todos estos archivos y familiarizarte con todas las opciones disponibles para ti.

Directorio Database

El directorio database contiene las migraciones de tu base de datos, model factories y seeders. Si lo deseas, puedes también usar este directorio para almacenar una base de datos SQLite.

Directorio Public

El directorio public contiene el archivo index.php, el cual es el punto de acceso para todas las solicitudes que llegan a tu aplicación y configura la autocarga. Este directorio también almacena tus assets, tales como imágenes, JavaScript y CSS.

Directorio Resources

El directorio resources contiene tus vistas así como también tus assets sin compilar tales como LESS, Sass o JavaScript. Este directorio también almacena todos tus archivos de idiomas.

Directorio Routes

El directorio routes contiene todas las definiciones de rutas para tu aplicación. Por defecto, algunos archivos de rutas son incluidos con Laravel: web.php, api.php, console.php y channels.php.

El archivo web.php contiene rutas que RouteServiceProvider coloca en el grupo de middleware web, que proporciona estado de sesión, protección CSRF y encriptación de cookies. Si tu aplicación no ofrece una API sin estado, todas tus rutas probablemente serán definidas en el archivo web.php.

El archivo api.php contiene rutas que RouteServiceProvider coloca en el grupo de middleware api, que proporcionan limitación de velocidad. Estas rutas están pensadas para no tener estado, así que las solicitudes que llegan a la aplicación a través de estas rutas están pensadas para ser autenticadas mediante tokens y no tendrán acceso al estado de sesión.

El archivo console.php es donde puedes definir todos los comandos de consola basados en Closures de tu aplicación. Cada Closure está enlazado a una instancia de comando permitiendo una forma simple de interactuar con los métodos de entrada y salida de cada comando. Aunque este archivo no define ninguna ruta HTTP, sí define puntos de entrada en consola (rutas) a tu aplicación.

El archivo channels.php es donde puedes registrar todos los canales de transmisión de eventos que tu aplicación soporta.

Directorio Storage

El directorio storage contiene tus plantillas compiladas de Blade, sesiones basadas en archivos, archivos de caché y otros archivos generados por el framework. Este directorio está segregado en los directorios app, framework y logs. El directorio app puede ser usado para almacenar cualquier archivo generado por tu aplicación. El directorio framework es usado para almacenar archivos generados por el framework y caché. Finalmente, el directorio logs contiene los archivos de registros de tu aplicación.

El directorio storage/app/public puede ser usado para almacenar archivos generados por el usario, tales como imágenes de perfil, que deberían ser accesibles públicamente. Debes crear un enlace simbólico en public/storage que apunte a este directorio. Puedes crear el enlace usando el comando php artisan storage:link.

El Directorio Tests

El directorio tests contiene tus pruebas automatizadas. Una prueba de ejemplo de PHPUnit es proporcionada. Cada clase de prueba debe tener el sufijo Test. Puedes ejecutar tus pruebas usando los comandos phpunit o php vendor/bin/phpunit.

Directorio Vendor

El directorio vendor contiene tus dependencias de Composer.

Directorio App

La mayoría de tu aplicación está almacenada en el directorio app. Por defecto, este directorio está regido por el espacio de nombre App y es cargado automáticamente por Composer usando el estándar de autocarga PSR-4.

El directorio app contiene una variedad de directorios adicionales tales como Console, Http y Providers. Piensa en los directorios Console y Http como si proporcionaran una API al núcleo de tu aplicación, pero no contienen lógica de la aplicación como tal. En otras palabras, son dos formas de emitir comandos a tu aplicación. El directorio Console contiene todos tus comandos de Artisan, mientras que el directorio Http contiene tus controladores, middleware y solicitudes.

Una variedad de otros directorios serán generados dentro del directorio app cuando uses los comandos make de Artisan para generar clases. Así que, por ejemplo, el directorio app/Jobs no existirá hasta que ejecutes el comando de Artisan make:job para generar una clase job.

Muchas de las clases en el directorio app pueden ser generadas por Artisan mediante comandos. Para ver los comandos disponibles, ejecuta el comando php artisan list make en tu terminal.

Directorio Broadcasting

El directorio Broadcasting contiene todas las clases de canales de broadcast de tu aplicación. Estas clases son generadas usando el comando make:channel. Este directorio no existe por defecto, pero será creado para ti cuando crees tu primer canal. Para aprender más sobre canales, revisa la documentación sobre broadcasting de eventos.

El Directorio Console

El directorio Console contiene todos los comandos personalizados de Artisan para tu aplicación. Estos comandos pueden ser generados usando el comando make:command. Este directorio también almacena el kernel de tu consola, que es donde tus comandos personalizados de Artisan son registrados y tus tareas programadas son definidas.

Directorio Events

Este directorio no existe por defecto, pero será creado para ti por los comandos de Artisan event:generate y make:event. El directorio Events almacena clases de eventos. Los eventos pueden ser usados para alertar a otras partes de tu aplicación que una acción dada ha ocurrido, proporcionando una gran cantidad de flexibilidad y desacoplamiento.

Directorio Exceptions

El directorio Exceptions contiene el manejador de excepciones de tu aplicación y también es un buen lugar para colocar cualquier excepción lanzada por tu aplicación. Si te gustaría personalizar cómo las excepciones son mostradas o renderizadas, debes modificar la clase Handler en este directorio.

Directorio Http

El directorio Http contiene tus controladores, middleware y form requests. Casi toda la lógica para manejar las solicitudes que llegan a tu aplicación serán colocadas en este directorio.

Directorio Jobs

Este directorio no existe por defecto, pero será creado para ti si ejecutas el comando de Artisan make:job. El directorio Jobs almacena las colas de trabajos para tu aplicación. Los trabajos pueden ser encolados por tu aplicación o ejecutados sincrónicamente dentro del ciclo de vida actual de la solicitud. Los trabajos que son ejecutados sincrónicamente durante la solicitud actual son algunas veces referidos como «comandos» dado que son una implementación del patrón de comandos.

Directorio Listeners

Este directorio no existe por defecto, pero será creado para ti si ejecutas los comandos de Artisan event:generate o make:listener. El directorio Listeners contiene las clases que manejan tus eventos. Los listeners de eventos reciben una instancia de evento y realizan la lógica en respuesta al evento siendo ejecutado. Por ejemplo, un evento UserRegistered puede ser manejado por un listener SendWelcomeEmail.

Directorio Mail

Este directorio no existe por defecto, pero será creado para ti si ejecutas el comando de Artisan make:mail. El directorio Mail contiene todas tus clases que representan correos electrónicos enviados por tu aplicación. Los objetos de correo te permiten encapsular toda la lógica para construir un correo en una única y sencilla clase, que puede ser enviada usando el método Mail::send.

Directorio Notifications

Este directorio no existe por defecto, pero será creado para ti si ejecutas el comando de Artisan make:notification. El directorio Notifications contiene todas las notificaciones «transaccionales» que son enviadas por tu aplicación, tales como notificaciones sencillas sobre eventos que ocurren dentro de tu aplicación. Las características de notifcaciones de Laravel abstrae el envío de notificaciones sobre una variedad de drivers como email, Slack, SMS o almacenadas en la base de datos.

Directorio Policies

Este directorio no existe por defecto, pero será creado para ti si ejecutas el comando de Artisan make:policy. El directorio Policies contiene las clases de las políticas de autorización de tu aplicación. Las políticas son usadas para determinar si un usuario puede realizar una acción dada contra un recurso. Para más información, revisa la documentación sobre autorización.

Directorio Providers

El directorio Providers contiene todos los proveedores de servicios para tu aplicación. Los proveedores de servicios maquetan tu aplicación al enlazar servicios en el contenedor de servicios, registrando eventos o realizando cualquier otra tarea para preparar tu aplicación para solicitudes entrantes.

En una aplicación de Laravel nueva, este directorio ya contendrá algunos proveedores. Eres libre de agregar tus propios proveedores a este directorio según sea necesario.

Directorio Rules

Este directorio no existe por defecto, pero será creado para ti si ejecutas el comando de Artisan make:rule. El directorio Rules contiene los objetos para las reglas de validación personalizadas de tu aplicación. Las reglas son usadas para encapsular lógica de validación complicada en un simple objeto. Para más información, revisa la documentación sobre validación.

Laravel Valet – Documentación de Laravel 6

Introducción

Valet es un entorno de desarrollo minimalista de Laravel para Mac. No requiere de Vagrant ni de modificar el archivo de configuración /etc/hosts. Incluso permite compartir tus sitios a través de túneles locales. Sí, también nos gusta

Laravel Valet configura tu Mac para que siempre inicie el servicio de Nginx en segundo plano al iniciar tu computadora. Después, usando DnsMasq, Valet actuará como servidor proxy, procesando todas las peticiones en el dominio *.test apuntando a los sitios instalados en tu máquina local.

En otras palabras, es un entorno de desarrollo de Laravel sorprendentemente rápido y solamente utiliza cerca de 7MB de RAM. Laravel Valet no está pensado para ser un reemplazo de Vagrant o Homestead, en su lugar presenta una alternativa flexible y rápida, lo cual es una buena opción para quienes tengan una cantidad limitada de RAM.

Por defecto, Valet brinda soporte para las siguientes tecnologías, pero no está limitado a sólo ellas:

Además, es posible extender Valet con tu propio driver personalizado.

Ver post

Laravel Homestead – Documentación de Laravel 6

Introducción

Laravel se ha esforzado en hacer que toda la experiencia del desarrollo de PHP sea placentera, incluyendo el entorno de desarrollo local. Vagrant provee una manera simple y elegante de administrar y aprovisionar máquinas virtuales.

Laravel Homestead es el box de Vagrant pre-empaquetado oficial que brinda un maravilloso entorno de desarrollo sin la necesidad de que tengas que instalar PHP, un servidor web, ni ningún otro software de servidor en tu máquina local. ¡Basta de preocuparte por estropear tu sistema operativo! Los boxes de Vagrant son completamente desechables. Si algo sale mal, simplemente puedes destruir y volver a crear el box en cuestión de minutos.

Homestead puede ejecutarse en sistemas Windows, Mac y Linux e incluye Nginx, PHP, MySQL, PostgreSQL, Redis, Memcached, Node y todas las demás herramientas que necesitas para desarrollar aplicaciones de Laravel sorprendentes.

Si estás utilizando Windows, puede que necesites habilitar la virtualización por hardware (VT-x). Usualmente puede habilitarse en el BIOS. Si estás utilizando Hyper-V en un sistema UEFI puede que requieras también deshabilitar Hyper-V para poder acceder a VT-x.

Ver post

Configuración – Documentación de Laravel 6

Introducción

Todos los archivos de configuración para el framework Laravel están almacenados en el directorio config. Cada opción está documentada, así que no dudes en consultar los archivos y familiarizarte con las opciones disponibles para ti.

Configuración del entorno

A menudo es útil tener diferentes valores de configuración basados en el entorno en el que se ejecuta la aplicación. Por ejemplo, es posible que desees utilizar localmente un driver de caché diferente del que quieras usar en un servidor para producción.

Para hacer esto sencillo, Laravel utiliza la librería de PHP DotEnv por Vance Lucas. En una nueva instalación de Laravel, el directorio raíz de tu aplicación contendrá un archivo .env.example. Si instalas Laravel por medio de Composer, este archivo será renombrado automáticamente a .env. De lo contrario, deberás renombrar el archivo manualmente.

Tu archivo .env deberá omitirse en el sistema de control de versiones de tu aplicación, ya que cada desarrollador / servidor que usa tu aplicación puede requerir una configuración de entorno diferente. Además, esto sería un riesgo de seguridad en caso de que un intruso obtenga acceso al repositorio de control de versiones de tu aplicación, ya que cualquier credencial confidencial se expondría.

Si estás desarrollando con un equipo, es posible que desees continuar incluyendo el archivo .env.example en tu aplicación. Al poner valores de ejemplo (placeholder) en el archivo de configuración .env.example, otros desarrolladores en tu equipo podrán ver claramente cuáles variables de entorno se necesitan para ejecutar tu aplicación. También puedes crear un archivo .env.testing. Este archivo sobrescribirá el archivo .env al ejecutar pruebas con PHPUnit o al ejecutar comandos de Artisan con la opción --env=testing.

Cualquier variable en tu archivo .env puede ser anulada por variables de entorno externas tales como variables de entorno de nivel de servidor o de nivel de sistema.

Ver post

Suscríbete a nuestro boletín

Te enviaremos publicaciones con consejos útiles y múltiples recursos para que sigas aprendiendo.

Suscríbete a nuestro boletín

Recibe consejos útiles, promos y múltiples recursos directamente en tu correo.

Tu nombre y correo serán enviados directamente a MailChimp. No compartiremos tus datos con otras empresas.