Comment nous avons rendu API Platform compatible avec Laravel

Ah, excusez moi, je ne vous avais pas vus.

J'étais dans mon truc, là.

Je pense qu'il vous manque un tout petit peu de contexte.

Qui, ici c'est ce que c'est API Platform ? Ah ça c'est chouette, ça va me faire gagner un peu de temps ! Je me présente, je m'appelle Antoine Bluchet vous pouvez me retrouver sous le pseudonyme de soyuka sur Internet.

Je suis directeur technique chez Les Tilleuls.

Alors Les Tilleuls, c'est un peu différent d'une société classique.

On est une société coopérative.

Ce que ça veut dire, principalement, c'est qu'il y a plus de 51 % des salariés qui sont aussi associés.

Donc on gère la société ensemble.

Chez nous, c'est 100 %.

Tout le monde est salarié-associé.

Je suis aujourd'hui le release manager d'API Platform, donc c'est la personne qui va taguer la nouvelle version, qui va faire que toutes vos API cassent.

On a vu la conférence de Smaïne avant, mettez des alertes.

Et je suis développeur depuis un petit moment.

Vous pouvez me retrouver sur les réseaux sociaux que vous avez en bas de l'écran.

Petit rappel, API Platform, la promesse, c'est quoi ? C'est de pouvoir démarrer une API en quelques minutes.

Littéralement. Il y a peu de concept pour les débutants.

On essaye d'avoir des choses qui sont accessibles.

En plus de ça, ça supporte les standards du web les plus importants autour des API REST et hypermédia.

On va en reparler tout à l'heure et c'est extensible.

Comme on l'a dit au début, c'est basé sur des composants de Symfony.

API Platform, quand vous commencez, l'idée, c'est quelque chose comme ça.

On a une classe PHP. Ici, un livre et on va y apposer un attribut PHP 8 ApiResource.

On va même plus loin avec API Platform.

Ce qu'on propose, c'est une intégration de Doctrine.

Donc si vous avez Doctrine, vous avez automatiquement un système de persistance qui est branché et avec l'ApiResource à poser sur une entité, vous avez tout qui marche d'emblée. Vous vous retrouvez avec une API REST, avec ces routes qui sont déclarées dans votre système, qui vous permettent de récupérer une collection de livres, de créer un nouveau livre, de supprimer, de mettre à jour et ainsi de suite.

J'ai peut être oublié de vous parler de Laravel aussi, en fait.

Je suis désolé, c'est vendredi, je sais pas ce qui m'arrive.

Qui ici, a déjà utilisé Laravel ? Pas juste "J'ai testé Laravel et puis voilà, j'ai vu ce que c'était". Non, qui a utilisé Laravel et mis en production un projet avec Laravel ? Ah, ça fait plaisir à voir ! Alors.

Je vais vous montrer maintenant comment fonctionne API Platform avec Laravel.

Première étape, on require le composant API Platform Laravel.

Ce qui va venir nous installer.

Ce dont je vous parlais tout à l'heure.

Vous voyez que, une fois qu'on a installé le composant, à la fin on va venir copier les fichiers de configuration requis et aussi un dossier public dans les assets.

Suite à ça, on va faire un petit peu de Laravel ici.

Je vais utiliser le maker de Laravel pour créer un nouveau modèle, ici un modèle de livre.

Je vais générer une factory et une migration, on va voir à quoi ça sert.

Donc la Factory, il y a déjà un faker qui est disponible qui va me permettre de mettre de la fausse donnée dedans.

Je vais dire que j'ai un titre qui est un nom, pourquoi pas.

Ensuite, je vais aller dans ma migration.

Ici, je vais lui rajouter la colonne que je viens de mentionner.

Une fois que ça c'est fait, je vais aussi aller dans le DatabaseSeeder.

Quand je vais ensuite créer ma migration, je vais pouvoir rajouter des données.

Là, j'ai décidé de rajouter 10 livres pour vous montrer un peu comment ça marche.

