Backpack for Laravel: qué es, cómo lo encontré y por qué entré a la comunidad

Hace algunos años, creo que 2012 o 2013, descubrí Laravel, un framework de PHP que poco a poco iba popularizándose. Debo reconocer que en ese momento sólo miré algunas de sus características, pero me contuve de utilizarlo, porque no podía confiar en un paquete que embebía en él tanta responsabilidad: la estructura de control, la autogeneración de archivos y el control de sesión de usuario, todo junto.

Claro, siempre que la fobia sale a flote se debe a una muy mala experiencia. Me costaba confiar en los autogeneradores de código porque hace muchos más años atrás alguna vez usé Dreamweaver de Adobe, y debo decir que me dejó traumado. Posteriormente me certifiqué en .NET y fue el mismo caso: si bien su IDE autogenera interfaces con drag & drop, el código que va quedando tras ello es una carnicería con poca higiene. Hace mucho tiempo no desarrollo en .NET, por eso creo que hoy todo eso debe estar subsanado de varias maneras.

Volviendo a Laravel, no le di oportunidad de convencerme, me negué a usarlo por los puntos anteriores y seguí programando con control total de cada línea de código de los proyectos que desarrollábamos como equipo.

Cuando ya no se podía seguir ignorando

Pasaron los años y la popularidad de Laravel explotó, ya me era imposible ignorar ese framework del que todos hablaban, entonces me dispuse a instalarlo para probarlo. Debo reconocer que lo odiaba, tenía demasiadas acciones muy encapsuladas y eso significaba para mí entregarle el control a otro. No puedo vivir sin controlar mis desarrollos, jaja.

Pasaron los días y este framework comenzó a conquistar poco a poco mi gusto por el uso de frameworks. Dada la experiencia que traigo conmigo no me era difícil entender los conceptos que implementaba, y poco a poco fui dominando los métodos y combinándolo con otros paquetes para más funciones.

Llegó un momento en el que decidí probarlo para un proyecto real y quedé sumamente sorprendido por la aceleración que aportó al desarrollo. El scaffold que incluye ayuda demasiado, el código se mantenía bien estructurado y aportaba un gran apoyo para el debugging. Avanzando ya con el proyecto me dije, si esto autogenera código, ¿por qué no autogenera módulos completos? Si la mayoría de los CRUD son un estándar muy básico: listar, agregar, modificar y borrar. Entonces comenzó mi aventura en buscar un paquete que hiciera esto.

Los que probé antes

Son decenas o cientos los paquetes que autogeneran módulos CRUD, los hay desde los que apoyan la parte visual hasta los que por comandos levantan la estructura básica. Sólo mencionaré algunos de los que probé.

Voyager. No me gustó. Es un CMS que entrega herramientas visuales para generar módulos nuevos, pero no aporta demasiado control a las acciones, las validaciones y las estructuras en general. Si eres aficionado a la programación y quieres experimentar con algo que te ayude a generar módulos de manera fácil, este paquete te puede ayudar, pero de igual manera debes saber instalar Laravel, usar composer y de ser necesario montar y configurar un servidor web.

Laravel Generator, de InfyOm. Un paquete simple, me gustó. Apoyaba bien en autogenerar código desde un archivo json que contenía la estructura del migration, y te generaba explícitamente la estructura completa del CRUD; desde ahí tú aportabas todo tipo de detalles extra. Eso sí, si querías agregar campos nuevos tenías que comenzar el proceso de nuevo o controlar tú los cambios, lo que deja fuera el uso del archivo json. Por eso es sumamente importante tener la estructura de las tablas casi completa al inicio.

Comienza mi amor con Laravel y los autogeneradores de CRUDs

Como seguía con los experimentos, llegué a Backpack, lo instalé y me enamoré de la estructura simple y en general limpia que tenía.

Tuve que formatear mis conocimientos de los paquetes anteriores, porque este en general no autogenera archivos, sino que lo hace en línea: toma la información del migration y genera el CRUD, pero on the fly. Desde ahí, mediante métodos, puedes agregar, ocultar o eliminar campos. Si necesitas filtros para la lista, los incluye; si necesitas un campo para subir archivos, lo incluye; si necesitas trabajar con una tabla personalizada, lo incluye; si necesitas un campo que no existe, lo creas y lo agregas al paquete; si requieres cambiar la interfaz base, publicas las vistas y las cambias. Toda función común y otras no tan comunes van contenidas en el paquete.

Si bien para uso comercial no es gratis, la licencia vale todo el ahorro de tiempo que genera, y de igual manera se puede probar gratis, y si el proyecto no tiene fines comerciales se puede usar sin problemas.

Mi grano de arena

Hace algunas semanas estaba jugando con Backpack y creando un campo personalizado que tuviera todas las funciones de un invoice. Comencé editando el campo tabla que trae el paquete, y me causó gracia que de todo el proyecto fuera el único archivo que usara Angular. Le comenté ese detalle a un compañero de trabajo.

Pasaron las semanas y él me envía un issue de GitHub del paquete, donde el creador agrega a la lista “migrar campo tabla de Angular a jQuery”, porque no existía razón alguna para usar Angular y la migración natural debía ser desde jQuery a Vue.js en un futuro. Mi compañero me recordó que era lo mismo que yo había dicho algunas semanas antes, y yo le respondí que haría el cambio como aporte si tuviera tiempo.

Mientras iba camino a mi casa me puse a pensar en una frase de la serie Dark, donde dicen algo así como “tú no tienes al tiempo, el tiempo te tiene a ti”, la cual me marcó tanto que cuando llegué hice un fork del proyecto. Como conozco jQuery hace tantos años y lo domino bastante bien, me puse manos a la obra y en unas 2 o 3 horas realicé el cambio de librería, además de mantener totalmente la estructura de datos existente, es decir, quienes usaran el campo anterior con Angular no debían hacer ningún cambio para operar con el campo jQuery que programé.

Tuve que recuperar mi contraseña de GitHub, porque nunca la uso: en el ámbito laboral uso Bitbucket. Una vez hecho el commit realicé mi primer Pull Request al issue que el autor había abierto, y luego de algunas horas recibo la notificación de que mi aporte había sido aprobado y harían el merge a la versión 4.

Lo que aprendí de esas tres horas

La barrera nunca fue técnica. El cambio lo hice en una tarde, con una librería que domino hace años, sobre un issue que el propio autor ya había abierto y priorizado. Lo único que me faltaba era recuperar una contraseña y decidir que valía la pena.

Durante años vi el open source como algo que hacía otra gente, gente con más tiempo o con más nivel, y resulta que el aporte que terminó en la versión 4 del paquete salió de una molestia que ya había dicho en voz alta y que había dejado ahí.

Bienvenido al equipo

Como consecuencia de mi aporte directo a la comunidad del proyecto fui invitado como miembro de la organización Backpack for Laravel, donde somos 179 miembros que aportan con el desarrollo del paquete.

Si tienes una molestia con una herramienta que usas todos los días, revisa si ya existe el issue abierto. En mi caso existía, y llevaba semanas esperando a alguien que tuviera un par de horas.