Laravel et Symfony : notre point de vue !

François, concepteur développeur chez Oniti vous expose le point de vue de l’agence sur ces deux frameworks PHP

En développement PHP, il existe de nombreux frameworks. Laravel & Symfony sont deux outils qui ont impacté l’histoire d’Oniti.

Disclaimer : Cet article ne représente en aucun cas une vérité absolue ou un avis arrêté. Il s’agit plutôt de l’histoire des besoins de l’agence qui nous ont amené d’un framework à l’autre.

Laravel & Symfony : deux écoles pour l’écriture en PHP

Ces deux noms originaux représentent deux boîtes à outil pour développeur utilisant le langage PHP. Symfony est le leader sur le marché et est très reconnu notamment grâce à son écosystème de formation. Une majorité de développeurs l’utilisent. Comme tout outil efficace, il demande une rigueur de code à l’utilisation (qui peut être soit un avantage soit un inconvénient selon les profils). Lors de gros projets où tout le monde fonctionne de la même manière, il s’agit d’un excellent outil qui permet à un développeur de facilement reprendre le travail d’un autre. Une majorité de SSII utilisent Symfony pour leurs projets PHP : ils ont d’ailleurs tous un module dédié à ce framework dans leurs formations. En bref, on peut résumer que Symfony est “une Grosse Bertha bien rodée où tout est formalisé”.

Laravel séduit quant à lui par la grande liberté d’organisation du code qu’il propose. À la base un simple fork de Symfony (une copie de Symfony modifiée), chez Oniti on a trouvé son écriture très intuitive. L’absence de YAML nous a également séduit : largement utilisé par Symfony, ce type de données sont ardues à maintenir. Si Laravel est la boîte à outil qui s’occupe du back-end (la partie invisible pour l’utilisateur), notre choix s’est porté sur React pour gérer le  front-end sur nos applications.

handicap au travail

Laravel + React, un choix historique pour l’agence

Attention : à partir de ce point, l’article sera sensiblement plus technique.

Chez Oniti on a décidé de fonctionner avec API + client JavaScript (React). Dans ce contexte, nous avons fait le choix de Laravel.

Voici ce qui nous a motivé à passer de Symfony à Laravel :

La simplicité d’écriture

À l’agence, la manière d’écrire de Laravel (façades, middlewares…) nous parle davantage que Symfony .

Notre prise en main de Laravel nous a permis de nous familiariser fortement sa méthode d’écriture. Etant donné que nous n’avons pas de turn over en ce qui concerne les devs, nous n’avons pas besoin du cadre de Symfony : on capitalise sur nos compétences Laravel.

L’architecture et les notions similaires à Symfony

Laraval étant un fork de Symfony, les architectures et les notions sont à la base très similaires entre les deux frameworks. Sa façon d’effectuer des tâches complexes sans montrer la redondance des formats nous a fait un véritable effet “waouh”.

L’abondance des helpers et des outils de Laravel aident à l’architecture de nos projets : cela nous fait gagner énormément de temps (système de validation, helpers pour les path) !

La mise en place d’une API

Sur Laravel nous estimons que la mise en place d’une API est bien plus simplifiée que sur Symfony qui oblige d’installer davantage d’éléments. Laravel est nativement conçu pour faire de l’API, là où sur Symfony ce n’est pas inné.

Pour Symfony 4 voici les étapes pour mettre en place une API :

  1. Installer les dépendances nécessaires
  2. Configurer les dépendances préalablement installées
  3. Taguer la route comme étant de l’API
  4. Écrire le code correspondant

Plus d’infos : https://symfony.com/doc/master/bundles/FOSRestBundle/index.html

En ce qui concerne Laravel 5.8, voici la marche à suivre :

  1. Aucune dépendance à installer : Laravel sais répondre nativement en json
  2. Déclarer sa ressource
  3. Créer le code dans le controller

Plus d’infos : (cf Route::resource ) https://laravel.com/docs/5.8/controllers

La communication avec la base de données (Eloquent VS Doctrine)

Eloquent est utilisé par Laravel, Doctrine par Symfony. Doctrine nécessite 2 lignes de code complètes pour récupérer les données, Eloquent n’en demande qu’une.

Exemple Symphony 4 :

$repository = $this->getDoctrine()->getRepository(Product::class);
$product = $repository->find($id);

On passe toujours par un repository qu’on doit récupérer avant.

Documentation :  https://symfony.com/doc/current/doctrine.html

Pour Laravel 5.8 :

$product = Product::find($id);

Le routing

En Laravel on a un seul fichier qui centralise toutes les routes et permet de les gérer comme on veut. En Symfony, il faut parcourir plusieurs fichier pour trouver la route qui nous intéresse.

Mise en place de middleware plus simple

Mettre en place un middleware en Symfony 4 :

  1. Déclarer les paramètres dans le service.yaml
  2. Créer une interface vide (qui servira à taguer le controller)
  3. Implémenter l’interface sur le ou les controllers souhaités
  4. Créer un EventSubscriber
  5. Rattacher cet event sur l’événement correspondant avant les appels controller
  6. Créer le code de votre Middleware dans l’EventSubscriber

Documentation : https://symfony.com/doc/current/event_dispatcher/before_after_filters.html

En Laravel 5.8 :

  1. Créer un Middleware exemple  (php artisan make:middleware CheckAge)
  2. Définir le code du middleware
  3. Déclarer le middleware
  4. Rattacher le middleware sur la ou les routes souhaités

Documentation : https://laravel.com/docs/5.8/middleware

handicap au travail

L’agilité et Laravel+React, un combo que nous apprécions

 

Les deux frameworks décrits dans cet article sont excellents. Leurs caractéristiques demandent aux développeurs de faire un choix en fonction de leurs projets et de leur organisation. À nos yeux, Symfony convient particulièrement aux larges entreprises et agences qui ont besoin d’une méthode institutionnelle pour gérer un grand nombre de développeurs. La rigueur imposée par ce framework devient alors un véritable atout.

Pour les petites agences comme Oniti, la liberté proposée par Laravel et son concept conviennent particulièrement à leurs besoins de souplesse et de gestion de projets agiles. Notre utilisation de Laravel nous a permis de créer une solution permettant de monter un projet vierge en très peu de temps. C’est cette même liberté du code qui nous mène à davantage de rigueur. Nous avons donc opté pour un outil souple cadré par la rigueur de notre travail ! Loin d’être des convertis prêchant pour leur paroisse, notre choix de framework PHP est actuellement Laravel. Nous nous donnons la liberté de changer à tout moment si nos besoins évoluent.

Voici donc l’histoire de notre choix technologique, nous serons ravis d’en discuter avec vous en commentaire ou sur nos réseaux sociaux. En attendant, voici les documentations respectives de Symfony et de Laravel.