Quand j'ai fait ça, je peux utiliser PHP artisan migrate --seed.

Il va automatiquement créer ma base de données en utilisant la Factory et rajouter des données.

Maintenant là, j'aimerais bien apposer mon attribut ApiResource sur le modèle, comme je vous ai montré tout à l'heure.

Sauf que, dans Laravel, il y a aussi une gestion d'erreurs et là on va devoir aussi implémenter quelque chose.

Le composant Laravel d'API Platform vous propose un ExceptionHandler.

C'est une classe qui va automatiquement gérer les exceptions pour vous et vous les afficher au format JSON ou dans le format qui est demandé.

Alors ici, j'étends ce service qui est proposé par API Platform.

Peut être que dans le futur, on va faire plutôt un trait.

Ça reste à réfléchir.

Une fois que ça c'est branché, j'ai une dernière étape.

Je vais aller ouvrir le modèle eloquent et je vais apposer mon ApiResource dessus.

Ceci devrait avoir comme conséquence de vous proposer une API REST hypermédia.

Toute fonctionnelle.

Vous êtes prêts ? Ici, on voit du coup une Swagger UI qui est branchée sur Laravel.

Là, je vous ai affiché la collection de livres.

Vous voyez qu'on a le fameux JSON Linked Data qu'on met vachement en avant avec API Platform, qui est disponible.

On a bien entendu, la possibilité d'utiliser toutes les routes.

Ici, je vais créer un nouveau livre qui est un petit peu plus dans la tendance de nos jours.

Et bien entendu, je peux aussi aller par exemple supprimer le livre.

Ici, je vais utiliser le dernier identifiant.

Je vais avoir un code 204 qui correspond bien à la suppression.

Si je ré-éxécute, le livre n'existe plus, je devrais avoir une 404 et là vous voyez que le résultat est aussi formaté en JSON.

Donc ce qu'on attend d'API Platform quand il y a une exception, on ne veut pas du HTML comme c'est le cas de base.

Alors là, je suis comme Montgomery Burns.

Excellent ! Tout fonctionne.

Sauf que vous êtes venus pour voir aussi comment on a fait pour faire en sorte que API Platform et Laravel soient compatibles.

J'ai un petit jeu pour vous.

Lequel de ces frameworks est le plus ancien ? Pour ceux qui ne connaissent pas CodeIgniter, c'est un fork de Ruby on Rails en PHP. On peut dire ça.

J'ai pas mis Zend, ça aurait été trop facile.

Alors qu'est ce que vous en pensez ? Symfony ? Qui dit Symfony. Qui dit...

Laravel ? Ok. CakePHP ? Ah ouais quand même ! Pourtant, c'est à quelques mois d'écart que CakePHP est sorti avant Symfony.

Pourquoi je vous parle de ça ? Parce que moi, la première fois que j'ai utilisé Laravel, c'était il y a dix ans quand je comparais Laravel et CakePHP pour faire un projet de blog.

Voilà, pourquoi pas . On a tous fait un quand on a commencé.

Et du coup, quand je pense à Laravel, je pense à...

Je me suis fait un petit mind mapping de ce à quoi je pense. Je pense aux façades, je pense aussi aux contrôleurs.

Je vois que dans la documentation de Laravel, on propose beaucoup de créer une route, créer un contrôleur, etc.

On a des sucres syntaxiques, j'ai l'impression que des fois c'est ce qu'on entend.

Oui, il y a beaucoup de sucre syntaxique dans Laravel.

On a du coup des méthodes statiques et bien entendu.

l'ORM Eloquent.

Un petit tour sur les façades.

Pour ceux qui ne connaissent pas, c'est un moyen d'accéder à un service.

Ce qui est intéressant, c'est que dans la documentation, il y a écrit qu'il faut faire attention en utilisant les façades parce qu'on peut vite avoir trop de services qui sont utilisés au sein d'une classe et que c'est forcément pas forcément bien.

On recommande d'ailleurs dans la documentation d'utiliser le système d'injection de dépendance plutôt que d'utiliser des façades.

