I've been trying to use sylius for a few weeks now and it's not looking good. The documentation is poor & poorly written, which does not encourage implementation in Sylius e-commerce. If someone doesn't have advanced knowledge in symfony, they are not able to start with this framework. I honestly think that I should give up further development in this direction.
Thank you a lot. J'ai développé un gros projet ces 6 derniers mois pour une start-up où j'étais le lead dev back (ma mission se termine à Noël). Voici une des difficultés que j'ai rencontré. L'API est pour une sorte de marketplace et il y a 5 typologies d'utilisateurs : le public (anonymous users), les clients (users), les vendeurs, les accompagnateurs de vendeurs et les admins internes. Chaque rôle a ensuite ses propres règles de sécurité (ex: un vendeur peut voir ses propres produits dépubliés et tous les produits publics). L'API a pour vocation de pouvoir être utilisé directement par les vendeurs et accompagnateurs. Des ressources, des opérations mais aussi des groupes (groupFilter) ou des filtres ne doivent pas être exposé pour différents rôles. J'ai du mettre en place des hack pour pouvoir avoir une documentation openapi qui soient rendues en fonction du rôle de l'utilisateur (par son token jwt). Je ne sais pas si c'est une bonne pratique d'avoir une sorte de documentation dynamique ou si il faut faire autrement. Dans la mesure où la doc est gérée par des attributs et difficilement extensible en PHP c'est pas évident. Une autre difficulté concerne le filtrage des nested resources contextuellement (ex: avec un ger collection sur des produits un vendeur doit voir toutes ses déclinaisons mais un utilisateur ne doit voir que celles qui sont publiées), les relations sont "fetchées" directement par doctrine et il n y a pas moyen avec des doctrineExtension de filtrer facilement et contextuellement. La seule solution que j'ai trouvé est d'avoir 2 groupes de serialisation sur 2 Getters qui utilisent des criterias différents. Puis exposer un seule groupe de serialisation qui est changé dynamiquement en l'un des 2 groupe final grâce à un contextBuilder. Merci encore. Je pense démarrer un side project perso en début d'année avec SF7, si possible Doctrine ORM 3 (qui un jour sortira p-e darklol) et la dernière release ou une bêta d'A.P. en essayant d'exploiter au max les bonnes pratiques.
We did something quite similar in our project with API Platform 3 and the development process was very painful. Hopefully, we succeed with DTO / processor approach but it took much time to understand how it works with a lack of documentation. One of the weirdest things was that we had to expose entity resource and output DTO for this entity as a resource too (GET item only) to make it work. Then, to create the one resource from those two (dto and entity) you have to use the same shortName and uriTemplate to fix openapi schema I didn`t try stateOptions and it might solve this issue. But in general, it is very far from DTO system of "my dreams" :)
API Platform must be the most advanced API builder tool out there. It rests on web standards and does all heavy lifting for you when creating an API from scratch. Bravo! 👏👏
You got it all wrong. Both DDD and CQRS. I would advice you to rethink how you look at Infrastructure layer. Same for what is actually a domain service and its purpose.
