Discussion :

[NukaCola]

Bonjour à tous,

J'aimerais avoir vos avis concernant le fait d'utiliser Api platform ou non.
J'utilise Symfony depuis plusieurs années, et depuis quelques mois j'envisage de passer en full API rest. Du coup forcément je suis tombé sur le framework, je me suis un peu renseigné dessus via la doc, mais y'a déjà plusieurs choses qui me dérangent un peu, du style le fait que quasiment tout soit des annotations dans les entités. J'aime bien avoir mes controller. Ensuite, les filtres, là encore, j'aime pas trop la façon dont c'est fait.( Mais d'un côté ça reste super utile )
D'un autre côté, ils mettent en avant le fait de respecter les bonnes pratiques, avec Json-ld/hydra, schema.org, etc. (Même si pour le coup, j'ai jamais testé json-ld/hydra, et que pour mes applis un simple json marche tout aussi bien). C'est fait par des mecs de Symfony.

J'ai tâché de regarder également sur le net, mais y'a pas des masses de retours, à part le fait que ça met en place un environnement complet directement, et que tout marche rapidement. D'un autre côté j'ai peur que si je dois commencer à faire des trucs spécifiques ça commence à être la galère. (Notamment pour le boulot)

J'ai l'impression qu'en fait ils mettent tellement d'outils et de bonnes pratiques que limite je passe dans un autre monde de codage en utilsant API platform.


Donc voilà, j'essaie d'éviter le biais de confirmation, en espérant avoir des retours d'expérience, ou bien d'autres dév dans la même situation que moi.
Surtout que si je passe en API rest dans mon code c'est à priori pour plusieurs années, et pour tous mes projets, donc autant faire le bon choix maintenant.

[_Thomas]

Salut,

J'ai tâché de regarder également sur le net, mais y'a pas des masses de retours, à part le fait que ça met en place un environnement complet directement, et que tout marche rapidement. D'un autre côté j'ai peur que si je dois commencer à faire des trucs spécifiques ça commence à être la galère. (Notamment pour le boulot)

Perso je découvre API Platform depuis quelques mois notamment via ces tutoriels (vidéos payantes mais les scripts sont accessibles gratuitement dessous) : https://symfonycasts.com/tracks/rest#api-platform
Tout en étant conscient d'avoir encore beaucoup à découvrir, je trouve dès à présent que c'est un outil vraiment complet, et comme n'importe quel framework sa prise en main demande du temps et il existe souvent plusieurs manières pour arriver à des résultats similaires.

Par contre je ne comprends pas bien ce que tu sous entends par "Notamment pour le boulot" ?

J'ai l'impression qu'en fait ils mettent tellement d'outils et de bonnes pratiques que limite je passe dans un autre monde de codage en utilisant API platform.

Très probablement que tu n'utiliseras pas toutes les fonctionnalités disponibles (certaines sont spécifiques aux interfaces "machine-machine"), mais l'un des arguments mis en avant par API Platform c'est justement d'être basé sur Symfony/Doctrine, donc si tu utilises Symfony depuis plusieurs années tu ne devrais pas être trop dépaysé pour utiliser ses fonctionnalités, les étendre, etc.

Surtout que si je passe en API rest dans mon code c'est à priori pour plusieurs années, et pour tous mes projets, donc autant faire le bon choix maintenant.

