Le 10 septembre, c’était la première édition de l’API Platform Conference organisée en simultané à Euratechnologies, à Lille, et en ligne. Pour la première fois, la communauté d’API Platform s’est retrouvée pour une journée de conférences de haut niveau sur ce framework de création d’API basé sur Symfony. Plusieurs développeurs de l’équipe de SensioLabs ont fait le déplacement et SensioLabs était sponsor Gold de l’événement. Retrouvez un résumé des talks qui nous ont le plus marqués.

 

Opening Keynote: The future of API (Platform) architecture

Kévin Dunglas, le créateur d’API Platform, nous a, dans un premier temps, ramené aux genèses du projet. Au fil de l’histoire du projet, il a pu nous présenter un avant-goût des différentes conférences auxquelles nous allions assister durant la journée.

Pour ce premier événement sur APIP il fallait une annonce pour marquer le coup. Nous avons été servis, Kévin nous a présenté sa vision d’une nouvelle architecture pour la création d’API côté back-end : ESA pour Edge Side API . Cette architecture reprend le concept de JAMStack côté front, le but étant d’avoir des applications au plus proche de l’utilisateur, utilisant au maximum les fonctionnalités de caching pour éviter le plus possible les calculs côtés back. En distribuant les applications sur plusieurs serveurs à travers le monde, comme on pourrait le faire avec un cdn côté front, on réduit la distance avec l’utilisateur ce qui nous permet de gagner en performance.

Même si cette architecture est innovante et pleine de promesses, reste à voir si le gain de performance vaut vraiment la complexité de l’infrastructure.

 

The journey towards API Platform 3

Dans cette conférence, Antoine Bluchet nous a fait un tour d’horizon de API Platform et notamment des derniers changements qui ont eu lieu. Le système de subResources qui posait quelques soucis a été revu de fond en comble. Le but a été de simplifier l’expérience développeur et faciliter la gestion des sub resources. Ces changements arrivent avec API 2.7, l’ancienne manière étant toujours disponible mais dépréciée. La version 3 de API Platform arrive donc avec une nouvelle gestion de sub resources (notamment la suppression de @APISubResources), des nouvelles clés dans les annotations des ressources et la possibilité de déclarer plusieurs ressources pour une même entité.

 

The API mindset: tech, product, business and legal

Après un bref historique depuis l’idée de départ de réutilisation des routines logicielles au monde moderne où les applications interagissent entre elles, Mehdi Medjaoui aborde comment penser ce qu’est une API et ce à quoi elle est destinée. L’API est aujourd’hui un produit, il faut donc l’imaginer comme tel et garder en tête des choses telles que son intégration au monde extérieur, son mode de consommation, sa monétisation, ses différents acteurs et son côté légal (privacy, terms of services).

 

Sylius and API Platform. The story of integration

Łukasz Chrusciel nous explique comment est en train d’être intégré API Platform dans Sylius. L’une des premières problématiques qui ressort est comment faire cohabiter API Platform avec Sylius qui est très extensible. En prenant un exemple simple, il nous montre qu’ajouter un attribut #[ApiResource] n’est pas suffisant car il est difficile de gérer les différents besoins métiers de cette manière. Pour garder une séparation entre couches applicatives, leur choix s’est porté sur l'utilisation de Commandes / Handlers via le composant Messenger. Les amateurs de CQRS s’y reconnaîtront sûrement !

Łukasz a ensuite listé quelques recommandations comme, par exemple, d’intégrer toutes les informations nécessaires à une commande pour être traitée. Cela étant indispensable si vous voulez passer certains traitements en asynchrone par la suite. S’en est suivi une explication rapide du principe d’enrichissement afin d’ajouter des informations à vos commandes. N’hésitez pas à jeter un œil du côté de la classe CommandAwareInputDataTransformer !

Pour en revenir à API Platform, Łukasz a, lui aussi, expliqué les avantages d’utiliser les IRIs pour lier différentes ressources. En effet, les valeur de l’option /api/v2/shop/product-option-values/COLOR_BLUE peuvent être récupérées facilement par une application alors que ne retourner que COLOR_BLUE nécessite de savoir comment interroger l’API pour le même résultat.

Deuxième partie, et non des moindres, l’utilisation des tests comme outil de migration. Sylius ayant déjà ses tests Behat, il suffit d’une annotation pour tester un API nouvellement créée. Comment ?

Prenons par exemple la fonctionnalité de login. La step “I log in” pour un test @ui consiste à se connecter depuis la page de login (ce qui est somme toute logique). En ajoutant le tag @api, cette step passe maintenant par l’équivalent API. Evidemment, ce n’est pas sans un surcoût de complexité mais cela permet de réutiliser des spécifications existantes.

Le talk se termine par des exemples de tests PHPUnit qui ont pour charge de vérifier que les réponses respectent le contrat. Notons l’utilisation de la classe ApiTestCase ou encore de la librairie PHPMatcher que j’affectionne particulièrement.

Pour les curieux, ou les motivés, l’API est toujours en cours d'implémentation ici : New Sylius API on API Platform.

 

How To Become A React-admin Grandmaster In 237 Easy Steps

Le CRUD… Qui n’en a pas déjà fait et n’en refera pas encore ? Vous devez justement développer votre backend ? Jetez un coup d'œil à React-Admin !

François Zaninoto nous a présenté en 237 étapes (peut-être un peu moins en fait) comment en tirer le meilleur pour réaliser très rapidement un back-end sous forme de SPA qui en jète !