J'ai remarqué, enfin, j'ai aussi observé que dans Laravel, vous avez une injection de dépendance comme dans Symfony.

Vous avez un genre d'autowiring si dans votre constructeur vous avez les bonnes interfaces, il va automatiquement vous mettre les bons services dedans, ce qui est très pratique.

Concernant les helpers, ces sucres syntaxiques, vous en avez plein.

Moi j'en ai utilisé quelques uns.

J'ai utilisé config notamment...

Enfin voilà, ça c'est assez pratique, on aime ou on n'aime pas.

Mais, Laravel c'est aussi toute une série d'outils dans l'écosystème qui sont très très utilisés.

Par exemple, Forge pour gérer ses serveurs, ou on va avoir des outils qui sont plutôt côté client, qui vont vous générer du code.

On a toute une sorte d'outils autour de Laravel qui forment un écosystème très très riche.

Ça c'est que les outils officiels.

Mais il y a aussi plein, plein d'outils de la communauté Laravel derrière.

Et dans Laravel on retrouve aussi.

Des moyens de faire ce qu'ils appellent des ressources.

Par exemple, vous voyez un resource controller.

Alors quand on déclare un resource controlleur, ça va nous générer un CRUD avec plusieurs routes qu'on peut, ou ensuite dans notre contrôleur, on va pour chaque route avoir une méthode et pouvoir implémenter quelque chose ici.

Vous voyez aussi qu'on a une ressource dans Eloquent.

Ça, ça va nous permettre de faire une transformation de données et de dire Voilà, cette ressource ou ce modèle Eloquent, quand je veux le requêter sur une API, je veux que ces champs.

Et ça, c'est la manière qui est recommandée dans la documentation.

Alors, je vous montre ça et vous allez me dire Mais du coup, pourquoi est ce qu'on a besoin d'avoir API Platform ? On a déjà ça.

Oui, mais API Platform, ça va plus loin que ça.

C'est des formats standards comme le JSON LD, Hydra, Hal, pas que standards mais aussi qui sont hypermédias.

On va y revenir.

C'est de la documentation automatique, par exemple avec Open API.

On a aussi un support de GraphQL.

Beaucoup, beaucoup de choses.

C'est très portable, on a des fields, de la pagination.

On a plusieurs systèmes de persistance Elasticsearch, Doctrine, même Doctrine avec MongoDB et ça reste très extensible.

Quand on parle d'API hypermédia, on peut se le représenter, qu'il y a beaucoup de liens qui se font entre les données.

Ça peut être des liens en interne sur notre API, mais aussi des liens vers l'extérieur.

Ici, vous voyez un exemple de JSON LD où l'auteur, c'est un lien vers une ressource auteur.

Tout en bas, je vous ai mis aussi un petit en-tête Link qui va beaucoup nous servir dans API Platform.

Celui là, il permet de dire cette ressource, elle est documentée sur cet endpoint-là de mon API.

Grâce à ce lien, avec API Platform, on a des outils comme ça.

Donc là, c'est un outil d'administration qui va lire votre documentation et automatiquement générer cette interface là.

Vous allez pouvoir avoir des filtres, des tris, vous allez pouvoir avoir des formulaires dynamiques, etc.

Tout ça c'est basé sur React Admin et c'est complètement extensible.

Avec API Platform, on a aussi un Client Generator, on est assez fiers de ça.

Ça va lire votre documentation. C'est pas que compatible avec API Platform ce que je vous raconte là, c'est compatible avec toutes les API qui sont documentées soit avec Open API, soit avec Hydra.

Là, ici, le client generator va pouvoir vous scalfolder des systèmes Front.

Donc là vous voyez un formulaire à gauche en React, à droite, on a même du React native, ça supporte Next.js, ça supporte Vue.Js... Tout un tas de frameworks.

Et même là récemment, on peut générer des structures Rust depuis la documentation d'Open API, donc des outils très très très puissants.

