Contributeur depuis de nombreuses années sur Sylius et maintenant membre de la Core Team, je vous propose un voyage dans le futur de Sylius.
Nous verrons ensemble comment sera le code Sylius de demain et quelles seront les futures migrations de packages avec un objectif simple : se rapprocher de l’écosystème de Symfony.
Nous reviendrons également sur la vision de Pawel Jedrzejewski (le créateur de Sylius) d’exposer un skeleton plus léger et une architecture plus adaptable au niveau des fonctionnalités proposées par le framework E-commerce.
_ Bonjour. Je suis Loïc Frémont. Je suis expert technique chez Akawaka depuis quelques mois. Comme Olivier l'a expliqué, je suis membre de la Core Team Sylius depuis l'année dernière et créateur de Monofony en projet open source. J'ai mis les liens vers les réseaux sociaux pour me contacter après la conférence ou pour poser vos questions. Vous pourrez aussi venir me voir directement et faire vos doléances pour le futur de PHP également. J'ai mis mon lien vers mon Github.
Pour voir le futur d'un projet, il faut voir le focus sur Sylius, voir comment on en est arrivé là et tirer les conclusions de tout ça. Sylius a démarré depuis un bon moment. Il va falloir changer un peu les choses. Je vais vous présenter la recherche et développement que j'ai en cours. Tout est à l'état de POC pour essayer d'améliorer l'expérience développeur, pour faciliter la customisation des projets en Sylius et répondre davantage facilement à vos besoins et ceux de vos clients.
Il y a beaucoup de gens qui ont fait du Sylius dans la salle ? Une grande majorité, sinon, ils sont au talk d'à côté. C'est basé sur Symfony. Tout est dans l'adaptabilité pour les projets clients. Je n'ai pas dit ce que je faisais en sommaire sur la recherche-développement côté Sylius Symfony, Sylius API Platform, notamment. Au commencement de Sylius en 2013, ce n'est pas rien. PHP 5, Symfony 2 est une architecture découpée en plusieurs bundles. Je crois qu'ils sont à peu près tous encore là.
Première release stable quatre ans après, en 2017, en PHP 7 et Symfony
Dernière release stable pour la Saint-Valentin. Je ne sais pas pourquoi, c'est comme ça. En PHP 8. Symfony 4 et 5. Introduction et API Platform, il y a deux versions, et puis, toujours 40 packages et Sylius.
On est toujours en version majeure et on est monté en version Symfony jusqu'à lundi, mardi pour le support de Symfony 6.
J'ai passé des heures chez Akawaka pour essayer de faire monter de version en version 6. On va maintenant parler des choses qui plaisent un peu moins. Pour construire l'e-commerce qu'est Sylius assez monstrueux autour de Symfony, il y a pas mal de packages techniques qui ont été réalisés au fil du temps. Il y a des éléments pour mettre à jour Symfony qui est resté en version 1 de Sylius. On va arriver assez vite au bout de la version 1. Des packages techniques ont été défaits pour répondre aux besoins de prod. Je pense que tout le monde ici a utilisé le ressource bundle. Ça répond à un besoin et on verra que ça a ses limitations. Il va falloir mettre à jour tous ces packages et c'est compliqué. Si on peut se passer de quelques mises à jour, ce serait pas mal. On pourrait être prêts pour la version suivante de Symfony et que cela se passe plus rapidement.
Cela inclut du retard sur les versions. On est encore en API Platform version 2.6 pour la stable. On était en Symfony framework 5. Ça a mis du temps. Symfony 6 est sorti le 29 novembre, il y a quasiment un an, il va falloir du temps pour mettre à jour tout ça.
J'ai créé une issue le 7 novembre avant la version stable de Symfony 6. Ça a demandé de mettre à jour tous les composants externes qui ne sont même pas liés à Sylius. Tout un tas de composants. Symfony était déjà prêt, forcément.
Ensuite, il fallait faire tous les packages techniques avec les fameux 13 repository techniques. Ensuite, faire les packages internes. Tous les bundles internes, et ensuite, il fallait s'occuper de la partie e-commerce pour que l'application e-commerce Sylius de base puisse fonctionner en Symfony 6. Ça y est, on y arrive enfin.
Maintenant, c'est à vous de la tester. J'ai commencé à avoir quelques petits soucis en utilisant Monofony. On voit la capacité du bundle à être autonome dans un projet Symfony. On remonte les blocs de dépendance entre les packages.
Premier chapitre de R&D, Sylius par Symfony. Sylius a commencé bien avant la naissance de composants majeurs de Symfony. Nicolas vous en apprendra plus sur les composants Symfony et leur arrivée. Tous ces composants sont assez nouveaux par rapport au temps où Sylius a démarré. Utiliser les composants officiels permet de réduire les composants techniques à maintenir.
On va essayer de remplacer des packages, j'en ai notamment ciblé 3. Vous en ciblerez peut-être d'autres.
Ces trois, on va les remplacer. Est-ce qu'il y en a qui connaissent Zenstruck Foundry ? Pas beaucoup. Ensuite, Workflow et Panther.
Zenstruck Foundry, c'est quelque chose qui permet de créer un jeu de données très rapide pour le cas isolé de notre test. Dans Sylius, c'était pas mal, ce qu'ils avaient fait, le fixture bundle. Je l'ai utilisé pendant des années, mais le problème, c'est l'adaptabilité. C'est dommage pour un framework e-commerce comme Sylius de pécher ici pour étendre les fixtures de Sylius.
Comment ça marche ? Il y a une factory par ressources pour instancier la ressource en elle-même. Il y aura des stories qui vont créer les jeux de données pour une ressource de données. Ça va être piloté après par le Data Doctrine Fixture bundle.
On va pouvoir créer une petite partie de données pour la configuration et vous pourrez customiser en mélangeant vos data fixtures pour coller à votre projet client.
Comment Sylius fonctionne ? Zenstruck Foundry. Ce n'est pas l'implémentation que l'on a sur Sylius. C'est comment ça fonctionne. On va créer des valeurs par défaut. Là, ça va être du code. On va utiliser PHP pour définir les valeurs par défaut.
Ensuite, il y a la méthode initialisation qui va permettre de peupler la ressource, de la créer et de la peupler. Sur Sylius, on utilise des ressources factories qui vont instancier la ressource. C'est dans Sylius et dans votre projet, le répertoire pour être étendu et adapté à vos besoins. On a besoin d'instancier la ressource dans vos projets et non dans Sylius. On va peupler la donnée avec les valeurs par défaut. Ou les valeurs que l'on a fournies à la factory aussi.
Dans vos projets, on va utiliser l'extend classique et on pourra l'utiliser autrement. On va le voir après. On peut utiliser cet extend pour étendre les valeurs par défaut. Là, je merge les valeurs par défaut de Sylius et mes propriétés custom sur ma ressource.
Ensuite, on va fournir une méthode update sur chacune des factories. On va ainsi pouvoir peupler les nouveaux attributs. On a une factory qui récupère par défaut, ça donne des attributs. On va pouvoir transformer les valeurs. On va pouvoir instancier la ressource et mettre à jour les données.
Le nouvel objectif maintenant, ça va être d'utiliser la décoration pour les plug-ins. Un plug-in peut étendre des ressources qui existent déjà dans Sylius et ils peuvent être plusieurs à étendre les ressources.
On peut décorer les default values si on n'a pas envie d'étendre la factory. Ensuite, le transformeur. On va rajouter un service de transformeur, on va pouvoir le décorer aussi et en dernier, un updateur.
Ici, un faux plug-in qui n'existera pas et n'existera jamais. Il propose une méthode et il merge les valeurs par défaut.
Pour la transformation, on va pouvoir parler un peu plus de ça. Si vous avez utilisé le Sylius fixture bundle, c'est pour prendre le code et le transformer en une ressource channel pour correspondre au code XML demandé. Tout à l'heure, je disais qu'UR va pouvoir fournir directement l'instance de la currency avec une currency en euros.
Grosse nouveauté aussi, c'est une méthode qui est fournie. Si elle n'existe pas, c'est qu'on va pouvoir la créer automatiquement. Décoration de l'upadteur, même système, on va rajouter nos populations de nouveaux attributs.
À quoi cela ressemble, l'utilisation des factories ? On va fournir des méthodes qui permettent de découvrir très rapidement en autocomplétion ce que fournit la factory fournie par Sylius. Un exemple plus costaud, Channel Factory, cela permet de créer la Local Channel US, et cela en même temps.
Maintenant, une storie, c'est pour instancier des shop users. Ce sont les utilisateurs qui vont lancer les shops commerce. On va pouvoir mélanger les random et les prototypes.
Le passage à Symfony workflow a déjà commencé dans le ressource bundle que l'on peut déjà activer en changeant la configuration par les settings de la ressource. C'est déjà prêt, cette partie-là. Il y a une couche d'attraction entre l'utilisation du Symfony workflow et le Safe machine bundle.
On va pouvoir utiliser la même route qui est appliquée de la même manière que les transitions de manière générale. On voit ici la gestion de la route.
Ce qu'il reste à faire de ce côté, c'est de redéfinir toutes les state machines avec la configuration de Symfony workflow et d'adapter le besoin, de faire coïncider les deux et à un moment donné, vous pouvez choisir l'un ou l'autre dans votre projet, quand tout sera prêt. Le but sera de déprécier les anciennes state machines plus tard.
Et puis, Symfony Panther, c'est pour les tests Behat avec ou sans Sylius ?
Il y avait le Behat extension que je ne trouve pas vraiment bien maintenue. Il y a eu plein d'erreurs. Sur Monofony, j'ai galéré avec ce package. Je l'ai vite enlevé. Sur Monofony, on peut d'ailleurs utiliser Symfony Panther. J'avais commencé à faire la même chose sur Sylius et c'est terminé.
Maintenant, on passe à la deuxième grosse partie, la gestion des ressources. On ne va même pas parler d'API, on va parler du ressource bundle, encore une fois. Le ressource bundle est le cœur de Sylius. C'est avec ça que tout est fait. Tout est basé là-dessus. L'architecture d'API Platform a été revue maintes et maintes fois. Ils ont proposé quelque chose de super génial. J'ai eu l'occasion de tester la 2.7 en version dev quand elle est sortie et j'ai trouvé ça vraiment pratique. Je me suis dit qu'on pouvait faire la même chose sur Sylius.
Au début, ça faisait un peu peur. Au final, je me suis lancé. Voilà ce que ça donne. On va déprécier ressource controller. C'est un gros truc. Il n'y aura plus besoin de route et de controller. Il pèse 175 lignes de code et 7 actions. Ça fait un paquet d'actions et de codes à tester.
Le test de ce ressource bundle est impressionnant. Sylius a du mal à faire des évolutions sur ces ressources. Ça devient un peu compliqué. On va pouvoir faire autrement. Ce que l'on souhaite, l'objectif est d'avoir plus de flexibilité, de détacher les ressources de Doctrine, de pouvoir détacher des ressources Sylius qui ne soient pas des entités Doctrine. Le support des DTO, le support du Domain-driven design et faciliter la prise en main des développeurs Symfony. Il y a beaucoup de gens dans l'écosystème Symfony utilise API Platform.
Ils vont être comme à la maison. Sylius a un code assez compliqué pour rentrer dedans quand on vient de Symfony de par la structure technique, les composants techniques qui ont été développés. Si le composant technique se rapproche de la communauté Symfony, on va avoir une prise en main plus facile pour les développeurs.
On va commencer simple, des attributs pour configurer les routes. On va définir les opérations dans notre ressource. Ici, une entité Doctrine. On va définir la ressource Sylius et on va définir les opérations. Contrairement à API Platform, ici, on va définir plutôt les opérations de code. Un create va voir deux méthodes quand on affiche et quand on soumet. On a aussi la définition de la grid*. Est-ce que vous savez tout ce que c'est qu'une grid Sylius ? C'est la liste des ressources sur la base des administrateurs. C'est un tableau avec des filtres en haut. C'est ça, la gestion de la grid qui est définie en PHP maintenant. On va pouvoir piloter ce truc. Cette grille a un alias. On peut la déclarer dans la déclaration de l'index pour l'utiliser dans notre index.
Ça va générer ces cinq routes. Il y aura les paths directement associées. Nous n'avons pas eu besoin de définir le nom de la route ni le path qui va se définir de manière automatique. Les sections et les préfixes de route. Sur Sylius, il y a la partie admin, les routes utilisant notre firewall. Quand on utilise le shop avec un template. On va pouvoir définir des sections de route et un préfixe sur la route. Ici, j'ai défini une route. Mais sur le shop, je n'ai pas mis de route. Cela va donner une section qui se retrouve dans le nom de la route, intégrée en plein milieu. Le préfixe va être utilisé pour faire le path de la route. Dans le choc, il n'y a pas de route prefix.
Comme je le disais tout à l'heure, je n'en ai pas parlé, mais il y a eu du brainstorming entre Sylius et API Platform pour justement intégrer la nouvelle API avec API Platform dans Sylius. Cela a donné naissance à des évolutions API Platform qui ont donné lieu à la future version 3 d'API Platform.
Comme Sylius utilise des ressources, c'est juste qu'on ne l'utilise pas en API, on l'utilise en HTML, pourquoi pas le réutiliser puisque cela fonctionne très bien ? On utiliserait les kernel events, les state provider, les specs processor, les inputs et les outputs. On va se brancher sur les kernel events.
ReadListener se place en amont et récupère des données en utilisant des State providers que vous pourrez définir vous-même. FactoryListener honneur qui va instancier la ressource en utilisant la ressource factory. Le FormListener qui va initialiser et soumettre le formulaire. Un validateur et ensuite, ça va écrire au WriteListener. Ça va définir les changements en utilisant le state processor.
Avant d'enregistrer la donnée, sur Sylius, il y a des événements de precreate ou preupdate. Il y a une ressource book avec un alias et il y aura un event qui sera dispatché. C'est un peu pour la rétro compatibilité des applications. Le but n'est pas de tout péter. Le but est de redispatcher après réécriture des données.
Plus que le contrôleur en lui-même ne répond pas une réponse Symfony, il veut une réponse Symfony. On va traiter la ressource pour transformer en réponse Symfony.
Si vous avez vu les différentes conférences sur API Platform, ça se ressemble énormément. On a un provider, une interface qui va avoir l'opération, le create, l'update, etc., et on va pouvoir faire une action générique et le Request configuration est un objet Sylius qui contient la requête de Symfony et des metadatas sur la route.
Pour Doctrine, très simple. Il y a un provider qui est fourni directement. Si votre entité est une entité Doctrine, si votre ressource est une entité Doctrine, cela sera configuré par défaut et utilisera les ressources Sylius. Si vous utilisez les méthodes de repository custom, ça fonctionnera sans rien faire de plus.
Ici, il y a un provider custom. On va pouvoir définir directement dans la définition de la ressource ce qui va conduire à une route, un provider que l'on va associer directement avec le FQCM du service.
J'ai mis un exemple. On ne va pas partir sur le domaine du Web design. Ce serait une conférence à part et ce serait trop long. Je vous laisse regarder, on va bientôt sortir en ligne la conférence de Mathias et de Robin qui a été faite sur API Platform de cette année surtout. C'est vraiment l'implémentation dans la version 3. On va récupérer l'ID qui est fourni dans la route via l'attribut dans la request. Après, on peut récupérer la ressource de n'importe où, de ce que l'on veut, tout ce que l'on veut, c'est de ramener cet exemple. Du moment qu'on fournit le book à la fin, c'est fini.
Le state processor, de l'autre côté, c'est pour traiter la ressource en elle-même ou ensemble de ressources pour envoyer un e-mail, pour la base de données, pour ajouter à un bus de commandes, etc. Qu'est-ce qui est en plus ? La liste de datas qui contient les fameuses données à traiter.
Comme avec le state provider, il y a state processor par défaut qui va utiliser Doctrine et qui va flush et refresh. On va pouvoir configurer de la même manière qu'avec le state provider dans la route les processeurs à utiliser.
L'exemple que j'ai mis est vraiment bateau. Il va décorer le persist processor qui est fourni par Sylius pour enregistrer en base de données et il va rajouter quelque chose en plus qui sera de dispatcher... C'est juste un exemple. Vous pourrez faire autre chose que ça. Il va dispatcher le book qui a été créé dans le but de commande pour faire quelque chose de supplémentaire avec Symfony Messenger.
Maintenant, nous allons voir. J'ai menti tout à l'heure en disant qu'il n'y avait plus besoin de contrôleur. Ce n'est pas vrai. Sur Symfony, on est obligé d'avoir un contrôleur. C'est nécessaire. On a un code copier-coller PlaceHolderAction qui va prendre la ressource ou le jeu de ressources directement dedans et qui va le retourner. Si vous faites ça dans Symfony, vous tapez la fameuse exception, c'est les listers qui viennent juste après pour répondre. L'objet dedans peut être l'instance Sylius, DTO qui sera peut-être aussi la ressource ou le fameux input. On va avoir l'ensemble du jeu de données pour traiter la grid ou un itérable.
On peut aussi définir un contrôleur. Attention, il y a quand même les listers autour que l'on va pouvoir désactiver ou pas. On désactive le lister de la création et dire qu'on instancier nous-mêmes. On pourrait faire ce que l'on veut pour instancier tout ce dont on a besoin ici. J'ai mis un exemple. On va utiliser l'attribut user de Symfony. Il va injecter l'utilisateur courant dans la propriété user. Là, les listers font la suite. Là, on fait la même chose, mais on ne désactive pas la factory. Vous avez book, data et vous avez déjà le book instanciéqui arrive dans data. On rajoute l'utilisateur qui a créé le book dans la base de données.
Autre chose à travailler, c'est faire en sorte que les ressources soient détachées de Doctrine. Là, on va utiliser l'ISBN pour l'identifiant, il faut que ça marche. Ça va être un des objectifs futurs.
Autre chose, quand on va utiliser l'input... Il y en a qui ont déjà utilisé des inputs sur API Platform ? Oui. Cool. Ça va permettre de peupler la Request dans un objet intermédiaire et de le traiter ensuite dans la ressource. ici, J'ai pris un register user basic avec un e-mail et un password. Ça doit suffire à peupler la ressource intermédiaire pour ensuite créer un user.
On utilise le register user processeur que l'on va définir nous-mêmes et instancier notre source Sylius qui va être une entité Doctrine et qui va transformer cet input en une ressource user. Sur Sylius, ce serait plutôt shop user. C'est un des principes. On va s'occuper ensuite d'enregistrer cette personne en base de données. Ce n'est pas forcément une base de données dernière. On fait ce que l'on veut. Le but est de pouvoir être libre de faire ce que l'on veut à l'intérieur du ressource controller. Il était ultra cadré, c'est cool, mais on ne pouvait rien faire d'autre chose.
Autre solution sympa, c'est d'utiliser Messenger Processor directement. On va avoir le fameux book de tout à l'heure que l'on aura mis en instance. On va le dispatcher automatiquement dans le bus de commande Symfony et traiter la requête avec un handler de message qui implémente message handler de Symfony. Cette fois, on utilise l'input, mais on n'utilise plus le processeur pour implémenter la donnée, on utilise le but de commande Symfony pour le traiter en tant que handler. Ça va ressembler à l'implémentation que Sylius a faite avec API Platform sur le register, le change password, etc. On va refaire la même chose et on va pouvoir réduire le code Sylius à l'intérieur pour justement ces fameuses routes de security.
Est-ce que ça marche et est-ce que c'est cool ? Pour l'instant, c'est au stade de POC. C'est en discussion avec Sylius aussi. On commence tout juste à en discuter. Si on en parle, c'est parce que ce n'est pas encore fait. Ce n'est pas encore là. Vous avez sans doute votre expérience à vous. Il va falloir challenger avec un projet pour voir ce que ça peut donner et si cela se plie correctement aux besoins de chacun.
Dernière partie assez rapide. Je vais parler légèrement de Monofony. C'est un microframework qui utilise le ressource bundle, le grid ou tout ce qui est fourni comme code et tester via avec les tests qui vont bien, et vous avez un environnement pour pouvoir faire votre projet et en BDD directement.
On va pouvoir faire les tests et des formulaires de cette manière plus poussée. On refait la gestion de la taxonomie dans Monofony. Et la gestion des animaux. Vous pourrez aller voir la démo de Monofony. demo.monofony.com
Pour les gens qui ne connaissent pas la grille, c'est ça. Les filtres sont repliés, mais on peut faire autant de filtres que l'on veut. Chaque élément du tableau sur Sylius est en HTML. On peut le customiser. À la base, on peut faire ce que l'on veut, on peut rajouter des images, faire ce que l'on veut. C'est très pratique.
Maintenant, en vrac, nous n'avons pas suffisamment de temps pour expliquer toutes mes idées, faire des plug-ins compatibles à la fois sur Sylius et Monofony et Symfony tout court. Nous ne sommes pas obligés d'utiliser... Le but est de ne pas être obligés d'utiliser Monofony pour un projet Sylius et Symfony. Des composants qui vous servent tous les jours hors des projets Sylius. Tout ce qui est CMS, export de données, plein d'autres choses, vous n'avez pas besoin de Sylius. Cet écosystème, ce microframework conçu autour des composantes de Sylius, il a besoin d'être étendu sur quelque chose qui n'invoque pas sans arrêt Sylius.
Configurer le ressource et le grid bundle sur Symfony, pour l'avoir fait, ce n'est pas facile. C'est compliqué parce qu'il n'y a aucun template qui vient avec. Il n'y a rien qui vient piloter la grille et faire tout ça. Le but sera de fournir des packages de thèmes. Ensuite, il y a la migration des grilles qui ont été faites depuis récemment en PHP. Ce sont des services. Une grille peut être définie comme un service maintenant. Et on peut utiliser l'injection de dépendance. On peut injecter le user dans une grille Symfony pour gérer les rôles à l'intérieur. Il va falloir les migrer pour que les grilles actuelles soient desservies sur Symfony. On va pouvoir décorer. Ce sera beaucoup mieux et en théorie, je pense que ça arrivera pour la 2.0.
Pour les fameux filtres de grille, il y a des filtres qui sont fournis. On peut faire des filtres custom pour filtrer notre grille. Quand on doit définir des filtres custom, il faut configurer nous-mêmes le filtre dans Symfony. Dommage. Il existe l'autoconfiguration dans Symfony, mais ce n'est pas géré. Il faudra le faire et il faudra faire le maker. Il y en a beaucoup qui utilisent le maker bundle ? Il y en a un paquet ! C'est bien. Ça permet de gagner du temps. On s'est marré avec ça. On a fait des trucs fous les derniers temps.
J'ai fait quelques trucs pour générer avec Sylius. Il faut faire un make ressources dessus pour que ça fonctionne bien. On peut aller super loin là-dessus.
En conclusion, toutes mes idées à moi, pas encore les idées des autres commandes de Sylius. Ce ne sont pas vos idées. Si vous utilisez Sylius régulièrement, vous avez peut-être d'autres idées que je n'ai pas. Ce que je vous ai présenté, c'est ce que j'ai envie de voir sur Sylius. C'est comme ça que je suis devenu Core Team Sylius. Je voulais participer et apporter ces fonctionnalités sur Sylius. Ça m'a permis de voir arriver, de les voir voir le jour. Si je vous montre ça, c'est parce que je pense que ça verra le jour sans doute l'année prochaine.
Il va falloir que vous participiez à donner vos idées pour justement faire en sorte que Sylius, vous ne le critiquiez pas en disant que c'est de la merde, que c'est vraiment pourri. Vous allez pouvoir agir pour faire en sorte que le Sylius de demain soit celui que vous voulez.
Ma conclusion : c'est que le futur n'est jamais écrit à l'avance pour personne. Votre futur sera exactement ce que vous en ferez alors en sorte qu'il soit bon pour chacun de vous. Il faut rendre Sylius beau pour que vous adorez l'utiliser. Je vous ai mis le QR Code pour échanger. Comme je suis aussi dans les premières conférences, vous avez le droit de venir me voir. Je vais répondre aux questions auxquelles je serai en mesure de répondre en tant que développeur. S'il y a des questions fonctionnelles sur Sylius, je vous invite à aller voir la roadmap et je pourrais transférer des questions à Sylius pour essayer de répondre à vos questions durant la conférence. Merci à vous et merci à Akawaka pour tout le temps consacré à cette R&D et de pouvoir contribuer à Sylius sur le temps de travail. Merci !
_ Merci, Loïc. Nous n'avons pas le temps pour des questions, mais vous pourrez retrouver Loïc tout au long du forum. Il sera dans les parages. Merci.
Tweets