Le passage de Coinbase à React Native

Récemment, un développeur de Coinbase a partagé sur Twitter que la nouvelle application Coinbase avait été écrite en RN, ce qui a suscité un petit buzz (https://twitter.com/htormey/status/1392161714250993667). Des détails supplémentaires ont ensuite été publiés dans un article Medium. D’après le fil de tweets associé, il existe bien quelques modules natifs, mais environ 97 % du code de l’application serait en TypeScript.

Voici ci-dessous une traduction résumée du contenu original :

• Migration vers RN alors qu’il existait déjà des applications natives iOS et Android. Pendant la migration, il a fallu réimplémenter une très grande application native de plus de 200 écrans, et plus de 30 ingénieurs natifs existants ont également bénéficié d’une formation interne à RN pour accompagner la transition.

• Après beaucoup d’efforts, les principaux indicateurs ont tous été maintenus ou améliorés par rapport à la période native : métriques de performance, indicateurs business, note de l’application, pourcentage d’utilisateurs sans crash sur 7 jours, temps de Cold Start, temps de changement d’onglet, etc.

• La première application est sortie en 2013, et vers 2017 il existait de petites équipes distinctes pour Android et iOS. Mais le recrutement était bien plus difficile que pour les développeurs web, et l’équipe estimait que les technologies des plateformes natives ne suivaient pas la productivité permise par la rapidité d’évolution des technologies web. Après plusieurs tentatives infructueuses, il est devenu clair en 2018 qu’il fallait améliorer la vitesse d’itération et la capacité de croissance de la plateforme mobile.

• Coinbase a décidé de repenser en profondeur sa manière de construire ses produits. Pour les fonctionnalités principales, l’organisation fonctionnait avec 2 développeurs backend + 2 développeurs client pour chaque plateforme (Web, Android, iOS), ce qui nécessitait trop de personnes pour une seule verticale. L’idée a donc émergé de faire passer la taille minimale d’une équipe feature d’environ 8 à 5 développeurs, et de voir s’il était possible que les développeurs client couvrent plusieurs plateformes.

• L’objectif était d’assouplir les exigences minimales de composition des équipes, de permettre un développement plus efficace et d’augmenter les points de contact entre développeurs client. Bien sûr, l’efficacité seule ne suffisait pas : il fallait aussi améliorer la performance et la qualité perçues par les clients pour justifier cet investissement.

• À l’époque, il existait déjà une équipe web React assez mature. Après avoir évalué plusieurs options cross-platform, Coinbase a choisi RN, à la fois parce qu’il reposait sur des technologies déjà familières en interne et parce qu’il offrait une voie claire vers une convergence du web et du mobile. Comme il fallait aussi migrer des applications natives déjà en production, plusieurs mois d’évaluation technique préalable et de définition de stratégie ont été nécessaires pour permettre une migration progressive et sans heurt.

• L’équipe a d’abord estimé qu’il valait mieux commencer par un projet greenfield ne nécessitant pas d’intégration entre RN et le natif. Elle a donc décidé de créer d’abord en application le produit web Pro, qui n’était alors pas disponible sur mobile et qui, même chez Coinbase, était considéré comme complexe, avec de nombreuses fonctionnalités sensibles aux performances comme les graphiques de prix en temps réel ou les depth charts. L’hypothèse était que si Pro pouvait être correctement réalisé en RN, alors le reste — moins complexe et avec des exigences de performance moins strictes — pourrait être migré sans difficulté majeure.

• Ensuite, l’équipe a implémenté en RN le flux d’onboarding partagé entre Pro et l’application existante, puis l’a intégré à l’application native existante. Comme les zones de service variaient selon les pays, la partie onboarding était l’une des plus complexes de l’application et aussi l’une des plus difficiles à faire évoluer. L’idée était qu’en la reconstruisant pour Pro, cela servirait aussi de refactorisation de l’application existante.

• Enfin, sur la base de l’expérience et des connaissances acquises dans les deux étapes précédentes, l’équipe a réécrit l’application native existante en RN. Au moment de planifier, il n’était pas encore certain qu’il s’agirait d’une réécriture complète ou d’une augmentation progressive de la part de RN dans l’application native ; la décision devait dépendre des résultats des deux premières étapes.

• Une fois la stratégie définie, l’application mobile Pro a été lancée en octobre 2019, avec des résultats supérieurs aux attentes. Les résultats business étaient bons, l’équipe a appris à identifier les points problématiques en matière de performance et leurs solutions, s’est montrée très satisfaite de la productivité offerte par RN, et a également confirmé qu’un ingénieur web pouvait devenir productif en RN en peu de temps.

• Forts de cet élan, ils ont aussi lancé la réécriture du flux d’onboarding, avec là encore des objectifs atteints à la fois sur le plan business et sur la qualité de l’application.

La réécriture du flux d’onboarding a donné de bons résultats en elle-même, mais l’équipe s’est rendu compte qu’intégrer RN dans l’application existante était difficile.

La productivité y était inférieure à celle d’un développement purement web ou purement natif, ce qui a conduit certains ingénieurs à se demander « dans ce cas, pourquoi utiliser RN ? ». (Le cas ressemblait beaucoup à celui d’Airbnb, et les échanges avec des ingénieurs d’Airbnb leur ont permis d’apprendre beaucoup.)

• Au final, à la lumière de ces enseignements, ils ont conclu que l’approche brownfield consistant à faire coexister natif et RN était à l’origine de tous les problèmes, et ont décidé de réécrire l’intégralité de l’application existante en RN.

• Des deux plateformes, la migration de l’application Android semblait la plus difficile en matière de performance, de performances globales et de productivité ; Android a donc été choisi comme première cible de réécriture. Sur la base de l’expérience acquise, une réécriture complète était estimée à environ 6 mois, mais les bénéfices attendus semblaient supérieurs au coût.

• La réécriture de l’application Android a commencé en mars 2020 et a effectivement pris environ 6 mois. La réécriture iOS qui a suivi s’est achevée en janvier 2021. Sur les deux plateformes, les indicateurs clés ont montré de bons résultats.

• À la mi-2020, Coinbase comptait 18 ingénieurs iOS et 7 ingénieurs Android. En mai 2021, le dépôt RN de Coinbase comptait 113 contributeurs, parmi lesquels de nombreux ingénieurs web qui, auparavant, ne pouvaient pas contribuer au mobile.

• La formation destinée à accompagner la transition des ingénieurs natifs vers des rôles RN s’est déroulée sans forte friction, et les ingénieurs issus d’un background natif obtiennent aujourd’hui de très bons résultats sur l’application RN. Ce n’est pas encore parfait, mais l’organisation évolue bien vers l’objectif initial : au sein de chaque équipe feature, une seule « équipe client » couvre l’ensemble des plateformes client.

• Le nombre de plateformes est passé de trois (React, iOS, Android) à deux (React, RN), mais l’étape suivante vise à descendre à 1,5. Sont prévus : un design system partagé entre le web et RN, une couche de données commune basée sur GraphQL, ainsi que des outils d’infrastructure mutualisés. L’objectif est qu’un ingénieur puisse déployer des fonctionnalités sur toutes les plateformes web et mobile avec un minimum de context switching.

• D’autres articles sur RN sont prévus à l’avenir, notamment sur les difficultés techniques rencontrées et les enseignements tirés du processus.

[budlebee]

Cela me fait penser au retour d’expérience de Laftel sur l’adoption de RN.

https://ridicorp.com/story/react-native-1year-review/

[xguru]

C’est un article qui pourrait aussi beaucoup aider les entreprises françaises. Merci pour ce résumé traduit !