Maintenant qu'on a vu pourquoi, comment est ce qu'on peut brancher API Platform sur Laravel ? L'idée ce serait d'utiliser des composants d'API Platform et de les brancher sur Laravel.

Nous, on avait vraiment envie que ça continue d'être très magique, c'est à dire qu'on déclare une ressource sur un modèle et ça marche.

Donc ça c'est vraiment l'objectif principal que je me suis fixé ici.

On veut toujours que les utilisateurs de Laravel puissent étendre et configurer API Platform et du coup, on va sûrement avoir besoin de créer un contrôleur API Platform.

Ça tombe bien, API Platform 3.2 est sorti.

Et dans cette nouvelle version, j'ai refactoré pas mal de code d'API Platform avec dans le but premier de libérer API Platform du kernel HTTP de Symfony.

Donc là, en deux mots, comment API Platform c'est construit ? On a le kernel de Symfony et on va avoir des écouteurs d'événements à plusieurs étapes de la requête où on va se brancher pour gérer la négociation de contenu, lire la donnée, l'écrire, la deserialiser, etc.

Grâce à cette pull request que vous voyez là, on a extrait cette logique dans ce qu'on va appeler des providers et des processors.

Un provider, c'est quoi ? C'est un des concepts phares d'API Platform.

Un provider, comme vous le voyez ici, c'est le moyen d'apporter l'état de votre ressource.

Ici, quand on récupère un livre, on veut que le provider renvoie ce livre.

Donc là, j'ai fait un new book avec l'identifiant de ce livre.

Ensuite, ce provider, on peut le brancher dans notre source en utilisant juste dans l'attribut provider où on spécifie la classe dans laquelle on a déclaré la manière de récupérer l'état.

Ces providers là maintenant dans API Platform 3.2 vous en avez plusieurs.

Il y a le ContentNegociationProvider qui va gérer la négociation de contenu, est ce qu'on veut du HaL, du du JSON API, JSON LD, AccessChecker pour la sécurité, ReadProviders va récupérer la donnée dans Doctrine ou un autre système de base de données, Deserialize si vous avez fait un POST va transformer la requête en JSON en objet PHP, ValidateProvider pour la validation.

On a la même chose au niveau des processorss.

Les processors, c'est là où on va récupérer votre objet et en faire quelque chose, que ce soit l'envoyer par mail, le mettre dans une base de données et ainsi de suite.

Cette interface là, de la même manière que le provider peut se brancher sur n'importe quelle opération d'API Platform : Get, Post, Put ou une ApiResource même.

Dans API Platform 3.2 maintenant, on a aussi plusieurs processors.

On WriteProcessor qui va persister la donnée ou la supprimer.

Dans le cas d'un delete, Serialize pour vous afficher du JSON, Respond, il transforme l'objet livre par exemple en réponse HTTP ou le JSON il va rajouter, les entêtes etc.

AddLink pour ajouter des en-têtes de liens, et une mécanique de cache pour ajouter des en-têtes de cache.

Tout ça, si on le met dans un contrôleur, ça nous donne ça.

Donc là c'est un peu simplifié, mais on a notre contrôleur qui est appelé.

D'abord, on va appeler la chaîne des providers.

pour faire toute la résolution dont j'ai parlé tout à l'heure, puis on va renvoyer toute la chaîne des processors jusqu'à obtenir une réponse HTTP.

Ça, c'est vachement bien parce que ça va me permettre de mettre API Platform dans n'importe quel cadriciel qu'on veut.

Il y a un autre truc qui est arrivé avec API Platform 3.2, c'est le Subtree split.

On a tous les composants d'API Platform qui sont maintenant disponibles en tant que paquets indépendants.

Si vous allez sur Packagist, vous pouvez regarder.

Il y a vraiment tous les paquets d'API Platform disponibles.

Ça m'a d'ailleurs permis de créer un petit playground que vous pouvez ouvrir dans votre navigateur : API Platform Playground.

Il n'y a rien à installer, vous pouvez tester API Platform dans le navigateur.

