[:fr]La parole est aux speakers : Benoit VIGUIER[:]
[:fr]Jusqu’à l’AFUP Day 2020, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils ou elles aborderont lors de leur conférence !
La conférence
6play_API-v2-Final(1).docVotre API est confrontée à des contraintes techniques mais elle doit surtout répondre à vos problématiques métier qui ne cessent d'évoluer. Nous avons souvent vécu cette situation pour 6play (service de Replay du Groupe M6), et il nous a fallu plusieurs générations d'API avant d'arriver à une version adaptée à nos besoins. Micro-services, Rest/GraphQL, Developer eXperience… Un récit et des conseils pragmatiques pour concevoir et maintenir votre API. |
En ligne 24/06/2020 14:30-15:10 |
Tu es l’un des conférenciers les plus réguliers des évènements AFUP et nous t’en remercions ! Qu’est-ce qui continue d’animer ce sens du partage auprès de la communauté après toutes ces années ?
Lorsqu’on a un sujet à présenter qui nous tient à cœur c’est toujours un plaisir de le partager, surtout dans le cadre des évènements AFUP ! Je suis très content d’avoir pu être présent ces dernières années, mais cette régularité est aussi dûe à la chance : trouver un sujet qui m’intéresse, susceptible d’intéresser aussi les autres, de savoir comment le mettre en forme pour susciter l’attention du comité de sélection… Ça représente beaucoup de travail, de remises en question, qui finissent souvent par la déception de ne pas être retenu. Alors quand toutes les planètes sont alignées et qu’on a enfin l’opportunité d’aller jusqu’au bout, c’est une vraie satisfaction de pouvoir échanger avec les gens de la communauté qui ont les mêmes problèmes (ou les mêmes solutions). Et du coup on retente sa chance l’année d’après 🙂
Est-ce que le versionning des APIs permet d’être plus serein·e lorsqu’on conçoit une évolution, étant donné que cela peut autoriser plus facilement des ruptures et changements de comportements tout en limitant les effets de bords ?
De la manière dont je le pratique, le versionning d’API n’est rien de plus qu’une facilité de nommage pour éviter d’avoir à trouver un nouveau nom de domaine. En général on fait évoluer chaque API au maximum de ses capacités : on ajoute des routes, des nouveaux champs, parfois quelques nouveaux concepts, mais sans jamais casser nos contrats d’interface. Le jour où l’on se retrouve bloqué, où les évolutions deviennent trop coûteuses, ou que le besoin fonctionnel a divergé des motivations initiales, alors on réfléchit à une évolution majeure. C’est seulement à ce moment qu’on se pose la question philosophique (mais importante) de savoir s’il vaut mieux incrémenter le numéro de version, ou choisir un nouveau nom d’hôte pour API. Cette dernière solution est privilégiée quand le périmètre fonctionnel évolue de manière significative. La vraie difficulté, c’est de réussir à éteindre les vieilles versions pour de bon, car elles deviennent difficiles/coûteuses à maintenir et il est souvent difficile d’imposer ça aux utilisateurs. Le meilleur moyen reste de proposer une nouvelle API avec une vraie valeur ajoutée (plus de fonctionnalités, plus facile à utiliser, plus performante…) et de bien communiquer sur ces atouts. Pour l’anecdote, nous n’avons encore jamais dépassé la version 3 sur notre dizaine d’API, et nous avons réussi à éteindre une seule version 1.
Interface graphique, programmation asynchrone, tes différents retours montrent qu’on peut sortir des chemins balisés. Peux-tu donner un conseil, une méthode à une personne souhaitant utiliser un de ces outils de manière « non conventionnelle »?
Partir d’un besoin concret, qu’il soit professionnel ou personnel.
Regarder ce qui existe dans d’autres langages, faire de la veille, être curieux·se.
Avoir une bonne raison de le faire en PHP : c’est à partir de là qu’on prend des risques, surtout pour un projet professionnel. Si tout le monde utilise un marteau pour enfoncer des clous, pourquoi essayer avec autre chose? Il peut y avoir de vraies raisons, c’est au cas par cas… Mais j’avoue que pour mes projets personnels, je n’ai aucun remords à utiliser PHP à outrance juste pour le plaisir de faire tomber des préjugés !
Être prêt à être tout·e seul·e… C’est très rigolo d’être le·la premier·e à marcher dans la neige, mais si vous tombez sur un obstacle il n’y aura pas grand monde pour vous montrer le chemin. Dans mon cas, j’aime bien cette sensation que tout est à construire/imaginer, ça oblige à sortir de sa zone de confort et à revoir tout ce qu’on considère comme acquis sous un autre angle.
Proposer une conférence à l’AFUP bien sûr !
Une conférence présentée par
Benoit VIGUIER |
Lead Développeur Backend sur 6play, chez M6 Distribution. Initialement développeur 3D pour le jeu vidéo ou la CAO, mais reconverti dans le Web depuis 6 ans. Qu'importent les technologies, pourvu qu’on ait l'ivresse. |
Autres interviews
[:]