Logo Oniti pour les supports mobiles

Laravel et Symfony : notre point de vue  !

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.

François Concepteur développeur

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

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

Laravel é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 :

  • Installer

    •  Les dépendances nécessaires

  • Configurer

    • Les dépendances préalablement installées

  • Taguer

    • La route comme étant de l’API

  • Écrire

    • Le code correspondant

Plus d’infos : https://symfony.com/doc/master/bundles/FOSRestBundle/index.html
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);
Julien et Hugo s'extasient devant un écran d'ordinateur

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.

Nous avons donc opté pour un outil souple cadré par la rigueur de notre travail !

Silhouette de panneaux se détachant sur fond de couché de soleil.

16 réponses

  1. Oui, je suis d’accord, Laravel est bien plus souple et agréable à utiliser au quotidien. (On peut citer également la facilité d’utiliser blade par rapport à Twig, l’intégration de laravel-mix pour les assets à faire en node.)
    Mais, par contre, je ne suis pas sur qu’il soit un fork de Symfony. Je dirais plutot qu’il s’agit d’un framework basé sur Symfony, car on voit encore bcp de dépendances dans le core.
    Mais bon, ca reste un détail.
    Merci pour l’article 🙂

    Répondre

      1. Laravel n’est ni un fork, ni basé sur Symfony. Cela ne l’a jamais été. Laravel utilise des packages agnostiques de Symfony parmi d’autres. La philosophie est différente, la conception est différente. Je vous remercie de ne pas créer des légendes urbaines.

        Répondre

  2. Quelques erreurs :

    1) Les API :
    – Symfony gère nativement les réponses json avec JsonResponse depuis la version 2.2
    – il n’est plus nécessaire d’utiliser JMS Serializer depuis un bout de temps maintenant que le composant natif Serializer est aussi rapide et propose les mêmes fonctionnalités
    – FOSRest n’est qu’un maigre composant vieillissant pour faire des API, c’est API Platform qui a pris le relais depuis quelques années, une simple annotation sur une classe permet de la transformer en ressource API

    2) Doctrine :
    – depuis Symfony 3.4, l’autowiring permet d’injecter directement dans les contrôleurs des services, or tous les repositories sont des services. Il suffit donc de passer le repository ProductRepository en paramètre du contrôleur et d’exécuter la méthode find.
    – le pattern utilisé par Laravel est Active Record qui a beaucoup de faiblesses notamment un fort couplage entre les entités et la base de données, ce qui ne devrait pas être le cas. Doctrine 1 fonctionnait comme ça et Doctrine 2 s’est volontairement séparé d’Active Record pour éviter les problèmes liés à cette manière de faire.

    3) Routing :
    – ce n’est pas une obligation avec Symfony d’utiliser les annotations ou éparpiller des fichiers yaml de routing. Il est possible de créer un seul fichier yaml contenant toutes les routes de l’application.
    – avec un outil de dévelppement comme PhpStorm et le plugin Symfony installé, il suffit de CTRL+clic sur la route dans un fichier twig par exemple pour être redirigé sur le contrôleur correspondant.
    – les invokable controllers dans Symfony permettent aussi de mieux séparer le code et d’obtenir une meilleure architecture ADR, avec une classe par action.

    —

    Concernant Laravel, c’est un monstre de mauvaises pratiques qui incite à créer du code difficile à maintenir avec des patterns d’un autre âge qui font rouler les yeux (façades, active record…).
    Symfony est certainement plus complexe à appréhender mais si quelque chose prend du temps avec, c’est simplement que ce n’est pas la bonne façon de faire.

    Bonne continuation.

    Répondre

    1. J’oubliais :

      4) Les middleware :
      – en Symfony, ce n’est pas le bon terme, et inutile d’implémenter le PSR-15 pour obtenir un middleware. Il faut utiliser pour ça les Kernel Events https://symfony.com/doc/current/reference/events.html
      – créer un EventSubscriber ne nécessite aucune configuration dans services.yaml, et peut intercepter un événement avec un niveau de priorité personnalisable
      – de la même façon qu’avec le pattern middleware, les objets Event sont passés d’un listener/subscriber à un autre dans le sens décroissant de priorité

      Répondre

      1. Bonjour Julien, merci pour votre commentaire riche en informations ! Notre article dépeint un choix que nous avons fait il y a déjà deux ans. Certaines formulations présentes dans le blog sont plus précises du côté de Laravel que chez Symfony : il s’agit de notre outil de tous les jours ! Nous utilisons Symfony bien plus rarement et nous les comparions à l’instant “T”.
        Concernant les “mauvaise pratiques” de Laravel, je pense avant tout que cela dépend de l’environnement dans lequel nous travaillons. Aujourd’hui chez Oniti, nous nous retrouvons parfaitement dans la vision globale de Laravel qui nous permet une plus grande efficacité.
        Je vous souhaite une bonne continuation et serais ravi d’en discuter davantage avec vous. Si vous le souhaitez, contactez moi à francois@oniti.fr

        Répondre

  3. Bonjour,

    Pas tout à fait vrai. Doctrine permet également en une seule ligne de récupérer une ressource :

    $doctrine->find(Product::class, 1); // récupère le produit #1.
    Seulement pour réaliser une récupération plus complexe, il faudra passer par le repository. C’est sa fonction première.

    Répondre

    1. Bonjour Erwan, une fois le repository ou $doctrine initialisé il ne faut plus qu’une seul ligne, tout à fait. Les façades Laravel permettent de s’affranchir de cette ligne, c’est un des aspect qui nous a séduit.

      Répondre

  4. Bonjour
    merci pour ce petit comparatif et résumé des 2 frameworks. Pour pratiquer les 2 , je suis d’accord avec vous : LARAVEL beaucoup plus simple, plus productif, que SYMFONY. Et donc cela signifie projets livrés plus vite, à moindre coût. Je ne comprends pas pourquoi toujours un tel engouement pour SF en France…. suffit de faire un rapide google trend sur ces 2 frameworks pour se rendre compte que Laravel a pris le dessus partout dans le monde. Ce n’est tout de même pas le hasard.

    Et j’oubliais : j’apprécie particulièrement la gestion de la sécurité, particulièrement agréable à manager avec Laravel.

    Dominique

    Répondre

    1. Déjà, j’ai utilisé les deux frameworks. Symfony est plus complexe et respecte beaucoup plus de bonnes pratiques avec une POO beaucoup plus rigoureuse. De plus la documentation de Symfony est bonne et plus lisible comparé à Laravel. Sur Laravel la documentation d’une notion tient sur une page alors que sur Symfony est elle beaucoup plus organisé avec des liens vers des pages pour approfondir.
      Symfony est bloquant, une erreur entraine forcément une exception contrairement à Laravel ou certaines erreurs dans la vue Blade n’entrainent pas d’exceptions. Symfony est fait pour des gros projets et pour les parano du bon code. AAvec Laravel il est beaucoup plus aisé de coder comme on veut.
      De même, avec la CLI de Symfony, on voit d’avance que c’est du lourd avec des commande beaucoup plus avancées que celle de laravel.
      Pour quelqu’un qui prend son temps pour apprendre je lui conseille Symfony, il va apprendre la POO et voit à quel point on peut faire de belle chose et écrit un bon code. En revanche, je dirai ou j’irai jusqu’à dire qu’avec Laravel, quelqu’un qui ne connait pas grande chose à la POO ou au fonctionnement d’une application web peut faire du Laravel du moment qu’il connait le PHP.
      La vue Twig de Symfony est facile, complète (avec plein de fontionnalités) et fait pour des projets simples comme complexes tandis que Blade est assez basique.

      En gros, Laravel a simpliié beaucoup de choses avec des techniques tels que les facades et les helpers : on a l’impression d’utiliser que des fonctions et méthodes statiques ; ce qui facilite la tâche pour les novices alors que Symfony est beaucoup plus orienté rigueur avec donc un tout petit peu plus difficile au départ

      Répondre

      1. Merci pour votre retour.
        En effet Laravel est plus accessible, mais pour moi il est tout a fait adapter a de gros projets, tout est une question d’organisation, la rigueur qu’il n’impose pas doit faire l’objet de choix de code dans l’équipe.

        Répondre

  5. Symfony est toujours le meilleur, c’est un open source, ce qui est un bon avantage. On n’a donc pas de contraintes imposées et on peut développer des solutions propriétaires. Symfony est considéré comme un des framework PHP les plus puissants et les plus flexibles.

    Répondre

    1. Je développe sous Symfony depuis bientôt 3 ans (Symfony 2, Symfony 3, Symfony 4 et Symfony 5 récemment) et j’ai fait à peu près, le tour, si je puis dire, dans le fonctionnement de base et la logique dédiée (dans le sens où on a des managers, des repositories, etc.). En revanche, issu d’une formation type BTS & licence professionnelle, j’ai toujours autant de mal avec Doctrine qui est « couche applicative » avant « couche base de données », ce qui est à mes yeux une aberration compte tenu des problèmes de perf (rien ne vaut une vue et une procédure stockée). Et je ne parle pas des perf calamiteuses dès lors qu’on a un projet assez volumineux. J’avoue être intéressé par Laravel, car il y a « la base de données avant le reste » dans la logique de gestion et de persistance des données.

      Vous parlez, pour certains, des mauvaises pratiques sous Laravel (je commence à peine une formation sur Udemy) et je suis désolé, mais le code, majoritairement présent sur Stackoverflow et même, sur 2 des 3 jobs que j’ai fait, est littéralement moche, pas optimisé et, si je puis dire, aberrant. J’applique du mieux que je peux les principes théoriques, comme SOLID, mais force est de constater qu’aujourd’hui, on préfère coder avec des attributs publics à tout va et des annotations, plutôt que rester dans une écriture normée et standardisée depuis bien des années (getter, setter, construct, etc. …).

      Répondre

      1. Bonjour, merci de votre retour.
        Concernant le code laravel sur Stackoverflow non optimisé c’est malheureusement le cas dans beaucoups de languages / framework 🙂

        Répondre

  6. Perso j’ai envie de revenir sur la phrase : « Symfony est le leader sur le marché … » plutôt Marché Français … et encore il y a quelques années Laravel est largement passer devant Symfony … même si perso je trouve que les offres de Jobs demande encore énormément de Symfony.

    Pour moi Laravel est plus facile a prendre en main, même une personne qui n’est pas très bonne, principalement avec Eloquent qui rend vraiment les requêtes a la base très simple a comprendre…. et je trouve que quand tu arrive dans une boite , quand tu as un gros code legacy , tu aura plus de facilité a etre efficace rapidement sur un projet Laravel plutôt que Symfony.

    De plus Blade est beaucoup plus souple et facile a utilisé que Twig.

    Répondre

  7. Vous pourriez faire un article également sur le choix de React face à Angular 🙂
    Je pense qu’on arriverait à des conclusions et des débats assez similaires lol
    L’un est facile, abordable et souple, l’autre beaucoup plus strict et cadré et moins facile d’accès.

    Répondre

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Bulles
Parlez-nous de votre projet !
Bulles