Maintenant qu'on a vu tout ça, c'est bien beau, API Platform est disponible sous forme de provider processor, on a un subtree split...

Maintenant, il faut mettre tout ça dans Laravel.

On va commencer par aller lire la documentation, et dans la documentation de Laravel, on retrouve dans les concepts d'architecture tout ce dont j'ai besoin.

On a des notions de kernel HTTP, on a des notions d'injection de dépendances avec un service provider, on a de la middleware HTTP, on peut faire vraiment plein de choses.

Un service provider dans Laravel, ça ressemble à ça.

Vous avez une fonction Register qui est appelée au démarrage de votre application ou lorsque vous exécutez le PHP.

Et on va utiliser ici, nous, trois méthodes : singleton.

On va donner la classe et un callback dans lequel on va mettre l'instance qu'on veut déclarer dans ce singleton.

Pour récupérer une dépendance, on va utiliser make, donc app que vous voyez là, ou application c'est le conteneur, le conteneur de service.

Et la dernière méthode que j'ai beaucoup utilisée, c'est bind qui va me permettre de dire que pour une interface donnée, on va injecter tel singleton. Par exemple si vous le mettez dans un constructeur.

Vous avez ici la déclaration de tous les services qu'API Platform a besoin pour fonctionner avec la plupart de ces fonctionnalités.

On voit que j'ai utilisé principalement singleton, bind et make. Et, on voit aussi d'autres petites choses.

Il y a des tags, il y a la possibilité de taguer des services. Et, aussi on voit qu'on peut utiliser config.

Donc là, vous voyez que j'ai utilisé config pour récupérer le titre, la description, la version de votre API.

Et ça j'ai trouvé ça bien bien pratique.

On continue ? Pour cette configuration justement, vous avez juste à, dans la fonction boot, c'est toujours dans le provider, on peut publier le fichier de configuration à l'installation.

Là c'est très bien, vous avez juste un tableau PHP dans un fichier, et puis ça c'est mis sur les les projets des utilisateurs lorsqu'on exécute artisan vendor:publish.

Ça, j'ai vraiment trouvé ça très très sympa et très accessible.

Pour la suite, j'ai dû brancher le système de persistance qui ici est Eloquent.

Pour faire ça, j'ai de nouveau créé un provider et je lui ai dit tiens, quand on va récupérer mon livre, on va faire dix applications make, la classe Livre, find avec les variables, donc les urivariables, c'est toutes les variables que vous avez dans votre URL.

Là, sûrement un et je récupère le premier.

Pareil, là je vous ai mis un exemple de la persistance.

Je sais que data est un modèle Eloquent.

On va le voir tout de suite, comment j'ai fait, et je fais saveorfail et puis data refresh et je renvoie data.

Ah ouais d'ailleurs, tout ça, je le met dans un contrôleur, le API Platform Controllor, là, vous voyez que j'ai réutilisé les concepts Provider et Processor.

Et ensuite je dois brancher tout ça.

Comment on fait ? Dès qu'on détecte un ApiResource sur un modèle, on a dans API Platform ce qu'on appelle un système de métadonnées.

Dans le système de métadonnées, ça nous donne toutes les classes et toutes les opérations. Pour chaque opération, je suis venu déclarer une route Laravel et je lui ai branché le contrôleur que vous venez de voir.

Avec ce système de métadonnées, effectivement, on doit enregistrer les routes dans Laravel.

Il nous reste bien sûr le Error Handler.

Vous l'avez vu un petit peu au début.

Et on peut détecter aussi, est ce que la ressource qui est déclarée est un modèle Eloquent ? Dans ce cas là, on va automatiquement lui dire si tu n'as pas encore déclaré de provider, récupère le provider automatique d'API Platform.

Bien entendu, en plus de ça, j'ai mis SwaggerUI pour vous faire la petite démo de tout à l'heure, SwaggerUI qui est bien apprécié de nos développeurs pour regarder une documentation Open API, pour la visualiser en tout cas.

