La adopción de React Native en Coinbase

Recientemente, un desarrollador de Coinbase compartió en Twitter que la nueva app de Coinbase fue escrita con RN, lo que generó algo de conversación (https://twitter.com/htormey/status/1392161714250993667), y ahora se publicó una explicación más detallada en un artículo de Medium. Según el hilo relacionado, aunque sí existen algunos módulos nativos, alrededor del 97% del codebase de la app está en TypeScript.

A continuación, una traducción resumida del contenido original:

• Migraron a RN teniendo ya apps nativas para iOS y Android. Durante la migración tuvieron que reimplementar una enorme app nativa de más de 200 pantallas, y también ofrecieron capacitación interna sobre RN a más de 30 ingenieros nativos existentes para facilitar la transición.

• Después de mucho esfuerzo, en comparación con la etapa nativa, se mantuvieron o mejoraron todos los indicadores clave: métricas de performance, métricas de negocio, calificaciones de la app, porcentaje de usuarios sin crashes en 7 días, tiempo de Cold Start, tiempo de cambio entre tabs, etc.

• La primera app se lanzó en 2013, y hacia 2017 había equipos pequeños para Android e iOS, pero contratar era mucho más difícil que en web, y sentían que la productividad impulsada por la velocidad de evolución de las tecnologías web no estaba siendo alcanzada por las tecnologías nativas. Tras varios intentos fallidos, en 2018 quedó claro que era necesario mejorar la velocidad de iteración y la tasa de crecimiento de la plataforma móvil.

• Decidieron repensar desde cero cómo Coinbase construía producto. En las funciones principales, la organización funcional tenía 2 personas de backend + 2 clientes por cada plataforma (Web, Android, iOS), así que se necesitaba demasiado personal para una sola vertical. Empezaron a preguntarse si podían reducir el mínimo de desarrolladores por equipo de funcionalidad de 8 a unas 5 personas, y si los desarrolladores de cliente podrían cubrir varias plataformas.

• Esperaban que esto flexibilizara los requisitos mínimos de formación de equipos, permitiera desarrollar de forma más eficiente y aumentara los puntos de contacto entre desarrolladores de cliente. Claro, la eficiencia por sí sola no era suficiente; también pensaban que la performance y la calidad percibidas por el cliente debían mantenerse o mejorar para justificar la inversión.

• En ese momento ya existía un equipo web bastante maduro basado en React. Tras evaluar varias opciones cross-platform, eligieron RN porque se apoyaba en tecnologías familiares que ya usaban y porque parecía clara la ruta para integrar web y móvil. Como además tenían que migrar apps nativas que ya estaban en producción, pasaron varios meses en revisión técnica previa y definición de estrategia para lograr una migración gradual y sin sobresaltos.

• Pensaron que lo mejor era empezar por un greenfield que no necesitara integración entre RN y lo nativo. Dentro de Coinbase, decidieron convertir primero en app un producto web llamado Pro, que en ese momento no existía en móvil y que además era complejo dentro de la empresa, con muchas funciones donde la performance era importante, como gráficos de precios en tiempo real o depth charts. Asumieron que si podían construir bien Pro con RN, entonces el resto de funcionalidades (menos complejas y con requisitos de performance menos exigentes) también podrían migrarse sin mayores problemas.

• Después implementaron en RN el flujo de onboarding que compartían Pro y la app existente, y lo integraron en la app nativa actual. Debido a la diversidad de regiones de servicio, la parte de onboarding era una de las más complejas de la app, y por eso antes era demasiado difícil tocarla. Esperaban que al reconstruirla para Pro también sirviera como refactor de la app existente.

• Finalmente, con base en la experiencia y el conocimiento obtenidos en esos dos procesos, reescribieron la app nativa existente en RN. Al principio, al hacer el plan, no estaba claro si terminaría siendo un full rewrite o una estrategia de aumentar gradualmente la proporción de RN dentro de la app nativa; decidieron tomar esa decisión según los resultados de las dos etapas anteriores.

• Definieron la estrategia y en octubre de 2019 lanzaron la app móvil de Pro, y el resultado fue mejor de lo esperado. Los resultados de negocio también fueron buenos, aprendieron cuáles eran los puntos problemáticos de performance y cómo resolverlos, quedaron muy satisfechos con la productividad que ofrecía RN y además comprobaron que ingenieros web podían ser productivos en RN en poco tiempo.

• Animados por esos resultados, también iniciaron la reescritura del flujo de onboarding y, de nuevo, cumplieron sus objetivos tanto de negocio como de calidad de la app.

El resultado de la reescritura del flujo de onboarding fue bueno, pero se dieron cuenta de que integrar RN dentro de la app existente era difícil.

La productividad también era peor que trabajar solo en web o solo en nativo, así que aparecieron ingenieros en ambos lados pensando “entonces, ¿para qué usar RN?”. (Fue muy parecido al caso de Airbnb, y de hecho aprendieron mucho hablando con ingenieros de Airbnb).

• Como resultado, a partir de esas lecciones concluyeron que el enfoque brownfield de mantener juntos lo nativo y RN era la raíz de todos los problemas, y decidieron reescribir por completo la app existente en RN.

• Como pensaban que la migración de la app de Android sería más difícil que la de iOS en términos de performance, productividad y otros factores, eligieron Android como primer objetivo de reescritura. Con la experiencia previa estimaron que un full rewrite tomaría unos 6 meses, pero esperaban que los beneficios superaran el costo.

• En marzo de 2020 comenzaron la reescritura de la app de Android y efectivamente tomó unos 6 meses. Después, la reescritura de iOS que siguió terminó en enero de 2021. En ambas plataformas, los indicadores clave mostraron buenos resultados.

• A mediados de 2020, Coinbase tenía 18 ingenieros de iOS y 7 de Android. Para mayo de 2021, el repositorio de RN de Coinbase tenía 113 contributors, incluidos muchos ingenieros web que antes no podían contribuir al desarrollo móvil.

• La capacitación para que ingenieros nativos se convirtieran en ingenieros de RN avanzó sin demasiada fricción, y quienes venían de un background nativo actualmente están logrando un desempeño sobresaliente en la app RN. Todavía no es perfecto, pero, tal como esperaban al principio, en cada organización funcional se está formando un solo “equipo cliente” capaz de cubrir todas las plataformas cliente.

• Las plataformas pasaron de ser tres (React, iOS, Android) a dos (React, RN), pero como siguiente paso quieren reducir eso a 1.5. Están planeando compartir un sistema de diseño entre web y RN, una capa de datos común basada en GraphQL y tooling de infraestructura. La visión es que un solo ingeniero pueda desplegar funcionalidades en todas las plataformas web y móviles con el mínimo cambio de contexto posible.

• En el futuro planean compartir más artículos sobre RN, incluidas dificultades técnicas y aprendizajes obtenidos en el proceso.

[budlebee]

Me hace pensar en la historia de adopción de RN de Laftel.

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

[xguru]

Parece un artículo que podría ser de mucha ayuda también para las empresas locales. ¡Gracias por el resumen traducido!