A adoção de React Native pela Coinbase

Recentemente, um desenvolvedor da Coinbase compartilhou no Twitter que o novo app da Coinbase foi escrito em RN, o que gerou um pequeno burburinho (https://twitter.com/htormey/status/1392161714250993667). Agora, mais detalhes sobre isso foram publicados em um artigo no Medium. Segundo a thread relacionada, embora existam alguns módulos nativos, cerca de 97% da base de código do app é TypeScript.

A seguir, uma tradução resumida do conteúdo original:

• Migração para RN em uma situação em que já existiam apps nativos para iOS e Android. Durante o processo, foi necessário reimplementar um enorme app nativo com mais de 200 telas, e também foram oferecidas aulas internas de RN para ajudar mais de 30 engenheiros nativos existentes na transição.

• Depois de muito esforço, em comparação com a era nativa, todos os principais indicadores foram mantidos ou melhorados, incluindo métricas de performance, métricas de negócio, nota do app, porcentagem de usuários sem crash em 7 dias, tempo de Cold Start e tempo de troca entre abas.

• O primeiro app foi lançado em 2013, e por volta de 2017 havia pequenas equipes separadas para Android e iOS, mas contratar era muito mais difícil do que para desenvolvedores web, e a equipe sentia que as tecnologias de plataformas nativas não acompanhavam a produtividade impulsionada pela evolução das tecnologias web. Após algumas tentativas fracassadas, em 2018 ficou claro que era necessário melhorar a velocidade de iteração e a taxa de crescimento da plataforma mobile.

• A Coinbase decidiu repensar do zero como construía produtos. As principais features eram organizadas por funções, com 2 pessoas de backend + 2 pessoas de cliente para cada plataforma (Web, Android, iOS), o que exigia gente demais para uma única vertical. A partir disso, passou-se a pensar em reduzir o número mínimo de desenvolvedores por equipe de feature de 8 para algo em torno de 5, e em como permitir que desenvolvedores de cliente cobrissem várias plataformas.

• Com isso, esperava-se flexibilizar os requisitos mínimos de composição das equipes, permitir um desenvolvimento mais eficiente e aumentar os pontos de contato entre desenvolvedores de cliente. Claro, eficiência por si só não bastava; a empresa entendia que a performance e a qualidade percebidas pelo cliente também precisariam melhorar para justificar esse investimento.

• Na época, já existia uma equipe web bastante madura baseada em React. Após avaliar várias opções multiplataforma, a Coinbase escolheu RN por se apoiar em uma tecnologia já familiar e por parecer oferecer um caminho claro para integrar web e mobile. Como também era preciso migrar apps nativos que já estavam em operação, houve alguns meses de avaliação técnica prévia e definição de estratégia para realizar uma migração gradual e sem grandes impactos.

• Primeiro, concluíram que seria melhor começar por um greenfield, onde RN e nativo não precisassem se integrar. Dentro da Coinbase, decidiram criar primeiro como app um produto web chamado Pro, que ainda não existia no mobile e era complexo internamente, com muitos recursos em que performance era importante, como gráficos de preço em tempo real e depth chart. A suposição era que, se conseguissem construir bem o Pro em RN, então o restante das funcionalidades, menos complexas e com requisitos de performance menos rígidos, também poderia ser migrado sem grandes problemas.

• Em seguida, implementaram em RN o fluxo de onboarding compartilhado entre o Pro e o app existente e o acoplaram ao app nativo já em produção. Como a diversidade de regiões atendidas tornava o onboarding uma das partes mais complexas do app, era uma área difícil demais de mexer anteriormente. Havia também a expectativa de que, ao recriá-lo no Pro, isso ajudaria na refatoração do app existente.

• Por fim, com base na experiência e no conhecimento obtidos nas duas etapas anteriores, reescreveram o app nativo existente em RN. No momento de planejar, ainda não estava claro se isso se tornaria um full rewrite ou um aumento gradual da participação de RN dentro do app nativo, e a decisão seria tomada com base nos resultados das duas fases anteriores.

• Depois de definir a estratégia, lançaram o app mobile do Pro em outubro de 2019, e o resultado foi melhor do que o esperado. Os resultados de negócio foram bons, aprenderam onde surgiam problemas de performance e como resolvê-los, ficaram muito satisfeitos com a produtividade oferecida por RN e também confirmaram que engenheiros web conseguiam ser produtivos em RN em pouco tempo.

• Incentivados por isso, também começaram a reescrever o fluxo de onboarding, e novamente atingiram as metas tanto de negócio quanto de qualidade do app.

Embora o resultado da reescrita do onboarding em si tenha sido bom, perceberam que integrar RN ao app existente era difícil.

A produtividade também era pior do que trabalhar só com web ou só com nativo, e surgiram engenheiros dos dois lados pensando algo como “se é assim, por que usar RN?”. (Muito parecido com o caso do Airbnb, e eles de fato aprenderam bastante conversando com engenheiros do Airbnb.)

• Como resultado, a partir dessas lições concluíram que a abordagem brownfield, mantendo nativo e RN juntos, era a raiz de todos os problemas, e decidiram reescrever completamente o app existente em RN.

• Entre as duas plataformas, consideraram que a migração do app Android seria mais difícil em termos de performance, desempenho e produtividade, então escolheram Android como primeiro alvo da reescrita. Com base na experiência anterior, estimaram que um full rewrite levaria cerca de 6 meses, mas acreditavam que os benefícios superariam os custos.

• Em março de 2020, iniciaram a reescrita do app Android, e de fato levou cerca de 6 meses. A reescrita do iOS veio em seguida e terminou em janeiro de 2021. Em ambas as plataformas, os principais indicadores mostraram bons resultados.

• Em meados de 2020, a Coinbase tinha 18 engenheiros de iOS e 7 de Android. Em maio de 2021, o repositório RN da Coinbase já contava com 113 contribuidores, incluindo muitos engenheiros web que antes não podiam contribuir para o mobile.

• O treinamento para converter engenheiros nativos em engenheiros de RN aconteceu sem grande atrito, e os engenheiros com background nativo estão atualmente tendo alto desempenho no app RN. Ainda não está tudo perfeito, mas, como esperado inicialmente, cada organização de feature está gradualmente se transformando em um único “time de cliente” capaz de cobrir todas as plataformas cliente.

• As plataformas, que antes eram três (React, iOS, Android), passaram a ser duas (React, RN), mas o próximo passo é tentar reduzir isso para 1,5. Estão planejando compartilhar entre web e RN um design system, uma camada comum de dados baseada em GraphQL e tooling de infraestrutura. A visão é permitir que um único engenheiro consiga entregar features para web e mobile em todas as plataformas com o mínimo possível de troca de contexto.

• No futuro, pretendem compartilhar mais artigos sobre RN, incluindo desafios técnicos e os aprendizados obtidos nesse processo.

[budlebee]

Isso me lembra a história da adoção de RN pela Laftel.

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

[xguru]

Parece ser um texto que pode ajudar bastante também as empresas daqui. Obrigado pelo resumo traduzido!