Service Providers en Laravel (primera parte)

¿Por qué usar Service Providers?

Laravel es un framework que nos facilita el desarrollo de aplicaciones web.

Usar Laravel es muy sencillo. Sin embargo, si queremos entender realmente cómo funciona o cuál es la filosofía que sigue, es importante comprender 2 conceptos (service container y service provider).

• Laravel como framework usa un «contenedor de servicios» y unos «proveedores de servicios» siempre que necesita iniciar una instancia de una aplicación Laravel.
• No solo nuestras aplicaciones, sino también los servicios que conforman el núcleo de Laravel, se inician gracias a los service providers.
• Los service providers se encargan de toda la configuración necesaria antes de empezar a usar un servicio. Dependiendo del servicio que se va a iniciar, el proveedor se encarga de crear nuevas instancias y posiblemente las relaciones con otros servicios (definir parámetros, oyentes de eventos, middlewares, rutas).

La creación de nuevos paquetes para el framework Laravel requiere conocer bien estos conceptos.

¿Cómo usar Service Providers?

Más adelante, en este artículo, vamos a ver cómo crear nuestro propio service provider.

De momento, un breve adelanto:

• El archivo config/app.php presente en los proyectos Laravel, contiene un arreglo llamado providers.
• Este arreglo es un listado de todos los service providers que serán cargados en nuestra aplicación. Cada service provider es una clase.
• No todos los proveedores son cargados cuando nuestra aplicación resuelve una petición. Muchos de ellos son cargados únicamente cuando se requieren.

¿Cuándo usar Service Providers?

Cuando desarrollamos una aplicación muy puntual, generalmente tenemos secciones bastante simples, donde basta con validar y registrar datos. En estos casos no es necesario usar Service Providers.

Sin embargo, hay aplicaciones que van más allá de registrar datos. Por ejemplo:

• Cuando debemos subir y procesar documentos de texto (.txt, .pdf, .doc, .docx).
• Cuando debemos enviar notificaciones, de distintos tipos (vía email, sms, push notifications).
• Cuando debemos subir y procesar imágenes (distintos tamaños, diversas transformaciones, variedad de formatos).
• Cuando debemos generar reportes de distintos tipos, aplicando una serie de filtros.

En estos casos, tenemos muchas formas de hacer nuestra implementación.

• Podemos usar como base un paquete ya existente.
• Podemos escribir nuestra propia lógica.
• O podemos combinar el uso de distintos paquetes y nuestros propios algoritmos según se requiera.

Entonces, dependiendo de la magnitud del problema a resolver, hemos de optar por «crear un servicio que resuelva fácilmente nuestras necesidades«.

• Si la solución que hemos encontrado es breve, y se usa en un único lugar, podemos optar por crear un método (en la clase donde se necesite y eso será suficiente).
• Si la solución es muy breve, no requiere de una configuración inicial, y debe usarse en distintos lugares, podemos definir un helper (una función que estará disponible en todo nuestro proyecto).
• Sin embargo, si la solución requiere de una configuración inicial (depende de otras clases, y requiere parámetros específicos), lo más recomendable es crear un service provider (un proveedor, para que se encargue de la configuración de este servicio, y nosotros simplemente lo usemos).

¿Qué necesitamos?

En este artículo:

• Primero vamos a ver (de forma general), qué es el service container de Laravel.
• Cómo crear un service provider en nuestro proyecto Laravel.
• Y finalmente, cómo registrar y usar este service provider.

A modo de ejemplo, el servicio que nos interesa, va a estar relacionado con lo siguiente:

• «Estoy» desarrollando una aplicación para postular a ofertas de empleo.
• Los postulantes pueden subir sus CV al momento de postular si no lo hicieron antes.
• Pero también pueden actualizar sus CV desde su perfil en cualquier momento.
• Y los administradores pueden subir CVs en lote sin la necesidad de asociar estos a un usuario determinado.

(Hipotéticamente) ya he desarrollado la funcionalidad para subir archivos CV en lote.

• Subir hojas de vida no consiste en almacenar archivos de forma local.
• El archivo se debe subir a un bucket de S3 y su ubicación depende del formato.
• Se debe extraer el texto del documento e indexarlo a una base de datos para agilizar el proceso de búsqueda (esto también depende del formato del documento).

Lo bueno es que ya funciona para la subida en lote. Pero, repetir código, a fin de tener la misma funcionalidad en distintas secciones de la aplicación, no es adecuado.

• Entonces vamos a crear un proveedor de servicios que inicialice por nosotros el servicio de nuestro interés.
• Un método extenso dentro de un controlador, que hace uso de distintas clases pasará a ser un servicio de fácil uso.

Si estás siguiendo este artículo y ya has pensado en cómo aplicar estos conceptos. Mi sugerencia es la siguiente:

• Primero refactoriza el código que ya tienes, y asegúrate de no perder ninguna funcionalidad.
• Luego usa el servicio en otras secciones, o desarrolla nuevas características.

No es imposible implementar nuevas características mientras se refactoriza. Pero no es recomendable.

Te esperamos en los siguientes artículos en donde hablaremos mas acerca de estos temas, los cuales hoy en día son de vital importancia en el mundo de la tecnología.