Coinbases Einführung von React Native

Kürzlich sorgte es für ein kleines Gesprächsthema, als ein Coinbase-Entwickler auf Twitter teilte, dass die neue Coinbase-App mit RN geschrieben wurde (https://twitter.com/htormey/status/1392161714250993667). Nun wurden dazu ausführlichere Details in einem Medium-Artikel veröffentlicht. Laut dem zugehörigen Tweet-Thread gibt es zwar einige native Module, aber etwa 97 % der App-Codebasis sollen aus TypeScript bestehen.

Im Folgenden eine zusammenfassende Übersetzung des Originalinhalts:

• Migration zu RN, obwohl bereits native iOS- und Android-Apps vorhanden waren. Im Verlauf der Migration musste eine riesige native App mit mehr als 200 Screens neu implementiert werden, und für die Umstellung wurden über 30 bestehenden nativen Engineers interne RN-Schulungen angeboten.

• Nach großem Aufwand konnten im Vergleich zur nativen Zeit alle wichtigen Kennzahlen gehalten oder verbessert werden: Performance-Metriken, Business-Kennzahlen, App-Bewertungen, der Anteil der Nutzer ohne Crash innerhalb von 7 Tagen, die Dauer des Cold Start und die Zeit für Tab-Wechsel.

• Die erste App erschien 2013, und um 2017 herum gab es jeweils kleine Teams für Android und iOS. Allerdings war Recruiting im Vergleich zu Web-Entwicklern viel schwieriger, und man hatte das Gefühl, dass native Plattformtechnologien bei der Produktivität nicht mit dem Entwicklungstempo von Web-Plattform-Technologien mithalten konnten. Nach mehreren gescheiterten Versuchen wurde 2018 klar, dass die Iterationsgeschwindigkeit und das Wachstum der Mobile-Plattform verbessert werden mussten.

• Coinbase entschied sich, grundlegend neu darüber nachzudenken, wie Produkte entwickelt werden. Für zentrale Features gab es funktionsorientierte Organisationen mit 2 Backend-Entwicklern plus je 2 Client-Entwicklern pro Plattform (Web, Android, iOS), sodass für eine einzige vertikale Funktion zu viele Leute benötigt wurden. Man begann sich zu fragen, ob sich die Mindestzahl von 8 auf etwa 5 Entwickler pro Feature-Team senken ließe und ob Client-Entwickler mehrere Plattformen zugleich abdecken könnten.

• Dadurch erwartete man geringere Mindestanforderungen an die Teamzusammensetzung, effizientere Entwicklung und mehr Berührungspunkte zwischen Client-Entwicklern. Natürlich reicht Effizienz allein nicht aus; zugleich mussten sich auch die vom Kunden wahrgenommene Performance und Qualität verbessern, damit sich diese Investition rechtfertigen ließ.

• Zu diesem Zeitpunkt gab es bereits ein recht ausgereiftes Web-Plattform-Team auf React-Basis. Nach Prüfung verschiedener Cross-Platform-Optionen entschied man sich für RN, da es auf vertrauter, bereits genutzter Technologie basierte und der Weg zu einer stärkeren Integration von Web und Mobile klar erschien. Da auch bereits laufende native Apps migriert werden mussten, ging dem eine mehrmonatige Phase technischer Vorprüfung und Strategieentwicklung voraus, um eine schrittweise und möglichst reibungslose Migration zu ermöglichen.

• Zunächst hielt man es für sinnvoll, mit einem Greenfield-Projekt zu beginnen, bei dem RN und Native nicht miteinander gekoppelt sein mussten. Daher entschied man sich, zuerst eine App für das Web-Produkt Pro zu bauen, das innerhalb von Coinbase als komplex galt, viele performancekritische Funktionen wie Echtzeit-Preisdiagramme und Depth Charts hatte und damals noch nicht mobil verfügbar war. Die Annahme war: Wenn sich Pro gut mit RN umsetzen lässt, können die übrigen Funktionen, die weniger komplex sind und geringere Performance-Anforderungen haben, ebenfalls problemlos migriert werden.

• Als Nächstes wurde der Onboarding-Flow, den Pro und die bestehende App gemeinsam nutzten, in RN implementiert und in die vorhandene native App integriert. Da der Onboarding-Bereich wegen der vielen bedienten Regionen einer der komplexesten Teile der App war, war er zuvor nur schwer anzufassen. Mit der Neuentwicklung für Pro verband man auch die Hoffnung, gleichzeitig die bestehende App zu refaktorieren.

• Abschließend wurde auf Basis der Erfahrungen und Erkenntnisse aus den beiden vorherigen Schritten die bestehende native App in RN neu geschrieben. Bei der Planung war zunächst noch offen, ob es ein vollständiger Rewrite werden oder eher eine schrittweise Erhöhung des RN-Anteils innerhalb der nativen App sein würde; die Entscheidung sollte von den Ergebnissen der ersten beiden Phasen abhängen.

• Nach Festlegung der Strategie wurde im Oktober 2019 die mobile Pro-App veröffentlicht, und das Ergebnis übertraf die Erwartungen. Auch die Business-Ergebnisse waren gut, man lernte viel über problematische Performance-Stellen und deren Lösungen, war mit der durch RN gebotenen Produktivität sehr zufrieden und bestätigte außerdem, dass Web-Engineers in kurzer Zeit auch mit RN produktiv werden können.

• Ermutigt davon begann man auch mit dem Rewrite des Onboarding-Flows; auch hier wurden die Ziele sowohl bei Business-Kennzahlen als auch bei der App-Qualität erreicht.

Das Ergebnis des Rewrites des Onboarding-Flows selbst war zwar gut, zugleich erkannte man aber, dass die Integration von RN in die bestehende App schwierig war.

Im Vergleich zu einer rein webbasierten oder rein nativen Entwicklung war auch die Produktivität schlechter, sodass auf beiden Seiten Engineers aufkamen, die sich fragten: „Wenn das so ist, warum verwenden wir dann überhaupt RN?“ (Das war dem Fall von Airbnb sehr ähnlich, und tatsächlich lernte man viel im Austausch mit Airbnb-Engineers.)

• Als Ergebnis dieser Erkenntnisse kam man zu dem Schluss, dass der Brownfield-Ansatz, Native und RN parallel mitzunehmen, die Wurzel aller Probleme war, und entschied sich deshalb dafür, die gesamte bestehende App vollständig in RN neu zu schreiben.

• Von den beiden Plattformen schien die Migration der Android-App in Bezug auf Performance, Produktivität und andere Faktoren schwieriger zu sein, daher wurde Android zuerst als Rewrite-Ziel gewählt. Auf Basis der bisherigen Erfahrungen schätzte man, dass ein Full Rewrite etwa 6 Monate dauern würde, erwartete jedoch, dass der erzielte Nutzen die Kosten übersteigen werde.

• Im März 2020 begann der Rewrite der Android-App und dauerte tatsächlich etwa 6 Monate. Der anschließende Rewrite der iOS-App wurde im Januar 2021 abgeschlossen. Auf beiden Plattformen zeigten die zentralen Kennzahlen gute Ergebnisse.

• Mitte 2020 hatte Coinbase 18 iOS-Engineers und 7 Android-Engineers. Stand Mai 2021 gibt es 113 Contributors im Coinbase-RN-Repository, darunter auch viele Web-Engineers, die zuvor nicht zu Mobile beitragen konnten.

• Das Training zur Umstellung nativer Engineers auf RN-Engineers verlief ohne große Reibung, und Engineers mit nativer Vorgeschichte erzielen derzeit starke Ergebnisse in der RN-App. Noch ist nicht alles perfekt, aber wie ursprünglich erhofft entwickelt sich jede funktionsorientierte Organisation in Richtung eines einzigen „Client-Teams“, das alle Client-Plattformen abdeckt.

• Aus drei Plattformen (React, iOS, Android) wurden zwei (React, RN), und als nächsten Schritt will man das auf 1,5 reduzieren. Geplant sind ein zwischen Web und RN geteiltes Design-System, eine gemeinsame datenbezogene Schicht auf GraphQL-Basis sowie geteiltes Infrastruktur-Tooling. Das Zielbild ist, dass ein Engineer mit minimalem Context Switching Features für Web und Mobile auf allen Plattformen ausrollen kann.

• Künftig sollen weitere Artikel zu RN erscheinen, etwa über technische Hürden und Erfahrungen aus diesem Prozess.

[budlebee]

Das erinnert mich an den Einführungsbericht von Laftel zu RN.

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

[xguru]

Das ist wirklich ein Artikel, der auch für Unternehmen hierzulande sehr hilfreich sein dürfte. Vielen Dank für die zusammenfassende Übersetzung!