PHP a été l’un des premiers langages de programmation que j’ai découvert. Nous sommes en 2005, je suis encore étudiant, et ce langage est le plus populaire pour réaliser des sites web dynamique. Le hic, c’est qu’au cours des années suivantes, m’étant spécialisé en Java et en Python, j’entendais de plus en plus de critiques envers le PHP… Et pour principale cause, le langage a tardé à être orienté objet !! Et beaucoup d’autres développeurs, tout comme moi, étaient novices en programmation lorsqu’ils ont découvert le PHP. Donc inutile de vous dire qu’à cette époque là, nous n’étions pas au top en terme de “best practices”…
Depuis, les choses ont beaucoup évoluées, le langage est aujourd’hui dans sa version 7.4 (en stable), et de nombreux frameworks permettent désormais de structurer proprement son code et de développer rapidement. En tout cas, c’est ce que j’entends très régulièrement. Alors j’ai récemment décidé de redécouvrir le PHP, et en particulier un des frameworks Open Source très connu : Laravel.
Exposer des APIs, “finger in the nose”
Je souhaite développer un back-end exposant des APIs. En me basant sur les technologies que j’utilise régulièrement, la tâche ne semble pas insurmontable.
En Python, j’utilise généralement le micro-framework Flask, qui permet, en quelques lignes, d’initialiser un projet équivalent à celui que je souhaite mettre en place.
En Java, j’utilise l’incontournable SpringBoot qui, comme Flask, permet de mettre en place les premières briques d’un back-end très rapidement.
Sauf que… je ne vais utiliser aucun de ces 2 langages ! L’objectif est bel et bien d’exposer ces APIs en PHP…
Cette fois, c’est parti !
Je vous passe les détails liés à l’installation de PHP et de Composer (gestionnaire de dépendances pour PHP). J’imagine toutefois vos réactions : “Ahh oui, il part de loin quand même…”.
Je me rends donc sur le site web de Laravel pour télécharger le framework, et en savoir un peu plus sur son utilisation… Et là, première bonne surprise, il faut reconnaître que le site est clair, bien structuré, la documentation est très riche. C’est un point que je trouve très positif car il est toujours frustrant de galérer pour trouver des informations [justes] concernant un framework.
Première frustration…
Après l’installation de Laravel sur mon poste, je tape la commande suivante :
laravel new twu
Et c’est tout. Mon projet “twu” est créé.
Mon ressenti en découvrant le projet, est plutôt mitigé. D’un côté, je trouve le projet bien structuré, mais d’un autre côté, je me dis que le projet est déjà bien [trop] fourni, alors même que je n’ai pas encore écrit une seule ligne de code. En creusant, on se rend compte que Laravel, à la création du projet, fourni tout un tas de chose très intéressantes, mais qui ne me sont pas forcément utiles.
Par exemple, à la racine, il y a les fichiers package.json, ou encore webpack.mix.js qui ne servent qu’aux utilisateurs de Laravel qui souhaitent faire du front-end. Or, ce n’est pas du tout mon cas.
Prenons également l’exemple du répertoire config, je souhaite effectivement configurer ma base de données et mes envois d’emails, et c’est du coup très intuitif de le faire dans les fichiers database.php et mail.php présents dans ce répertoire. Mais un tas d’autres fichiers ne me servent absolument à rien (queue.php, view.php, logging.php, etc…).
Dernier exemple, le répertoire resource contient un sous-répertoire views, dans lequel plusieurs fichiers me sont, là encore, inutiles. Il s’agit de fichiers ayant l’extension .blade.php, utilisés par le moteur de templating de Laravel (vous l’aurez deviné, il s’appelle Blade). Mais étant donné que je ne renvoie aucune “vue”, j’ai supprimé tous ces fichiers. Il est d’ailleurs à noter que la suppression de ces fichiers ne m’a posé aucun problème, ce n’est pas le cas pour d’autres éléments que j’ai supprimé par la suite. Notamment suite à la suppression du répertoire database/factories, mon projet ne se lançait plus…
J’aurais aimé avoir la possibilité, à la création du projet, de choisir les modules que je souhaite inclure dans celui-ci, via une CLI, un peu comme ce que propose JHipster (projet Open Source fournissant des squelettes de projets, avec la possibilité de choisir les modules à y inclure). D’ailleurs, en parlant de CLI, penchons-nous maintenant sur Artisan.
La découverte d’Artisan
Artisan est un composant basé sur la Console de Symfony (autre framework PHP, également très populaire). Ce composant permet d’effectuer un certain nombre d’actions, comme par exemple la génération de fichiers, comme les Controlleurs, les Models, les Middleware ou encore les fichiers de tests.
Là où je trouve Artisan très pratique, c’est pour la gestion des migrations en base de données. Par le passé, j’ai eu l’occasion d’utiliser Flyway, qui permet lui aussi de gérer des migrations de base de données, mais il fallait l’ajouter à mon projet Java “manuellement”, le configurer en environnement de développement, puis en production. Avec Artisan, aucune configuration à faire, ça fonctionne directement, et il faut dire que l’outil est très efficace et extrêmement facile à prendre en main.
Voici quelques unes des commandes Artisan que j’utilise déjà très régulièrement :
php artisan serve => pour lancer le serveur web
php artisan key:generate => commande à lancer une seule fois
php artisan migrate => mettre à jour la structure de ma BDD
php artisan make:exception => génère une « custom exception »
php artisan make:controller => génère un Controlleur
La mise en place de mes routes
Maintenant que j‘ai compris l’arborescence du projet, que j’ai lancé mes premières commandes Artisan, et que mon projet démarre correctement, je me lance dans le développement de ma plateforme (outil de suivi des formations en présentiel et diffusion des contenus post-formation).
Assez rapidement, je me penche sur la question de la sécurité. Je souhaite sécuriser mon application via un JWT (Json Web Token). Mon application sera donc StateLess. Deux possibilités s’offrent à moi :
- JWT-Auth, qui est de loin le projet le plus utilisé pour mettre en place du JWT dans l’environnement Laravel. Il est plutôt simple, et la communauté autour de ce projet est conséquente.
- Laravel Passport, qui présente le gros avantage d’être conçu par l’équipe de développement de Laravel. Il faut dire que ça m’inspire confiance…
Je choisi donc d’utiliser Laravel Passport, car il est très simple, et il permettra de mettre en place très facilement du OAuth2 dans le futur, si besoin est. En quelques commandes Artisan, le tour est joué !
php artisan passport:install => installation de Passport
php artisan passport:client –personal => génération des clés
Les routes sont ensuite très simples à sécuriser. Voici un extrait du fichier api.php :
Route::prefix(‘v1’)->group(function () {
Route::post(‘/signup’, ‘Auth\SignupController@signup’);
Route::post(‘/login’, ‘Auth\LoginController@login’); Route::middleware([‘auth:api’, ‘verified’])->group(function () {
Route::get(‘/users/me’, ‘UserController@show’);
});
});
Ainsi, j’admets volontiers que la mise en place de mes routes, ainsi que la sécurisation de l’application se font facilement grâce à Laravel et Passport. Par ailleurs, plusieurs Middleware sont également présents dans l’application dans le but de la sécuriser (par exemple le fichier VerifyCsrfToken.php).
Finalement, ce n’est pas si mal…
À ce stade, je suis déjà obligé de reconnaître que Laravel permet effectivement de développer des applications rapidement et simplement. N’ayant jamais travaillé par le passé sur de “vrais” projets PHP, j’ai pu mettre en place, en quelques heures seulement, un back-end structuré et sécurisé, exposant des APIs REST. Fini les classes PHP comme j’ai connu à mes débuts (contenant du HTML, du CSS, du PHP, du JavaScript, du SQL, et tout ça dans le même fichier s’il vous plait !!!!).
Je ne vais pas m’attarder sur l’ORM Eloquent, car il fonctionne de manière similaire aux autres ORM avec lesquels j’ai eu l’occasion de développer. Je pense en particulier à SQLAlchemy (Python) et Spring Data (Java). Il est tout de même à noter que le système de Seed est très pratique avec Eloquent (insertion de données en base à l’initialisation de celle-ci). Il n’y a donc plus de raison d’insérer malencontreusement des doublons en initialisant sa base de données.
Autant Blade ne m’est d’aucune utilité dans le cadre de l’exposition de mes APIs, autant ce moteur de templating est pratique pour mes templates de mail. Par le passé, j’ai beaucoup utilisé Velocity, mais une fois de plus, le coté “tout en un” de Laravel ne me laisse pas indifférent car il n’y a aucune configuration à faire pour utiliser Blade.
Les alternatives à Laravel
La dernière question que je me pose est : “aurais-je pu utiliser un autre framework PHP ?”. La réponse est “probablement”, mais comme à chaque fois, tout dépend de ce que l’on souhaite mettre en place.
Pour ma part, Laravel fait très bien le travail, tout comme l’aurait également fait Symfony. Mais ce dernier est encore plus lourd que Laravel, donc une partie de ses modules, là encore, ne m’auraient pas servi. Par ailleurs, la courbe d’apprentissage de Symfony est plus longue, car Laravel se focalise sur la simplicité du code pour le développeur. Ne crachons tout de même pas dans la soupe : Symfony est un très bon framework (de réputation), et n’oublions pas que Laravel est composé de certains éléments provenant de Symfony !
Une autre alternative très sérieuse : Lumen. Ce micro-framework est basé sur Laravel, et répond en grande partie à mon souhait de ne pas avoir pleins de choses dans mon application qui ne me servent à rien. En effet, Lumen contient principalement le système de routing, et quelques petites fonctionnalités en plus. Et c’est tout.
Donc oui, Lumen aurait pu faire l’affaire. L’inconvénient (forcément, il y en a un…), c’est que j’aurais été obligé de configurer pas mal de choses par moi-même, comme par exemple la gestion des envoies d’email, alors qu’avec Laravel, je n’ai rien eu à faire, mis à part taper une commande Artisan.
En conclusion
L’expérience de développer une application dans un langage que je n’ai pas utilisé depuis plusieurs années n’est finalement pas traumatisante, bien au contraire. Le PHP a beaucoup évolué ces dernières années, dans le bon sens.
Simple, facile, efficace… Les promesses de Laravel sont, d’après-moi, tout à fait tenues.