Et une fois qu'on a fait tout ça.

php artisan route:list. Artisan, c'est un peu comme dans le monde Symfony, le binaire Symfony.

Et on voit qu'on a la liste des routes qui sont déclarées automatiquement.

Vous voyez aussi qu'on a d'autres routes, contextes, docs, errors ça, ça va être pour les systèmes internes d'API Platform pour surtout l'auto-discoverabilité de votre API.

Alors malgré tout ça, il reste quand même beaucoup, beaucoup de travail à faire.

On n'a pas encore implémenté la pagination et les filtres, GraphQL on va le rajouter aussi, mais là c'est juste rajouter, brancher quelques services, ça va fonctionner.

Je me suis dit que pour la communauté Laravel, ce serait intéressant de brancher les providers et processors que je vous ai montrés en tant que middlewares HTTP que les développeurs pourraient brancher directement sur leur contrôleur.

Il nous reste aussi la validation à faire et la sécurité.

Peut être encore d'autres choses que j'ai oublié de mettre sur cette slide.

Alors, j'avais envie de vous faire aussi un retour de mon utilisation de Laravel.

Cela faisait un moment que je n'en avais pas fait.

J'ai bien apprécié le fait qu'on ne soit pas obligé d'utiliser le sucre syntaxique et qu'on puisse faire de l'injection de dépendance. En fait il y a souvent des alternatives pour faire la même chose.

Ça c'est cool.

On a des fois un doute avec Laravel, on se dit oui, le conteneur...

Je sais qu'il y a eu des débats conteneurs, performances...

C'est pas vraiment important parce que déjà avec Laravel par exemple, vous avez Laravel Octane qui va lancer votre kernel, le garder en mémoire et puis du coup ça change rien.

Maintenant, il y a beaucoup beaucoup de fonctionnalités. On peut faire absolument tout ce qu'on a besoin et c'est c'est très très bien Laravel quand vous voulez aller assez vite dans vos développements. C'est super bien documenté, vraiment, la documentation est vraiment superbe.

Et avec Eloquent, il n'y a pas de propriétés donc faut s'adapter un petit peu et on doit trouver d'autres mécanismes qui sont peut être un peu différentes de ce qu'on a l'habitude de voir avec Doctrine.

D'ailleurs, une question qu'on peut se poser, là, dans ce que vous avez vu sur Laravel API Platform, vous avez bien les propriétés qui sont mappées avec les bons types dans des schémas JSON, par exemple sur votre documentation.

Alors pour faire ça, je me suis basé sur la commande artisan model show book qui va venir me lister les propriétés.

J'ai pris le code, j'ai copié collé, ça fonctionne.

On peut peut être revenir dessus. Pour l'instant, il faut se dire que c'est plutôt un prototype qui fonctionne mais on voudrait mettre des mécanismes en place un peu plus évolués pour pouvoir vraiment configurer API Platform comme on le fait aujourd'hui avec Symfony.

On a plein d'idées, je vais rejoindre le discord de Laravel, j'ai discuté avec quelques personnes qui font du Laravel pour vraiment leur proposer des manières de faire et voir quels sont leurs retours aussi par rapport à ça.

Comment j'essaye ? Parce que oui, vous avez peut être envie d'essayer.

Alors là, il y a une pull request qui est ouverte sur API Platform avec le code que j'ai présenté ici et, sur cette PR, il y a la liste des étapes à faire pour l'installer.

Aujourd'hui, je ne l'ai pas encore publié, c'est sur un fork à moi, mais ça s'installe en remplaçant quelques paquets dans Composer.

Avec API Platform, aujourd'hui avec la 3.2, normalement la version 2.7, elle est tombée en End of life (EOL), elle ne devrait plus être utilisée.

On a lancé un crowdfunding pour pouvoir financer une version long term stable d'API Platform, donc si ça vous intéresse ou si vous pensez à des gens qui pourraient être intéressés par ça, n'hésitez pas à aller voir sur Open Collective pour nous aider à financer API Platform.

