Laravel y el Service Layer

Laravel y Service layer

Recientemente me tope con este termino aplicado a Laravel. Al aprender Laravel desde su documentación te da una guía recomendada y funcional de como usarla de una manera exitosa. Sin embargo su eslogan es:

The PHP Framework for Web Artisans

https://laravel.com/

El framework para artesanos Web. Entonces debemos tomar la documentación como una guía y nada más. El resto esta en nuestras manos de artesanos.

Aquí entra el paso extra del service layer. El proceso de un request http en grandes rasgos es así:

Ahora con el service layer sería así

La idea es separar la parte de la lógica del controlador, logrando así tener responsabilidades únicas en cada elemento, el controlador solo tendrá la tarea de llamar a los elementos necesarios y retornar resultados, convirtiéndose es solo un mensajero, manteniendo una arquitectura de software limpia y fácil de mantener.

Service layer es un patrón de diseño que nos permite no repetir código. Permite abstraer la lógica cuando necesitas usar la lógica con diferentes front end. Permite abstraer la lógica de la aplicación a un servicio común.

Ejemplo

Sin service layer

UsersController.php

<?php

namespace App\Http\Controllers;

use App\User;
use Illuminate\Http\Request;

class UsersController extends Controller
{
     public function create(Request $request){
           $validator = $this->validate($request->all(), [...]);

         User::create([
        'email' => $request->get('email'),
        'name' => $request->get('name'),
        'password' => $request->get('password')
    ]);

        return redirect('users')->with('user', $user);
     }
}

Con service layer

CreateUserService.php

public function make(Request $request)
{
   $user = User::create([
     'email' => $request->get('email'),
     'name' => $request->get('name'),
     'password' => $request->get('password')
   ]);
   return $user; 
}

UsersController.php. Inyecta en el nuevo servicio en el constructor.

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

public function store(Request $request)
{
    $this->CreateUserService->make($request);

    return back()->with(['success' => 'Congratulations!']);
}

Así que ahora sabes, puedes crear usuarios desde diferentes lados, por ejemplo un API y un frontend tradicional con blade. O hasta en proyectos con multiples dominios con ui limitadas o diferentes. Ante cualquier cambio solo tendrás que actualizar tu servicio.

El Vue js más util, Laravel Inertia + Vue JS

Yo aprendi a programar usando vanilla JS y jquery, me convertí un gran fan de jquery. Luego surgieron estos frameworks de frontend, angular, react js, vue, svelte, etc. Y cada año surgen nuevos.

Mi primer acercamiento con esto fue un: pero que necesidad de complicar esto, con jquery ya lo hubiera terminado. Porque al inicio había que hacer muchas cosas para hacerlo correr, aparte de la curva de aprendizaje, el paso inicial era raro y complicado.

Para iniciar no era solo incluir un script tag como jquery, literal copias y pegas una linea y ahí esta jquery listo para usar. Necesitaba utilizarlo con npm, más webpack, más un main.js. Claro luego descubrí que si habían mas opciones, que no solo era webpack, y que si habían script tag para angular, etc.

Esta semana me tope con un curso de Platzi sobre Inertia + Vue Js, aplicaciones single page. Era corto y me pareció interesante pues no conocía Inertia.

The Inertia stack provided by Jetstream uses Vue.js as its templating language. Building an Inertia application is a lot like building a typical Vue application; however, you will use Laravel’s router instead of Vue router. Inertia is a small library that allows you to render single-file Vue components from your Laravel backend by providing the name of the component and the data that should be hydrated into that component’s «props».

https://jetstream.laravel.com/1.x/stacks/inertia.html

En resumen Inertia provee una stack para usar vue js template junto a Laravel pero le quita toda la complejidad extra y excesiva (a mi gusto) de las redes en frontend. Permite usar las rutas de laravel ya establecidas y permite enviar parámetros desde php cómo props a las paginas de Vue js.

Esto te da todas las ventajas de Vue js, componentes, reactividad, velocidad, acceso a plugins desarrollados por la comunidad, documentación, etc, etc. Pero con el sistema ordenado y funcional de Php + Laravel. Reduce el tiempo de desarrollo de un api para comunicar frontend con backend. Permite ser una aplicación completamente funcional unificada. Permitiendo un approach fullstack completamente funcional.

Claro, para gustos hay colores, dime que piensas tú de inertia + vue js.

Código limpio, esencial pero ¿limpio para quién?

Si eres un desarrollador habrás escuchado esta frase varias veces, debemos hacer código limpio. Pero no les parece que un adjetivo como limpio, es subjetivo?

Es obvio (y si no es obvio para ti probablemente no te ha tocado leer código malo, feo, espaguethi o como le quieran llamar) que se necesita crear, editar actualizar código que sea legible y que sea fácil de entender.

Todos estamos en contra de las variables llamadas a, b, cdpTraxddo peor. De métodos o funciones que tienen a cientos de lineas, entrelazadas, mal nombradas, con código duplicado.

Un proyecto grande llegara al punto de: mejor gastar recursos y tiempo en iniciar desde cero que arreglar lo malo. Es un problema tan real como que los cerdos no vuelan. Y las repercusiones de estos problemas son enormes, imagina decirle al cliente todo tu dinero y tiempo invertido en este proyecto inservible fue desperdiciado, no podemos salvar tu inversión o tu negocio. Imagina ese momento en el que le das la noticia a alguien a quien le has cobrado miles de dólares, al que le prometiste ese software que resolvería todos sus problemas, que sería escalable, que le daría retorno de inversión, que resolvería la paz mundial, y pues, … ya no sirve, mejor deséchelo.

La importancia de esto no es cuestionable, es algo necesario y que todos los desarrolladores deberíamos saberlo como base. Si bien es cierto que no hay una regla absoluta de que es el código limpio, todos sabemos lo que es mal código. Los siguientes consejos los doy de mi lectura del libro Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin).

  • Ley de LeBlacn: Despues es igual a nunca. Cualquier cosa que pienses «luego lo hago» se traduce a que nunca lo haras. Surgiran nuevos bugs, te asignaran nuevas cosas, y tu deuda tecnica ira aumentando. Haz algo al respecto.
  • La lógica debe ser directa.
  • El código debe ser especifico y no especulativo.
  • Preocuparse por la legibilidad, prestar atención a los detalles.
  • No tener duplicados, cuando algo se repite es una señal que tenemos una idea que no terminamos de representar correctamente.
  • Que el método o objecto no haga mas de una cosa. Similar la S de los principios SOLID. Cada elemento tiene una y solo responsibilidad.
  • El código debe ser evidente, sencillo y atractivo, que cuente una historia, de principio a fin.
  • Ley del boy scout: dejar el campamento mas limpio de lo que se ha encontrado.
  • Cuando se ve código malo, no es necesario refactorar todo, empieza por cambios pequeños, cambiar de nombre a una variable, separar un método en otros métodos mas especificos.

 

Con esto terminaría la parte 1 de una serie de post hablando sobre este tema.

¿Cuál crees que es la importancia del código limpio? Déjame tu opinión abajo.

 

 

LinkedIn
Share
Instagram
WhatsApp