React-Admin propose une multitude de composants qui vont vous permettre de customiser le rendu de votre page pour y ajouter un tableau triable, des filtres, de l'accessibilité, de la validation de données et j’en passe !

Des hooks ont également été présentés. Ils permettent d’intégrer facilement un comportement à votre composant à la sauce React. Même si vous êtes allergiques au JS (oui, oui, je vous connais), n’hésitez pas à faire un tour sur la documentation de cette fonctionnalité apportée en version 16.8.

Toujours pas convaincu ? Imaginez qu’une colonne de votre tableau nécessite un appel à l’API pour être affichée. Un tableau de 30 lignes provoquera logiquement 30 appels API car chacun est fait depuis le composant rendu. Et bien non, le composant ReferenceField est assez malin pour grouper ces calls en un seul pour utiliser dataProvider.getMany() une fois au lieu de dataProvider.getOne() 30 fois.

Le tout codé via TypeScript pour vous faciliter encore plus la tâche !

 

Symfony Runtime: wrapping API Platform in a lambda

L’idée de départ de décorréler l'exécution de son contexte (super globales par ex) a conduit à la création du composant Runtime chez Symfony et à la nouvelle forme du front controller de Symfony (public/index.php). Ce nouveau front controller ne sert plus qu’à déclarer une lambda qui va englober toute l'exécution de la stack Symfony. L’intérêt pour l’équipe Symfony, c’est d’avoir le contrôle sur la mise à jour de ce front controller, tout en laissant la possibilité de garder une flexibilité sur cette couche de la stack au travers des concepts de Runtime et de Runner. Le Runtime et le Runner sont des interfaces PHP pour lesquelles plusieurs implémentations existent déjà, pouvant être réutilisées et étendues.

 

A suitable serialization with API Platform and Symfony

Dans ce talk, Mathias Arlaud (un Alumni de SensioLabs) a commencé par nous rafraîchir la mémoire sur le fonctionnement de la sérialisation via Symfony juste avant de passer à son utilisation par le biais d’API Platform.

La balade commence tranquillement avec un exemple concret d’une API gérant les activités plus ou moins officieuses d’un robot envoyé sur Mars. Nous y avons abordé tous les moyens qui nous sont mis à disposition pour adapter au mieux le retour de nos APIs.

  • Gérer la visibilité ou les droits d’écriture sur une propriété via des attributs PHP.
  • Utiliser des groupes de sérialisation pour retourner au client les infos qui lui seront nécessaires.
  • Utiliser ApiProperty::security pour sécuriser certaines propriétés. Attention à ne pas l’utiliser sur une ressource susceptible d’être cachée et partagée.
  • Comment choisir entre une configuration par défaut ou au cas par cas

Nous sommes ensuite entrés un peu plus dans le vif du sujet en explorant comment ApiPlatform procède pour formater les données que nos controllers retournent. Car, oui, nul besoin ici de retourner une Response ou encore de formater ses données en JSON-LD, ApiPlatform s’en charge !

Mathias nous amène ainsi vers deux moyens de customiser la logique de normalisation : les ContextBuilder et les ResourceMetadataFactory qui peuvent s’avérer de redoutables alliés notamment pour ajouter un comportement commun à diverses ressources en quelques lignes de code.

La balade se termine par un exemple d’utilisation de DTO (Data Transfer Object) dans votre API. Idéal pour du DDD (Domain Driven Design) ! Promis, j’arrête de mettre un acronyme tous les 10 mots.

Bien que les prochaines versions d'API Platform réduisent la sérialisation à un usage plus basique (cf. Opening Keynote: The future of API (Platform) architecture), cela pourra toujours vous sortir de certaines situations plus complexes. Merci à Mathias pour la balade ! Pour ceux qui y ont accès, ce talk est également disponible parmi les replays du SymfonyLive Online French Edition.

 

French tech & Start up Nation, what else?

De la présentation d’une coopérative à l’éthique au travail, durant ce talk d’Hélène Maître-Marchois nous avons remis en cause beaucoup de choses.

Et si le salaire n’était pas si important ? Il est vrai qu’aujourd’hui l’argent et le salaire sont des points importants dans le choix d’un poste, mais des développeurs sont aujourd’hui friands de nouvelles connaissances pour apprendre de nouvelles choses dans un environnement qui le permet.

Il existe bel et bien des développeurs qui préfèrent baisser leur salaire pour intégrer une entreprise prometteuse que de choisir une entreprise moyenne avec un salaire plus important. Le choix est à eux, l’éthique viendra jouer ici un grand rôle et pèsera dans la balance.

Outre le salaire, le choix d’une mission ou d’un nouveau client est aussi un point sur lequel elle a appuyé. Il est possible de dire non, si on ne se retrouve pas dans les valeurs du client ou d’une mission pourquoi se forcer ? Un nouveau client arrive avec une offre juteuse, difficile de dire non et pourtant elle nous a raconté comment elle et son équipe ont refusé un client malgré l'appât du gain qu’offrait le contrat car celui-ci ne correspondait pas à l’éthique de l’entreprise.

Clôturés par des débats qui en ont fait sauté la pause de l’après-midi, ce talk amène à réfléchir sur son rôle dans l’entreprise, ses valeurs et son éthique personnelle et professionnelle.

 

Rendez-vous l'année prochaine pour la seconde édition de l'API Platform Conference en 2022 !