À mon avis il faut transformer ton code/tes applications en API REST que lorsque tu en a réellement l'utilité, ce qui n'est probablement pas le cas dans tous tes projets.
Cela étant dit, API Platform me semble un outil pérenne pour plusieurs raisons : basé sur SF4/Doctrine (qui ne sont pas des petits projets), une popularité croissante (cf. le nombre de tutoriels un peu partout sur le net, le nombre de conférences dont c'est le sujet, etc.) et une communauté active (cf. GitHub). Et puis comme tu connais déjà Symfony, l'apprentissage devrait être facilité par rapport à d'autres outils éventuellement écrits dans d'autres langages.

[NukaCola]

Hello, merci pour ton retour

Tout en étant conscient d'avoir encore beaucoup à découvrir, je trouve dès à présent que c'est un outil vraiment complet, et comme n'importe quel framework sa prise en main demande du temps et il existe souvent plusieurs manières pour arriver à des résultats similaires.

Par contre je ne comprends pas bien ce que tu sous entends par "Notamment pour le boulot" ?

Tu utilises les autres parties du framework (Partie admin, la doc Swagger) ou juste la partie Symfony ?
Par exemple, je n'aime pas non plus également React, préférant largement Angular.

Concernant le boulot, je peux pas spécialement me permettre de passer sous une techno, et de rester bloquer sur un problème spécifique à celle ci quand on me demande d'intégrer des choses qui sortent de l'utilisation standard. De ce que tu me dis, ça à l'air facile de modifier quelque chose vu que ça reste du Symfony. Mais si à chaque cas un peu compliqué je dois surcharger je ne sais quoi pour retourner sur du Symfony "basique", le framework perd un peu son utilité.
J'ai déjà connu des outils qui marchaient super bien 90% du temps, et après quand on rentrait dans les 10% de cas spéciaux, ça devenait un enfer à modifier.

Très probablement que tu n'utiliseras pas toutes les fonctionnalités disponibles (certaines sont spécifiques aux interfaces "machine-machine"), mais l'un des arguments mis en avant par API Platform c'est justement d'être basé sur Symfony/Doctrine, donc si tu utilises Symfony depuis plusieurs années tu ne devrais pas être trop dépaysé pour utiliser ses fonctionnalités, les étendre, etc.

Tant mieux !
Par contre ce qui me dérange vraiment, c'est d'avoir toutes les annotations dans les Entités. En temps normal j'aime plutôt les annotations, mais quand je vois ça j'ai franchement du mal

Après tu me diras que c'est une question d'habitudes, et que là c'est un exemple avec toutes les possibilités, c'est vrai, mais avec des entités ayant plusieurs sous ressources, j'ai peur que ça devienne immonde, et avec des entités de 3m en annotations.
Pour le coup c'est vraiment une question de goûts.

À mon avis il faut transformer ton code/tes applications en API REST que lorsque tu en a réellement l'utilité, ce qui n'est probablement pas le cas dans tous tes projets.
Cela étant dit, API Platform me semble un outil pérenne pour plusieurs raisons : basé sur SF4/Doctrine (qui ne sont pas des petits projets), une popularité croissante (cf. le nombre de tutoriels un peu partout sur le net, le nombre de conférences dont c'est le sujet, etc.) et une communauté active (cf. GitHub). Et puis comme tu connais déjà Symfony, l'apprentissage devrait être facilité par rapport à d'autres outils éventuellement écrits dans d'autres langages.

Pour les projets existants non c'est sûr, mais pour les futurs ça me semble intéressant de switcher complètement, que ça soit via api platform ou avec un truc manuel.
Après l'apprentissage ne me fait pas peur vu que la doc semble être claire, donc ça devrait être rapide à prendre en main.


Là à froid je serais plus tenté d'utiliser uniquement l'api core bundle directement (même si la doc automatique via Swagger peut être intéressante également)

[_Thomas]

Tu utilises les autres parties du framework (Partie admin, la doc Swagger) ou juste la partie Symfony ?

Pour l'instant je me suis concentré sur la partie "Symfony" : la 1ère parte du tuto SymfonyCasts traitait les concepts et comment utiliser les annotations pour personnaliser l'API ; la 2ème partie (en cours) est focalisée sur la sécurité donc c'est très intéressant pour voir comment API Patform réutilise des composants Symfony pour ne pas ré-inventer la roue (Security, Voters, Validation, etc.).
Après la doc Swagger je la vois comme du bonus car sans rien faire tu disposes d'une documentation toujours à jour qui représente fidèlement ton API à l'instant T.

Par exemple, je n'aime pas non plus également React, préférant largement Angular.

Je n'ai pas encore étudié la partie admin et je connais trop peu les framework JS pour me rendre compte des conséquences de leurs différences, mais effectivement ça peut être déroutant si tu connais mieux et que tu préfères Angular que React/Vue.

Concernant le boulot, je peux pas spécialement me permettre de passer sous une techno, et de rester bloquer sur un problème spécifique à celle ci quand on me demande d'intégrer des choses qui sortent de l'utilisation standard. De ce que tu me dis, ça à l'air facile de modifier quelque chose vu que ça reste du Symfony. Mais si à chaque cas un peu compliqué je dois surcharger je ne sais quoi pour retourner sur du Symfony "basique", le framework perd un peu son utilité.
J'ai déjà connu des outils qui marchaient super bien 90% du temps, et après quand on rentrait dans les 10% de cas spéciaux, ça devenait un enfer à modifier.

En fait d'après ce que j'en comprends pour l'instant (à prendre avec des pincettes donc), tu ne vas pas "retourner" faire du Symfony basique, mais comme API Platform est basé sur des composants Symfony, pour étendre ses fonctionnalités il "suffit" souvent de savoir utiliser/étendre les composants Symfony sous-jacents pour modifier le fonctionnement d'API Platform.

Après je ne partage pas l'argument des outils adéquats dans 90% des cas mais affreux dans 10%, au final tous les outils sont imparfaits et c'est bien pour ça qu'il y a régulièrement des nouvelles versions et/ou des nouveaux outils. La crainte de se laisser "enfermer" dans les contraintes d'un framework est légitime, mais dans le cas de Symfony (et donc in fine d'API Platform) les composants sont conçus pour être utilisables indépendamment les uns des autres (cf. par exemple : https://symfony.com/doc/current/crea...ork/index.html).

Et au final ça me fait penser aux arguments des gens qui préfèrent le PHP from scratch plutôt qu'utiliser un framework quelconque, au prétexte d'avoir plus de liberté mais en devant alors ré-inventer la roue (souvent moins ronde) pour chaque sujet (typiquement un routeur, la sécurité, la validation des formulaires, etc...).

Par contre ce qui me dérange vraiment, c'est d'avoir toutes les annotations dans les Entités. En temps normal j'aime plutôt les annotations, mais quand je vois ça j'ai franchement du mal

Après tu me diras que c'est une question d'habitudes, et que là c'est un exemple avec toutes les possibilités, c'est vrai, mais avec des entités ayant plusieurs sous ressources, j'ai peur que ça devienne immonde, et avec des entités de 3m en annotations.
Pour le coup c'est vraiment une question de goûts.

Là je suis d'accord, les annotations sont bien pratiques mais peuvent vite devenir illisibles et compliquées à déboguer (pas beaucoup d'autocomplétion ni de vérification dans les IDE).
D'où l'importance d'intenter le plus proprement possible en revenant à la ligne pour aérer le texte, et à utiliser des conventions de nommage pour les groupes (exemple dans ce chapitre, certaines annotations sont supprimées pour être ajoutées automatiquement sous réserve de respecter la convention de nommage choisie : https://symfonycasts.com/screencast/...ty/auto-groups).

Après pour avoir des retours d'expériences plus concrets, tu peux cherche sur YouTube, exemple de 2017 :

[NukaCola]

En fait d'après ce que j'en comprends pour l'instant (à prendre avec des pincettes donc), tu ne vas pas "retourner" faire du Symfony basique, mais comme API Platform est basé sur des composants Symfony, pour étendre ses fonctionnalités il "suffit" souvent de savoir utiliser/étendre les composants Symfony sous-jacents pour modifier le fonctionnement d'API Platform.

Hum, de ce que j'ai compris, la partie Symfony utile "juste" le api core bundle, et le framework fournit juste plusieurs outils (admin/doc) et les configs déjà prêtes. Mais pour la partie Symfony ça revient juste à un l'installation d'un bundle et sa configuration.

Après je ne partage pas l'argument des outils adéquats dans 90% des cas mais affreux dans 10%, au final tous les outils sont imparfaits et c'est bien pour ça qu'il y a régulièrement des nouvelles versions et/ou des nouveaux outils. La crainte de se laisser "enfermer" dans les contraintes d'un framework est légitime, mais dans le cas de Symfony (et donc in fine d'API Platform) les composants sont conçus pour être utilisables indépendamment les uns des autres (cf. par exemple : https://symfony.com/doc/current/crea...ork/index.html).

Et au final ça me fait penser aux arguments des gens qui préfèrent le PHP from scratch plutôt qu'utiliser un framework quelconque, au prétexte d'avoir plus de liberté mais en devant alors ré-inventer la roue (souvent moins ronde) pour chaque sujet (typiquement un routeur, la sécurité, la validation des formulaires, etc...).

Hum, je ne suis également pas d'accord avec toi pour le coup.
Je suis le premier à dire qu'il faut utiliser un framework, car on ne peut pas tout faire, surtout au niveau de la sécurité par exemple. Par contre, faut utiliser des technos éprouvées.
Entre utiliser Symfony, un framework de quasiment 15 ans, avec une grosse équipe derrière qui tourne comme une usine, et utiliser api platform, qui est dans sa version ^2.0 depuis moins de trois ans, qui est une surcouche d'un framework, dont je commence à entendre depuis un peu plus d'un an (et pourtant je suis l'actu PHP/Symfony), et qui mélange back/front/doc/infra/etc, avec divers framework, et une équipe plus petite, y'a des questions légitimes.
Même sur le site de Symfony, ils poussent timidement api-platform.

D'ailleurs tu parles de composants, mais dunglas a justement réunifié pas mal de composants à la base séparés pour faire le api core bundle qui regroupe tout. Alors que Symfony au contraire dans sa version 4 a séparé certains modules en plusieurs sous modules. Du coup ça ressemble à du Symfony mais la philosophie est différente.



En tout cas, merci beaucoup pour tes retours, je regarderai ta vidéo ce soir en continuant mes investigations.
J'aurais aimé le retour ou même juste l'avis d'autres personnes sur le forum également (Une transition raté/réussi sous api-platform, pourquoi ça peut être une bonne/mauvaise idée), mais bon.



Dans les faits, je vais juste utiliser l'api core bundle dans un projet S4, histoire de me faire la main dessus, et de me faire un avis définitif.

[_Thomas]

Entre utiliser Symfony, un framework de quasiment 15 ans, avec une grosse équipe derrière qui tourne comme une usine, et utiliser api platform, qui est dans sa version ^2.0 depuis moins de trois ans, qui est une surcouche d'un framework, dont je commence à entendre depuis un peu plus d'un an (et pourtant je suis l'actu PHP/Symfony), et qui mélange back/front/doc/infra/etc, avec divers framework, et une équipe plus petite, y'a des questions légitimes.
Même sur le site de Symfony, ils poussent timidement api-platform.

Je vois ce que tu veux dire, effectivement API Platform est plus confidentiel que Symfony (plus spécifique aussi). Je me disais qu'il manquait une page référençant les projets/sociétés qui utilisent API Platform et en fait ces infos se trouvent tout en bas de la page d'accueil du site (https://api-platform.com/). Mais ça serait encore mieux s'ils détaillaient quelques projets concrets pour illustrer comment le framework a été utilisé etc, car effectivement pour l'instant les retours d'expérience sont rares.

Et pour finir sur un argument d'autorité () :

API Platform is the most advanced API platform, in any framework or language.

++

[krakatoa]

j'utilise api platform et je recommande.

fiabilité, rapidité de développement, liberté, pérennité....

[NukaCola]

j'utilise api platform et je recommande.

fiabilité, rapidité de développement, liberté, pérennité....

Hello

Tu l'utilises depuis combien temps ? Pour quel genre de projet ? (Perso/pro)



Du coup je m'y suis mets depuis quelques jours, c'est sûr que c'est assez rapide à prendre en main quand on connait Symfony, et la doc se fait automatiquement.
Par contre, les problèmes arrivent assez tôt :

Là j'ai mis en place la partie utilisateur, et quand je crée un nouveau compte via le POST SUR /api/users, le mot de passe se met en clair dans la BDD (Forcément vu que l'encodeur n'est jamais appelé). Et pour l'appeler, là ça devient soit problématique, soit dégueulasse.

J'ai le choix entre surcharger le controller ( non recommandé par api platform ), ou créer un EventListener (recommandé). Et le système d'event est franchement pas opti, vu que je ne peux pas mettre un listener pour écouter JUSTE l'événement à la création/modification d'un utilisateur. Je dois forcément mettre un listener qui écoute toutes les créations/modifications d'une entité.

A moins que je manque quelque chose, c'est vraiment pas extra pour les grosses API.

[_Thomas]

Salut,

À la place d'un EventListener tu peux aussi utiliser un Data Persister : https://api-platform.com/docs/core/data-persisters/
Explications détaillées ici notamment pour encoder le mot de passe lors de la création d'un utilisateur : https://symfonycasts.com/screencast/...-user-password

[krakatoa]

le service d'authentification de Symfony fonctionne très bien , suffit de l'utiliser pour créer ton user...

n'oublie que Symfony est un framework qui proposent des outils, faut les utiliser...

[NukaCola]

Salut,

À la place d'un EventListener tu peux aussi utiliser un Data Persister : https://api-platform.com/docs/core/data-persisters/
Explications détaillées ici notamment pour encoder le mot de passe lors de la création d'un utilisateur : https://symfonycasts.com/screencast/...-user-password

Ah merci, j'en étais pas encore arrivé là !
En effet, ça semble mieux, vu que le framework s'arrête de chercher des DataPersisters à partir du moment où l'un d'eux renvoie true. C'est pas encore le plus opti, mais c'est un poil mieux.

le service d'authentification de Symfony fonctionne très bien , suffit de l'utiliser pour créer ton user...

n'oublie que Symfony est un framework qui proposent des outils, faut les utiliser...

Tu n'as pas l'air d'avoir bien saisi le sujet, je te laisse le relire

[houss04]

Bonjour

Moi aussi j'ai l'habitude de travailler avec Symfony des sites web traditionnelles. J'ai commencé à apprendre API platform mais j'ai des questions à poser car je suis un très confus.

Prenons un exemple d'un site web pour les annonces :

un administrateur peut poster et gérer les tous annonces (ajouter, modifier, supprimer, lister).
Un membre peut aussi ajouter, modifier supprimer et lister ses annonces uniquement à travers son espace privé.
Un visiteur peut consulter la liste des annonces et afficher les détails.

Dans l'habitude , je fais 3 controleurs pour l'entité Annonce:

• AnnonceController dans App\Controller\Admin qui contient les CRUD et les routes pour la partie admin
• AnnonceController dans App\Controller\EspaceMemebre qui contient les CRUD et les routes pour la partie espace membre
• AnnonceController dans App\Controller\Front qui contient les CRUD et les routes pour la partie visiteur

et je donne les noms des routes comme ça :

• admin_annonce_index, admin_annonce_new, admin_annonce_edit ....
• espace_membre_annonce_index, espace_membre_annonce_new, espace_membre_annonce_edit ....
• front_annonce_index, front_annonce_new, front_annonce_edit ....

Quand j'ai commencé à apprendre API platform, j'ai compris qu'il y a des 4 ou 5 opérations principales (item et collection) , mais j'ai pas compris comment créer des autres opérations spécifiques pour chaque partie (admin, front, espace membre)...

Comment bien organiser mon projet, comment par exemple un admin peut gérer et vois tous les annonces mais un membre peut gérer et voir seulement les sien. Comment on peut créer ces trois espace ... Est ce que on doit créer aussi des autres routes et controleurs pour chacun ? Est ce que un controleur peut contenir tous les crud ou bien chaque fonction dans une class unique ?

Vraiment je suis très confus et les choses ne sont pas clair. Pouvez vous m'aider et m'expliquer comment organiser un projet avec API platform ?

Je demande pas de code mais si vous avez un exemple comment faire ça je serai très reconnaissant.

Merci à vous.

[krakatoa]

d'un coté tu as l'api platform et de l'autre un serveur d'authentification (sont but est d'autoriser ou pas les accès à l'api)
le serveur d'authentification est facultatif dans le cas contraire, tout le monde a accès à l'api.


le serveur d'authentification fonctionne par jeton (jeton jwt en général)
au serveur d'auth... :
- tu t'inscris
- tu demande (identifiant + pwd) un jeton
- tu reçois un jeton (à stocker)

au serveur d'api :
- tu joint le jeton dans ta requête pour interroger l'api et donc le serveur d'auth vérifie celui ci et te laisse accéder à l'api


dans le jeton, on peut mettre les roles de l'utilisateur
et donc lors des accès à l'api, symfony récupère le rôle et ainsi tu peux autoriser ou pas certaine actions api...

le systèmes de voters proposé par Symfony permet de connaitre le propriétaire etc.....


dans l'ensemble, c'est quand même un gros morceau, cela demande un certain temps d'apprentissage.... mais ça vaut le coup.
il y a pas mal de docs et de tutos sur ces sujets....


bon courage...