Laravel : Les solutions pour construire une base de travail commune et évolutive ?
Voyager : À consommer mais avec modération !
P’tit article pour commencer une suite sur un sujet qui nous concerne tous, développeurs, l'optimisation de notre temps de travail. En effet, hors cas exceptionnels, lorsque l’on fait un choix de techno qui débouche sur du Laravel, c’est pour des projets qui demandent ou demanderont des fonctionnalités complexes. Malgré tout, on retrouve toujours certaines étapes : par exemple dans le parcours utilisateur avec une phase de connexion / inscription et la plupart du temps un back-office. C’est pourquoi chez TroisPointZéro, nous avons testé (et nous continuerons de tester) plusieurs solutions pour à la fois gagner du temps sur des éléments répétitifs mais pour permettre aussi à chaque dev de pouvoir comprendre / reprendre le code de son collègue sans perdre 10 jours à appréhender l’arborescence du Laravel mise en place. Vous l’aurez compris, le but de cette série d’articles sera de vous faire découvrir les packages / solutions que nous avons testé dans un cadre d’optimisation et de définition d'une base de développement solide. Pour ce premier article, je vais vous présenter Laravel Voyager, qui est le premier package que l’on a utilisé dans un but d’optimisation, ainsi que le cadre du projet et enfin les côtés ‘black and white’ du package. A savoir que cet article n’a pas vocation à dire si le package est bien ou non - chacun se fera son avis - mais de vous aiguiller sur son utilisation.Pourquoi Voyager ?
Pour répondre à cette question, je me dois de vous expliquer (très) rapidement le cadre du projet : projet d'application mobile d’où un besoin de générer des APIs avec une part complexe côté métiers (beaucoup de tables, de relations, multilingue, …) et gestion complète ou presque des données par les admins (Back office complexe).
Notre choix s’est donc logiquement tourné vers Laravel, ce qui tombait très bien car nous avions Voyager dans le viseur.
A consommer …
Pour commencer, Voyager s’installe via composer donc pas de système de repository privée avec utilisation de clé etc... D’ailleurs, je ne l’ai pas mentionné mais Voyager est gratuit ! Bonne nouvelle ! Je vous laisse lire la documentation pour les détails mais on se retrouve avec ceci :
On retrouve les fonctionnalités principales :
- Accès au back office complet : inscription / connexion / mot de passe oublié
- Flat design
- Ergonomie : très simpliste qui permet une compréhension des ‘admins clients’ très rapide
- La gestion des rôles utilisateurs
- Le contrôle des permissions
- La gestion des médias
- Le contrôle (basique) de pages
- La gestion d’un ou plusieurs menus
A première vue tout ça est idyllique, sur le coup j’avais l’impression d’avoir un Wordpress sous Laravel et je me vois déjà en vacances plus tôt avec mon cocktail en main … mais bon, vous l’aurez compris tout ne s’est pas passé comme prévu :)
… mais avec modération !
On arrive au stade où il faut ajouter les briques fonctionnelles et notamment sur les droits utilisateurs : c’est LE point faible de Voyager. En effet, pour personnaliser ces droits, il y a 2 solutions, soit :- Créer le controller ET la vue from scratch où il sera compliqué de faire ressembler la vue au design globale du BO car les vues de Voyager ont des variables obligatoires qui sont générées via ses propres controllers (hiérarchie)
- Publier et dupliquer les controllers pour pouvoir les utiliser, c’est la solution que nous avons choisie sur notre projet , ce qui nous a obligé à récupérer du code ‘core’ de Voyager pour pouvoir faire nos modifications de droit, ce qui reste partiellement propre, car si un jour nous avons besoin d’upgrade la version de Voyager et que l’un des bouts de code que l’on a dupliqué est modifié, cela nous demandera des adaptations sur plusieurs controllers.
