BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Actualités Comment et Pourquoi Etsy a évolué vers une Architecture API-first

Comment et Pourquoi Etsy a évolué vers une Architecture API-first

Lors de QCon New York 2016, Stefanie Schirmer, ingénieur logiciel chez Etsy, a présenté comment son entreprise a réussi avec succès la transition vers une architecture API-first qui prend en charge plusieurs périphériques, traite les problèmes de performances côté serveur et qui a été rapidement adopté par les équipes de développement.

L'équipe d'ingénierie chez Etsy a établi sa réputation avec une architecture qui est optimisée pour le changement, qui facilite l'expérimentation continue et qui permet de déployer 50 fois par jour. Il pourrait être ainsi surprenant d'apprendre qu'ils avaient à faire à des problèmes graves de performance il y a quelques années.

Ayant un objectif de 1 000 ms temps d’affichage, leur équipe avait besoin de diminuer le temps de traitement côté serveur pour chaque requête côté client. Malheureusement, l'écosystème mono threadé de PHP ne permettait pas facilement les appels d'API concurrents, entraînant une lenteur due à l’exécution séquentielle. Schirmer et ses collègues avaient besoin de comprendre comment profiter de la concurrence, sinon ils risqueraient des problèmes de performance permanents. Pour compliquer l'affaire, il n'était pas clair si la cause origine de la dégradation des performances était suite à des problèmes de backend ou à la nature des demandes clients.

Malheureusement, l'équipe de développement ne pouvait pas travailler uniquement sur l'amélioration des performances. En plus de la mise à niveau et du support du site Etsy.com, les nouvelles fonctionnalités pour les applications mobiles nécessitaient plus d'extensibilité de la plateforme. Pour résoudre ces deux problèmes, l'équipe d'API devait adopter une nouvelle philosophie de conception, tout en gardant l'API familière et accessible aux équipes de développement.

Au lieu de se baser sur une seule API avec un ensemble fixe de paramètres, Etsy a créé une API à deux couches en utilisant des meta-endpoints. Similaire à un modèle utilisé par Netflix et ql.io d'eBay, chacun des meta-endpoints d’Etsy agrège plusieurs autres paramètres. Cela permet la composition côté serveur de bas niveau, les ressources à usage général dans les ressources device- ou view- spécifiques.

Toute la stack forme un arbre multi-niveaux, d'après la diapositive de Schirmer ci-dessous. La page d'accueil sur mesure consultée par le client est adaptée à une vue spécifique. Elle consomme simultanément une couche de méta-endpoints, qui à leur tour appellent les endpoints des composants atomiques. Seuls les composants de plus bas niveau, qui ne sont pas les méta-endpoints, sont en mesure d'interroger la base de données.


La couche de méta-endpoints a réduit la complexité pour composer la vue sur mesure, autant pour le site Web que pour les applications mobiles. Cependant, le traitement mono-threadé de plusieurs méta-endpoints ne répondrait pas aux exigences de performance. Les ingénieurs d’Etsy ont utilisé cURL pour faire des appels HTTP parallèles, ils sont allés plus loin jusqu'à patcher de la bibliothèque libcurl pour répondre à leurs propres besoins. Des outils personnalisés de suivi permettent de visualiser la hiérarchie d'appel d'une requête lors de sa propagation dans le framework, ce qui permet de détecter les points à problèmes.

Des outils internes supplémentaires ont été créés pour simplifier l'adoption de la nouvelle API. Etsy a en premier lieu généré automatiquement des API clients, qui connaissaient les paramètres exacts pour chaque endpoint, accompagnées de la documentation, le but étant de simplifier la courbe d'apprentissage pour les développeurs. Plutôt qu'une seule et unique approche de la formation, les équipes ont participé à des groupes de projets pilotes, laboratoires de code, ateliers “lunch and learn“ et jumelage avec développeurs expérimentés.

Schirmer estime que l'histoire qu'elle a présenté est une étude de cas sur les changements architecturaux, et transmissible vers d'autres systèmes. L'effort qui a été mis en œuvre et les services auxiliaires autour de l'API ont certainement aidé l'équipe de la plate-forme à « vendre » la nouvelle API auprès des développeurs. En réponse, Schirmer et ses collègues entretiennent la conversation avec les équipes de développement, afin de veiller à ce que le framework continue d'évoluer pour le bénéfice de tous.

Evaluer cet article

Pertinence
Style

Contenu Éducatif

BT