Lors de son annonce en décembre dernier, le serveur web local intégré au nouveau binaire Symfony avait piqué mon attention, et j’avais promis dans un précédent article de le tester. C’est maintenant chose faite, voici un petit retour d’utilisation et une comparaison avec mon environnement précédent, basé uniquement sur Docker.
Une grande facilité de mise en place et d’utilisation
Le démarrage est très simple: il suffit d’aller sur symfony.com/download pour avoir la commande qui permettra d’installer le binaire. C’est très rapide, on ne peut plus simple, et aussi multi-plateforme (dans la sujet de l’article, je ne parlerais que de mac OS, que j’utilise).
Une fois le binaire téléchargé, une simple commande permet d’allumer le serveur web et il commence à recevoir les requêtes en HTTP (sans SSL):
symfony server:start --no-tlsLe binaire lui-même ne remplace que le serveur web (Apache…), il est toujours nécessaire d’avoir une ou plusieurs versions de PHP installés sur sa machine (pas forcément « link » an sens de Brew). Il auto-détectera quels exécutables PHP sont disponibles, et il choisira la « meilleure » version compatible avec notre composer.json. Aucune configuration n’est nécessaire, il n’y a même pas besoin d’un .htaccess pour désigner notre front controller (app_dev.php ou index.php…).
On voit ensuite s’afficher dans le terminal un mélange de logs serveur / logs Symfony. L’avantage est que l’on a tous les logs potentiellement intéressants centralisés à un seul endroit, formatés pour une meilleure lisibilité et (légèrement) colorisés pour mettre en avant les erreurs.
Il est également possible d’exécuter des commandes PHP à travers le binaire, afin d’utiliser la même version et la même configuration de PHP. Par exemple:
symfony php composer.phar update symfony/symfony
Cette mise en route est très rapide, il reste que notre application a probablement d’autres dépendances (MySQL, ElasticSearch…), et là c’est à nous de gérer. Soit à « l’ancienne », avec tout installé en local, soit avec Docker, soit avec SymfonyCloud en utilisant un « tunnel ». Je n’ai pas testé cette dernière partie, j’ai gardé mon MySQL dans Docker, en adaptant ma configuration précédente. Une auto-configuration (côté Symfony), ou plus exactement « auto-découverte », est disponible avec Symfony 4 / Flex (uniquement), puisqu’elle utilise les variables d’environnement.
Le gros plus: la rapidité
Au-delà de la mise en route facile, le gros avantage à mon sens réside dans la rapidité: les performances sont excellentes, bien supérieures à un Apache/PHP classique dockérisé, qui souffre de la lenteur des filesystems dans Docker mac OS.
À titre de comparaison rapide, sur une application en Symfony 2.8 les temps de réponses indiqués dans la profiler toolbar ont été divisés par 5. La différence de ressenti est encore plus forte, on passe d’une application « qui rame » (à cause des autres ressources chargées, je pense) à quelque chose d’agréable, de fluide. La différence est moins flagrante sur une application Symfony 4, je pense grâce aux optimisations qui ont été apportées au fur à mesure des versions.
Deux autres avantages sont à signaler: le binaire inclut un proxy, qui permet de donner des noms de domaines à nos projets locaux très facilement, et il est capable de générer et d’installer des certificats HTTPS locaux. Tous les détails sur le sujet, avec les commandes, sont dans la présentation de Kévin Verschaeve du SymfonyLive Lille. J’ai essayé de tester rapidement, je n’ai pas réussi à faire fonctionner le proxy alors que j’étais connecté en partage de connexion, peut-être est-ce dû à une limitation de mac OS?
Quelques inconvénients
Si j’ai apprécié les avantages précédement détaillés, à l’utilisation j’ai pu trouver quelques limites et inconvénients.
Tout d’abord, la nécessité de garder PHP en local est la plus grosse limitation pour moi. J’interviens sur de nombreux projets, sur une même version de PHP les extensions requises sont très différentes, il n’y a pas de simplification de ce côté-là. De même pour les dépendances « binaires », par exemple jpegoptim ou wkhtmltopdf, il faut tout installer localement, et « maintenir » les installations (mises à jour, configuration…).
Deuxième accroche à l’utilisation, le manque de documentation. Il est dommage de devoir se référer à des slides de conférence pour découvrir les fonctionnalités. Je pense que l’idée était de favoriser d’abord une documentation en CLI, avant la documentation en ligne, mais cette dernière me manque.
Heureusement cette situation est probablement provisoire, la release étant récente, on peut imaginer avoir dans le futur une aide plus exhaustive sur symfony.com.
Dernier point, l’auto-configuration est agréable au début, mais sur des projets plus complexes on a vite besoin de configurer notre serveur web (entête CORS…). Ce n’est pas possible pour l’instant, et je ne sais pas si cela le sera un jour, puisqu’il faudrait introduire un nouveau format de configuration (le binaire utilise de ce que j’ai compris une librairie Go, donc pas possibilité de conf au format Apache genre .htaccess…).
Bilan
En conclusion, le binaire Symfony est une bonne solution pour démarrer rapidement à travailler sur un projet simple. L’initiative est louable et la réalisation réussie.
Une part de moi regrette qu’il ne soit pas accompagné d’une installation de PHP « locale », isolée, ce qui en ferait une excellente alternative aux serveurs « débutants » type EasyPHP (souvenirs…). À défaut, cela pourrait être compensé par de la documentation, ou un « package » avec par exemple de la configuration Docker.
Pour des projets plus longs ou plus complexes, je pense qu’il vaut mieux prendre le temps de mettre en place un environnement complet sous Docker et de former au besoin l’équipe dessus. Cela permettra d’aller plus loin au niveau de la configuration, de l’isolation/la reproductibilité, et d’être plus proche de l’environnement de production.
