Laravel – Voyager : À consommer mais avec modération !

30/04/2018

Aucun commentaire

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
  • Gestion des rôles utilisateurs
  • Gestion des permissions
  • Gestion des médias
  • Gestion (basique) de pages
  • Gestion d’un ou plusieurs menus

 

Enfin, et surement la plus intéressante : le CRUD (Create / Read /Update / Delete) / BREAD (Browse / Read / Edit / Add / Delete)  Builder qui permet de créer une table en base de données avec tous les champs et leurs types, puis de générer toutes les actions d’ajout de mise à jour et de suppression pour chaque ligne dans le back office.  

 

 

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.

 

En clair !

 

Vous l’aurez compris Voyager est une bonne base de travail avec des fonctionnalités pré-développées intéressantes comme le CRUD Builder qui permettent de mettre en place rapidement une gestion basique métier, mais qui a une structure fermée où il est plutôt difficile d’ajouter des briques fonctionnelles compliquées, notamment en terme de droits utilisateurs.

 

Il est plus intéressant d’utiliser ce package dans des projets où les listing et la gestion des données restent simple, avec des formats de données basiques (pas de champ sérialisé, ..).

 

Enfin, je rappelle que cet article découle de notre expérience personnelle avec Voyager mais aussi grâce à d’autres outils que l’on utilise qui nous permettent d’avoir des points de comparaisons et finalement une vision sur son utilisation et ses limites, donc n’hésitez pas à commenter pour nous donner vos avis.

 

Dans le prochain article nous parlerons de Laravel Boilerplate ! Stay tunned ! 🙂