Je voulais aussi annoncer ici que, du coup j'ai parlé de Laravel Octane tout à l'heure, on est en train d'ajouter le support de, enfin c'est fait, il ne manque plus que la PR à faire, de FrankenPHP sur Octane.

On est partenaire officiel de Laravel chez Les-Tilleuls.coop, il y a peu de gens qui le savent mais Les Tilleuls, il y a aussi des experts Laravel chez Les Tilleuls.

On est complètement en mesure de vous accompagner sur ce genre de projet.

Et bien entendu, on a maintenant API Platform avec Laravel qui arrive.

Je ne peux pas vous donner de date précise reste à voir comment, comment on l'utilise, qu'est ce qu'on met en place, avant vraiment de le publier. Il faudrait faire des code review aussi.

Sur ce, je vous remercie pour votre attention, je pense que j'ai une petite dizaine de minutes pour des questions, mais j'ai un train à 17 h du coup.

Voilà.

On va peut être un moment couper court aux questions.

Merci.

Du coup, est ce qu'il y a des questions ? Super ! Merci pour la présentation.

Moi de mon côté j'ai déjà pas mal utilisé Laravel sur des projets aussi, et là pour l'instant dans la démo il y a une seule ressource.

Je reviens pas sur les histoires de performances du conteneur, mais c'est est ce que dans l'avenir vous imaginez une solution différente pour pouvoir intégrer les routes à la volée, quand il y aura, j'en sais rien.

10, 40 ressources différentes sur le projet.

Non, je ne pense pas.

Alors il faut savoir que j'en ai un peu parlé, mais dans API Platform, on a un système de métadonnées où on va collecter vraiment toutes les informations sur vos ressources.

Ça nous ce sera mis en cache, c'est sûr, c'est toujours mis en cache.

Après, pour la déclaration de route, j'imagine que c'est dans le container que c'est mis, et du coup si le conteneur est gardé en mémoire avec les nouvelles choses qui arrivent comme FrankenPHP, il y aura peu d'impact en fait.

Je pense que ce sera entièrement viable, il n'y aura pas de soucis.

Bonjour, si on souhaite migrer notre API d'un Symfony à Laravel, à combien il est estimé le temps de développement pour cette migration avec cette compatibilité ? Ça dépend de beaucoup, beaucoup beaucoup de choses.

Est ce que tu utilises Doctrine ? Est ce que tu utilises un système de persistance à toi ? Moi je pense que là, avec ce qu'on a fait, on pourrait même brancher Doctrine sur API Platform x Laravel, ça va fonctionner par exemple.

En fait c'est juste copier coller les fichiers sources et là il y a clairement il manque des fonctionnalités.

J'ai pas testé de faire des relations entre les ressources, pour info, j'ai commencé à coder ça quand le sujet a été accepté donc c'est c'est assez récent on va dire ! Donc, là tout de suite, je te déconseille de le faire maintenant dans un an, ce sera, ce sera entièrement faisable.

Maintenant, est ce qu'il y a vraiment un intérêt à faire ça ? Je sais pas.

Si ton projet marche déjà, gardez ce qui marche, s'il vous plaît, refaites pas les trucs qui marchent.

Il y a une question devant.

Merci. Merci pour la présentation.

Ce serait pour savoir la séparation d'API Platform en tout un tas de composants, c'est quelque chose qui était prévu à la base, on va dire dans la roadmap d'API Platform, ou c'était vraiment quelque chose pour éprouver, pour rendre compatible Laravel et prouver tout ça ? Ou alors c'était aussi la possibilité de faire un Symfony API Platform sans par exemple la partie Hydra ? Ouais, complètement.

En gros, depuis depuis que je travaille sur...

Depuis que PHP 8 est arrivé avec les nouveaux attributs et qu'on a voulu vraiment retravailler la DX d'API Platform, on savait déjà à ce moment là qu'on voulait faire un subtree split. Mais on ne pouvait pas tant qu'on n'avait pas clarifié certaines choses dans notre code, où était quoi, etc.

