[Nous aimons utiliser Sylius](https://troopers.coop/expertises/sylius) comme plateforme pour développer des sites e-commerce, des sites de vente, des marketplaces, ou même des ERP !




C’est un excellent outil, très évolutif. Il est possible de modifier son fonctionnement en profondeur tout en conservant la puissance du framework et la possibilité de continuer à le mettre à jour pour bénéficier de nouvelles fonctionnalités.
Mais parfois, une modification anodine a des conséquences inattendues…

## L’apparition du problème

Lors d’un sprint récent sur un projet basé sur Sylius, Patrick le PO remonte une erreur lors de la modification d’un produit. Il n’arrive pas à valider la modification d’un produit alors que cela marchait auparavant.
Étrange, c’est le même formulaire qui permet la création et la mise à jour d’un produit. Il a été modifié il y a peu et des tests automatisés ont été mis en place.

Il n’y a pas à tergiverser, lorsque l’on cherche à modifier certains champs, le site remonte une erreur :
“Mise à jour impossible, Product a été modifiée précédemment” ou “Cannot update, the Product was previously modified” selon les préférences de langue.

Les tests automatisés n’ont pas détecté le problème : ils ne couvrent que la création du produit, pas sa modification.

## Que nous révèle cette erreur ?

En première approche, j’aime faire un rapide tour dans le code. En restant naïf on a parfois de bonnes surprises, et des réponses rapidement. Le message d’erreur semble suffisamment unique pour commencer par là.



Une recherche dans le code fait remonter que ce texte est associé à la clé de traduction “race_condition_error”.
Nouvelle recherche : cette clé n’est utilisée qu’au sein d’une exception spécifique à Sylius (RaceConditionException), elle-même est utilisée dans une seule classe : Sylius\Bundle\CoreBundle\Doctrine\ORM\Handler\ResourceUpdateHandler

Ouch ! Ça parle de Doctrine, qui fait l’interface entre notre code et la base de données. Dans ce contexte, une erreur de “race condition” signifie que le code ne parvient pas à déterminer dans quel ordre traiter une ou plusieurs demandes de mise à jour : la donnée en base peut être plus récente que la modification que l’on envoie.

Cela ne s’annonce pas trivial : il est temps d’identifier la modification qui a fait apparaître l’erreur.

## Comment trouver le commit coupable ?

On a identifié un champ qui génère l’erreur lors de la modification d’un produit. J’écris un test simple : créer un produit, puis tenter de modifier ce champ. Le test échoue car l’erreur apparaît.

Je vais remonter dans le temps à l’aide de GIT, l’outil de gestion de version que nous utilisons. Mon objectif : utiliser le test pour déterminer quel commit a fait apparaître l’erreur.

Je pourrais utiliser la commande [git bisect](https://git-scm.com/docs/git-bisect) qui remplit parfaitement ce rôle. Mais j’ai ma petite idée du commit “coupable” :
- Je remonte l’historique GIT juste avant le commit : le test passe.
- J’avance d’un commit, le test échoue. Parfait, c’est bien là que tout se joue !

## Identifier le problème

Dans ce commit, on a ajouté des champs sur deux entités : Product et ProductVariant.

- Product, vous l’aurez deviné, représente un produit.
- ProductVariant représente un produit particulier, avec ses propres options, sa propre tarification, voire son propre suivi des stocks.



En plus de l’ajout de ces champs, les formulaires ont été modifiés pour les afficher, et au passage intégrer le design du projet.

J’annule les modifications sur ProductVariant, et je retire les champs associés dans les formulaires. L’erreur est encore présente. Mauvaise pioche ?

Je recommence avec les modifications de l’entité Product… L’erreur persiste.

On a toujours la “RaceConditionException”, due à la mise à jour d’une entité en base de données. Or je viens d'annuler tout ce qui a changé dans le code qui concerne les entités Product et ProductVariant. Soit je suis entré dans la quatrième dimension, soit j’ai raté quelque chose.



Que reste t’il dans le commit ? Une innocente modification esthétique : nous n’affichons plus la gestion des stocks lors de l’édition du produit car c’est inutile pour ce projet.

Dans le doute, j’annule cette modification : l’erreur disparaît !

## La réponse, et le correctif

En supprimant l’affichage de la gestion des stocks, nous avons cassé l’édition des produits.

Comment est-ce possible ? Le formulaire en question ne présente que deux champs : *faut-il suivre les stocks* et si oui, *quel est le stock actuel*…

Et pourtant, un troisième champ est bien présent (mais invisible pour l’utilisateur) : la *version*. Il n’est pas obligatoire, mais son absence semble poser problème.
Je ne sais pas ce qu’est cette *version* de la variante. Avant de creuser cette piste : testons. 

Si je l’affiche (toujours invisible) mais sans rétablir la gestion des stocks, l’erreur ne réapparaît pas. Bingo, voici le correctif : rétablir le champ *version* dans le formulaire, bien qu’il ne soit pas visible.

## Mais, pourquoi ?

Ce système de version sur ProductVariant est présent pour éviter que plusieurs demandes de modifications simultanées ne rentrent en conflit. D’accord, mais pourquoi est-ce que le champ se retrouve enfoui avec la gestion des stocks, s’il est si important ?

Avec le système des stocks, il va y avoir une modification de la variante à chaque fois qu’un produit est vendu. Si deux clients achètent le même produit au même moment, ils vont tous deux demander une modification “stock -1” avec la même version : 
- Le système s'appuiera sur la donnée version pour n’autoriser qu’une modification.
- La seconde modification sera rejetée, puis retentée avec la nouvelle version : s’il reste du stock, l’achat sera également validé. Si non, pas de chance, le produit vient de passer en rupture de stock.

Comme le champ de formulaire est caché, il peut être généré n’importe où dans la page.
Bien que j’aurais préféré qu’il soit ajouté avec les champs cruciaux de la variante, je peux comprendre comment il s’est retrouvé associé aux champs de formulaire liés aux stocks…

## Le(s) mot(s) de la fin

Ce bug aura été l’occasion de creuser un peu plus loin dans notre connaissance du framework Sylius et de ses composants les moins apparents, comme le versionnage des entités.

Le problème peut sembler lunaire : des erreurs liées à Doctrine, la persistance en base, RaceConditionException. Mais l’approche de résolution montre encore une fois sa pertinence : reproduire l’erreur, réduire les modifications jusqu’à trouver l’élément déclencheur, étudier cet élément pour comprendre pourquoi il pose problème et comment corriger.

Comme à chaque fois qu’un bug échappe aux tests automatisés écrit par les développeurs, nous nous posons la question : avons-nous la bonne approche pour la rédaction des tests ?
Les tests sont nécessaires mais peuvent être chronophages (écriture, maintenance, exécution). Lorsque l'on travaille avec un framework, on cherche à tester “notre” code, pas celui du framework car il est déjà testé : c’est une perte de temps.
Ici, fallait il d’emblée un test automatisé sur la mise à jour, en plus de la création ? Sachant que le même code est concerné dans les deux cas, j’ai tendance à penser que non.
Par contre, maintenant que le bug a été rencontré, le test créé pour réussir à l’isoler et à le corriger va rester dans notre suite de tests. On a pu se faire surprendre une fois, mais pas deux !

Un bug cache parfois une occasion de mieux découvrir votre framework préféré

La publication d'une application sur App Store et Google Play Store nécessite de nombreuses heures de travail : il faut installer des outils complexes sur notre machine, compiler l'application pour les 2 boutiques d'application, puis transférer les fichiers, et enfin les envoyer pour qu'elles soient validées.

Heureusement Expo nous aide à réduire ces étapes au strict minimum.

Expo nous permet d'utiliser encore plus facilement des librairies de React Native :

- Permissions
- Géolocalisation
- Sélecteur d’images
- Signatures
- Notifications

EAS (Expo Application Service) est un service d'Expo qui permet de publier facilement sur les deux stores en suivant ces étapes : Gitlab → Expo → App Store.

Grâce à GitLab CI et à Expo, nous n’avons plus besoin de compiler l’application nous-mêmes, ce qui était contraignant en particulier pour iOS car il nous fallait un Mac disponible et éviter les écueils lors de l’installation de Xcode.

## Mise en place

Pour cela nous sommes passés par ces phases :

1. Configuration EAS pour branchement App Store
2. Configuration dans GitLab CI
3. Pas de configuration particulière dans App Store
4. Pas d’automatisation vers le PlayStore mais un simple fichier APK à envoyer sur la console Google Play Store

Configuration dans GitLab CI :

```yaml
.eas: &eas
 image: ghcr.io/troopers/node-14-eas:latest
 stage: build
 before_script:
   - yarn install
 when: manual


build-android-preprod:
 <<: *eas
 script:
   - yarn eas build --platform=android --profile=preprod --no-wait --non-interactive
 only:
   - develop


build-ios-preprod:
 <<: *eas
 script:
   - yarn eas build --platform=ios --profile=preprod --auto-submit-with-profile=release --no-wait --non-interactive
 only:
   - develop


update-preprod:
 <<: *eas
 stage: update
 script:
   - yarn eas channel:create preprod || true
   - yarn eas channel:edit preprod --branch develop || true
   - yarn eas update --non-interactive --branch=develop --auto
 only:
   - develop
```
  
  
 Le job **build-android-preprod** envoie les données à EAS qui va compiler l’application et nous fournir un lien vers un fichier APK qui peut être partagé et installé sur un appareil Android.

Le job **build-ios-preprod** envoie les données à EAS qui va compiler l’application et l’envoyer directement dans Testflight, on pourra alors publier cette version pour les utilisateurs qui font partie de notre groupe de testeurs.

Le job **update-preprod** sert quant à lui à pousser une mise à jour en OTA. Puisque la mise à jour ne demande pas de compiler l’application, la mise à jour est très rapide, elle est effective en moins de 5 minutes (contre 10 à 15 minutes pour les compilations Android et iOS).

Côté Expo, on peut visualiser comment chaque branche de git est connectée à un environnement Expo :

Récemment nous avons mis à jour la version d’Expo sur l’un de nos projets pour installer la version 45.

Cette version 45 a débloqué Expo Go et donc les mises à jour OTA très faciles, y compris via un QR code.

Les mises à jour OTA nous autorisent à mettre à jour l’application à l’exception des couches natives de l’application : configuration de base, dépendances écrites en code natif, etc.

Les publications OTA sont parfaites pour les mises à jour urgentes, par exemple pour une mise à jour pour avoir tout le monde sur le même niveau d’API. Une fois qu’une mise à jour OTA est publiée, Expo s’occupe de télécharger la mise à jour. Les utilisateurs et utilisatrices n’ont alors qu’à redémarrer leur application pour utiliser la nouvelle version.

Nous mettons quand même à jour la version sur les boutiques Apple et Google afin que les nouveaux utilisateurs aient directement la dernière version.
## Conclusion

Expo permet de publier sur les deux stores via EAS en allégeant la charge de travail. Il vient avec des avantages et des inconvénients et c’est un choix d’architecture important. Le nombre et la spécialisation des développeurs, le temps à accorder au projet aux phases de déploiement doivent jouer dans ce choix.


Comment s’appuyer sur Expo pour publier sur les deux app stores ?

## Comment nous utilisons Sylius pour construire des e-commerces open source et sur mesure
 
Chez Troopers, nous construisons des sites e-commerces, des marketplaces ou des outils de gestion pour nos clients. Pour cela, nous utilisons [Sylius](https://troopers.coop/expertises/sylius). Dans cet article nous vous partageons :
- ce qu’est Sylius, ses **principales fonctionnalités et avantages** ;
- et plusieurs **projets clients utilisant Sylius**, qu'ils soient passés ou en cours.

## Sylius : zoom sur cette solution open-source

### Présentation de Sylius

Sylius est une plateforme e-commerce open source basée sur le framework PHP Symfony. Lancée en 2011, elle est conçue pour offrir une **solution flexible et configurable aux entreprises qui souhaitent créer une boutique e-commerce**.

Sylius se distingue de ses concurrents grâce à sa **modularité** et sa capacité à s’adapter à différents types de projets et tailles d’entreprises.

En tant que solution open source, Sylius bénéficie d’une **large communauté de développeurs** qui contribuent à l’amélioration et au développement des fonctionnalités.

Une vaste bibliothèque de **plugins et d’extensions peut être utilisée pour ajouter des fonctionnalités spécifiques** à un site ou une application e-commerce : **liste de souhaits, gestion avancée de contenus éditoriaux** et j’en passe.

### Quelques caractéristiques intéressantes de Sylius 
#### La taxonomie
Sylius simplifie la gestion de l’arborescence des produits grâce à son système de taxonomie : des **catégories hiérarchisées** qui permettent de classer les produits. Sylius se charge alors de générer menus, filtres et pages catégories pour que les utilisateurs puissent aisément naviguer dans votre site e-commerce et découvrir les produits.

Les utilisateurs de Sylius peuvent facilement créer, modifier ou supprimer des catégories sans avoir de compétences en développement.

#### Personnalisation des cycles de la commande
Sylius offre la possibilité de **personnaliser les différentes étapes du processus de commande**.

En plus des étapes classiques telles que “en cours de préparation” ou “expédié”, il est possible d’ajouter des étapes supplémentaires et de** créer des règles sur mesure**. Par exemple, pour des produits personnalisables, une étape “en cours de fabrication” peut être ajoutée.

Cela apporte une valeur ajoutée aux clients en améliorant la transparence et facilite le suivi pour l’entreprise. Sylius gère également les retours de commandes de manière efficace.

#### Solutions de paiement et d’expédition
Sylius permet de **connecter la boutique e-commerce avec différents outils de paiement et d’expédition**. Certaines des solutions de paiement compatibles incluent PayPal ou Stripe. Pour les livraisons, Sylius peut se connecter avec les différentes solutions d’expédition. 

Intégré à Sylius, il est possible d’utiliser Payum, une bibliothèque de paiement open source qui facilite et sécurise l’intégration des **passerelles de paiement** dans les applications e-commerce. Elle offre une interface unifiée pour interagir avec les différents services de paiement et simplifie le processus de développement en gérant les détails techniques de chaque passerelle.

#### Personnalisation de la boutique e-commerce et/ou du back-office 
Il est possible d’utiliser la boutique en ligne et le back-office de Sylius par défaut ou de les personnaliser selon les besoins spécifiques de l’entreprise. Cela permet aux **entreprises de limiter les développements** dans un premier temps ou au contraire de créer une interface complètement adaptée à leur image. En adaptant le back-office, les entreprises peuvent ainsi calquer leur outil sur leurs processus internes et gagner du temps.



#### Solution open source et stable
Sylius est une solution open source, cela signifie que son code source est accessible à tous et peut être modifié pour répondre à des besoins spécifiques. Cela garantit une **solution flexible et évolutive** pour les entreprises.

De plus, Sylius bénéficie d’une communauté active de développeurs qui contribue à son amélioration continue et à sa stabilité. **Les entreprises sont assurées d’avoir une solution à jour et fiable pour leur boutique en ligne**.

### Les avantages de Sylius par rapport à ses concurrents

Sylius présente différents avantages par rapport à des solutions e-commerce comme Magento ou WooCommerce :
- **Flexibilité** : Sylius est conçu autour d’une architecture modulaire, permettant une personnalisation plus poussée et une meilleure adaptation aux besoins spécifiques de chaque entreprise par rapport à WooCommerce ou Magento ;
- **Performances** : Sylius est considéré comme une solution plus légère et rapide que Magento, ce qui se traduit par une meilleure expérience utilisateur et des temps de chargement plus courts pour les sites e-commerce ;
- **Facilité d’intégration** : Sylius est construit sur le framework [Symfony](https://troopers.coop/expertises/symfony), ce qui facilite l’intégration avec d’autres applications et services. WooCommerce, qui est un plugin pour WordPress, peut par exemple être plus complexe à intégrer avec des solutions tierces.

Le recrutement ou le recours à des développeurs est plus aisé sur Sylius qui est basé sur Symfony (avec une large communauté) alors que pour Magento, il faut trouver des développeurs spécifiques. Il faut noter que dans la plupart des cas la version gratuite de Sylius est utilisable pour lancer son projet.

## Notre utilisation de Sylius pour construire des e-commerces

Chez Troopers, nous utilisons Sylius pour construire des solutions e-commerce adaptées aux besoins de nos clients. Voici quelques exemples de projets sur lesquels nous avons travaillé avec succès en utilisant Sylius.

### Création d’une marketplace

Créer une marketplace peut être très complexe. En effet, cela implique de **gérer plusieurs vendeurs**, des catalogues de produits variés, des systèmes de paiement et de livraison distincts, voire des **commissions**.

Nous avons choisi d’utiliser le [plugin Odiseo](https://odiseo.io/plugins-and-bundles/premium/sylius-mvm-plugin) pour Sylius, cela nous a permis de bénéficier de nombreuses fonctionnalités clés-en-main qui nous ont permis de réduire considérablement la difficulté et le temps de développement d'une **marketplace producteurs-grossistes-détaillants**. 

Nous avons ainsi pu construire une **marketplace privée qui permet de mettre en relation les fabricants avec un groupe spécifique de clients**. Les acheteurs ont un compte pour accéder à la marketplace et sont associés à un type de profil qui leur permet d'accéder ou non aux catalogues des grossistes. Ainsi, les fabricants peuvent **filtrer les acheteurs et offrir une expérience d’achat personnalisée** selon leur cible commerciale.

### Site e-commerce proposant de la personnalisation de produits
Nous avons également construit un site e-commerce qui permet aux clients de personnaliser leurs produits lors de l’achat.

En utilisant Sylius, nous avons pu créer un processus de personnalisation interactif qui génère des consignes de fabrication spécifiques pour chaque client : la **commande validée sur le site déclenche automatiquement l’envoi des informations de fabrication du produit à l’usine** !

Ce système a permis de créer une **expérience d’achat unique** mais également d’optimiser le temps de traitement des commandes : en supprimant les temps d’attente entre l’achat en ligne et la fabrication en usine, les commandes sont **expédiées plus rapidement**. Cet avantage technique devient un argument commercial.

### ERP avec fonctionnalité de commandes récurrentes
Pour un de nos clients qui avait besoin d’une gestion des commandes récurrentes, Sylius nous a permis de **configurer et de mettre en place des abonnements qui génèrent automatiquement des commandes des clients** selon des règles définies lors du devis. Ce type de fonctionnalité est particulièrement utile pour les entreprises qui proposent des services ou des produits sur une base régulière.

En intégrant cette fonctionnalité à un système d’ERP, il est possible de **gérer les stocks et les ordres de préparation**, ainsi que l’ensemble du processus de commande depuis cette solution centralisée.



Ces différents exemples montrent des solutions e-commerce pouvant être développées avec Sylius.

## Pourquoi nous allons continuer à utiliser Sylius

Chez Troopers, nous nous engageons à fournir des solutions e-commerce sur mesure et adaptées aux besoins de nos clients.

Contrairement à certaines solutions e-commerce grand public qui peuvent être limitées en termes d’**adaptabilité et de personnalisation**, Sylius nous permet de répondre à cet engagement. Comme on l’a vu, c’est une solution e-commerce flexible qui offre de nombreuses fonctionnalités, ce qui en fait une option idéale pour **créer des sites ou applications e-commerce sur mesure**.

Sylius : la solution open-source pour un site e-commerce sur mesure


Quand on utilise API Platform pour servir un site front, on a souvent besoin d’un **espace d’admin** pour que les gestionnaires du site puissent gérer les données. Et généralement, c’est mieux si c’est pas fait de zéro. 


Dans notre recherche du bon espace admin pour notre API, nous avons eu l’occasion d’utiliser deux solutions : **Easy Admin** et la solution proposée et développée par **API Platform**.

Pour résumer brièvement, API Platform Admin est une application [**React**](https://troopers.coop/expertises/react) qui vient se connecter à votre API et la scanner pour proposer un ensemble de formulaires basés sur les endpoints disponibles. Easy Admin, quant à lui, est un **bundle** à ajouter à un projet [**Symfony**](https://troopers.coop/expertises/symfony) qui permet de créer de manière rapide un espace d’admin avec des formulaires correspondants aux entités. 

Notre but n’est pas de décréter lequel est le meilleur des deux, mais de vous proposer une comparaison afin que vous puissiez faire le choix le plus adapté à vos besoins.

## Api Platform Admin

C’est la solution officielle développée par les contributeurs d'API Platform, basée sur [react-admin](https://marmelab.com/react-admin/). Il s'agit d’une appli react qui analyse la documentation de l’API et génère des composants pour créer des formulaires d’administration. Les formulaires restent personnalisables en développant en React.

### Avantages

- Intégration complète avec Api Platform
- Conservation de la séparation API / front
- Pas de code pour la configuration par défaut
- Tous les widgets pour les types de base et les jointures sont disponibles
- Possibilité de personnalisation

### Inconvénients

- Devoir maintenir & héberger une application en plus
- S’il faut personnaliser, besoin de savoir développer en React
- Devoir mélanger les configurations de l’API front et admin sur API Platform, et gérer les droits qui vont avec

## Easy Admin

Easy Admin est un bundle qui, à l’instar d’autres outils tels que Sonata Admin, propose une interface d'administration des entités Symfony, à partir d’une configuration intégrée au projet. C’est un bundle symfony classique et nécessite donc de passer par un accès web au projet.
C'est donc une solution totalement décorrélée d’API Platform.






Pour cette solution, il est nécessaire d’écrire un peu de code afin de configurer
des formulaires pour les entités. Voici un exemple pour l’entité Question :
```php
class QuestionCrudController extends AbstractCrudController
{
   public static function getEntityFqcn(): string
   {
       return Question::class;
   }
  
   public function configureFields(string $pageName): iterable
   {
       return [
           IdField::new('id'),
           TextField::new('name'),
           TextField::new('company'),
           TextEditorField::new('description'),
       ];
   }
}
```
### Avantages 

- Environnement plus familier des développeurs back
- Installation facile et rapide
- Peu de code dans le cas nominal
- Décorrélé d’API Platform : réduction du risque d’effet de bord
- La commande Maker nous assiste afin de créer les classes

### Inconvénients

- Décorrélé d’API Platform : nécessite une configuration à part
- Obligé d’installer des dépendances inutiles à l’API (twig, etc.)

## Conclusion

En conclusion, le déploiement d’une nouvelle appli React peut s’avérer compliqué, tout comme la personnalisation d'éléments React en fonction des besoins du projet, si l’équipe n’est pas formée sur cette technologie, mais l’utilisation d’API Platform Admin permet une intégration plus cohérente de l’outil d’administration. C’est donc à décider en fonction de votre équipe de développement et de l'approche que vous souhaitez avoir pour votre projet.






Easy Admin vs Admin d'API Platform : comparatif des interfaces d'administration d'une API Symfony

Legacy to DDD : Partie 3 - Tester et faire du neuf avec Domain-Driven Design en PHP

Legacy to DDD : Part. 2 - Comment moderniser votre application PHP avec le Domain-Driven Design

Accueil