Depuis déjà pratiquement un an, enfin depuis que la version 3 est sortie, on a déjà des composants qui étaient dispo en subtree split, notamment le composant Open API, et là, ça fait même un an qu'on travaille à en migrer petit à petit, des composants.

Mais c'est un travail très très très difficile.

Parce que si, quand je bouge des classes d'ailleurs, j'ai cassé des interfaces récemment, mais quand on bouge des classes, il y a des mécaniques à faire dans PHP, et PHP nous aide pas vraiment à pouvoir déplacer une classe, dire celle là, elle dépréciée et tout.

Il faut faire des bidouilles dans tous les sens.

Donc c'est un travail très très dur qui est très très long.

Et du coup c'est pour ça que là, ça arrive petit à petit, mais qu'on n'a pas tout fait d'un coup et dans tous les cas, c'était le but que vous pouviez par exemple utiliser un Symfony avec juste le serialiser JSON LD mais vos contrôleurs à vous, ou alors que vous vouliez le support de GraphQL sans le reste, etc etc.

Donc clairement ça n'a rien à voir avec Laravel.

Il s'avère que ça nous aide pour faire ça, donc c'est tant mieux.

Salut et merci beaucoup pour la presentation très intéressante, au niveau du processus décisionnel, déjà assez général sur API Platform, la décision architecturale, le moment où vous choisissez justement de splitter, de faire une nouvelle version, etc.

Et là, plus précisément sur la partie Laravel, comment se passe le processus décisionnaire ? C'est l'idée de quelqu'un qui est approuvée par d'autres ? En étant lead dessus, le poids que tu vas avoir en disant je veux partir là dessus, etc.

Un petit peu le contexte décisionnel autour de tout ça ? Alors en fait, je pense que le contexte décisionnel chez nous, il est beaucoup apporté par les retours qu'on a de la communauté.

C'est à dire qu'on a bien vu que notre travail sur les attributs était vraiment très très apprécié.

Donc on veut aller toujours dans ce sens là.

Et du coup c'est pareil pour toutes ces choses là.

Nous, on sait très bien que dans Laravel, il y a beaucoup beaucoup d'utilisateurs de Laravel.

C'est un des framework les plus utilisés au monde et du coup, on trouvait ça dommage qu'ils ne puissent pas bénéficier de nos outils aussi.

Et donc ça, depuis le début API Platform, c'était au début, c'était un bundle Symfony, mais parce qu'on réutilise des composants de Symfony comme le fait d'ailleurs Laravel, il y a des composants de Symfony dedans.

Et nous, l'objectif, c'était vraiment d'apporter ces standards au plus grand nombre et ensuite de pouvoir faire en sorte qu'on puisse l'utiliser partout dans tous vos projets PHP.

On réfléchit même des fois à se dire, tiens, est ce qu'on ne ferait pas des API Platform dans d'autres langages ? Parce qu'aujourd'hui, il y a peut être un framework en Java qui est assez proche de ce qu'on fait, nous, avec API Platform, mais dans le reste des écosystèmes, des langages, il y a peu de choses où il y a autant de fonctionnalités.

Enfin, nous on le voit, API Platform, c'est énormément utilisé et ça marche.

Donc voilà, je pense que le contexte décisionnel est plus porté à ça.

Maintenant, on est plusieurs de la core team chez Les Tilleuls, ça nous simplifie aussi les discussions, etc.

On a des ADR, on essaye d'en faire des architectures decision records qui vont nous aider à façonner notre pensée.

Genre vraiment, le travail que vous voyez là, c'est un aboutissement d'au moins 2 ou 3 ans de travail et d'échanges, et de réflexion et de, je code un truc, mais en fait je code un autre truc et je code un autre truc jusqu'à ce qu'on soit nous-mêmes satisfaits.

On le propose et on espère que ça plaît.

J'espère que je réponds à la question ? Merci beaucoup Antoine.

Merci