Cómo Coinbase reescribió la aplicación en React Native

Rate this content
Bookmark

El año pasado, nuestro equipo reescribió la aplicación de Coinbase de Android/iOS Nativo a React Native. La nueva aplicación se lanzó con éxito y con mayor calidad. Los ingenieros nativos fueron trasladados a React Native, y nuestra productividad ha aumentado. La charla compartirá nuestro viaje desde el inicio de la transición, cómo mitigamos los riesgos y las lecciones aprendidas.

30 min
22 Oct, 2021

Video Summary and Transcription

El año pasado, la aplicación de Coinbase fue reescrita de nativa a React Native debido a la complejidad de la arquitectura de la aplicación. Se eligió la aplicación de Android para la reescritura y se utilizó un enfoque Brownfield para integrar a los ingenieros de Android existentes. El proyecto comenzó en marzo de 2020 y tuvo lanzamientos exitosos tanto para Android como para iOS. La transición a React Native fue exitosa, con un aumento de los recursos de ingeniería y el desarrollo de nuevas funciones. Las recomendaciones para React Native incluyen tener en cuenta los requisitos de la aplicación, y la mejor pregunta fue sobre la división entre los módulos nativos y de la comunidad de React.

Available in English

1. Coibase App Rewrite in React Native

Short description:

El año pasado, la aplicación Coibase fue reescrita de nativa a React Native. La decisión de reescribir se basó en la complejidad de la arquitectura de la aplicación y los desafíos para realizar cambios sin regresión. El equipo enfrentó dificultades para coordinarse entre plataformas y contratar ingenieros nativos. Con un amplio grupo de talentosos ingenieros de JS, Coibase eligió React Native como solución. La reescritura comenzó con la aplicación de Android, que tenía menos características y un equipo más pequeño en comparación con iOS.

Hola a todos, soy Siri Wong, una gerente de ingeniería de Coibase. El año pasado, permití que la aplicación Coibase fuera reescrita de nativa a React Native, y hoy quiero compartir nuestra experiencia en este viaje. Así que hoy, voy a hablar sobre por qué reescribimos en React Native, y al principio, cómo abordamos la reescritura, la línea de tiempo del proyecto y los resultados clave, y luego compartir los desafíos y aprendizajes que tuvimos. Entonces, la primera pregunta es, ¿por qué reescribimos en React Native? A fines de 2019, observamos que nuestra velocidad para agregar una nueva función en la aplicación Coinbase no era muy buena. Para las funciones, tomaba varios meses en cada plataforma y mucha coordinación entre equipos. Esto no significa que la tecnología móvil nativa sea mala. Sin embargo, nuestra arquitectura de la aplicación era demasiado compleja y complicada para realizar cambios sin temor a las regresiones. La aplicación se había construido con muchos cambios a lo largo de muchos años. Intentamos solucionar la arquitectura, pero fue muy difícil arreglar los cimientos mientras teníamos mucha presión para construir una nueva función al mismo tiempo. Además, nuestros equipos en ese momento tenían alrededor de 8 personas en Android y 10 personas en iOS, divididos por plataforma en dos equipos. Esto también creaba desafíos de comunicación y consistencia. Por ejemplo, cuando construíamos funciones, necesitábamos verificar qué estaba haciendo otro equipo o plataforma. Y cuando había un error, necesitábamos verificar si ocurría en iOS, Android o ambos. La contratación también era otro desafío. Era realmente difícil contratar ingenieros nativos en comparación con ingenieros web en ese momento. Recuerdo que durante todo el año contratamos tal vez un ingeniero de Android o dos ingenieros de Android en ese momento. Intentamos convertir a algunos de los ingenieros web a Android, pero no tuvimos mucho éxito. Además, en Coibase en ese momento, teníamos un amplio grupo de talentosos ingenieros de JS. Teníamos muchos ingenieros de personal en el lado web. Eso hizo que React Native fuera una excelente opción para nosotros. Y con todo esto, estábamos pensando en reescribir nuestra aplicación principal de Coibase en React Native. Entonces, ¿cómo abordamos la reescritura? Primero, comenzamos con la aplicación de Android. ¿Por qué la aplicación de Android? En ese momento, nuestra aplicación de Android generaba menos de la mitad de los ingresos de iOS. La aplicación de Android también no tenía el mismo conjunto de funciones que iOS. Tenía muchas menos características. Y por lo tanto, era más fácil alcanzar la paridad de funciones. Además, teníamos menos personas en Android.

2. Reescritura de la aplicación de Android e integración

Short description:

La aplicación de Android fue elegida para ser reescrita en React Native debido a su complejidad y los desafíos de realizar cambios sin regresión. El equipo decidió adoptar un enfoque Brownfield, integrando a los ingenieros de Android existentes y capacitándolos en React Native. Estos ingenieros resultaron ser invaluables para el proyecto, con su experiencia tanto en el código existente como en los módulos nativos. Se creó un sistema de diseño basado en código para agilizar el desarrollo de la interfaz de usuario, y se establecieron métricas de control para garantizar el éxito del proyecto.

En comparación con la cantidad de ingenieros de iOS en ese momento. Por eso se eligió reescribir la aplicación de Android en React Native. Y veremos cómo sucede para React Native antes de pasar a iOS. En segundo lugar, estamos hablando de si debemos reescribir o hacer un enfoque Brownfield. Y decidimos hacer un enfoque Brownfield. Y como pueden ver, no vamos a reescribir o hacer un enfoque Greenfield debido a la complejidad. No es solo la complejidad, también hay varios otros desafíos. Por ejemplo, si tenemos una nueva función, debemos decidir qué función hacer en Nativo, qué funciones queremos hacer en React Native. Si modificamos las funciones existentes, ¿realmente debemos intentar convertirlas en React Native o Node.js? Esas son las preguntas que debemos responder si hacemos el enfoque Brownfield. Además, con el enfoque Greenfield, podemos crear un equipo separado que trabaje en la nueva aplicación, que esté separada de la aplicación existente. Por lo tanto, es más fácil reforzar los recursos necesarios para avanzar.

A continuación, integramos a los ingenieros de Android existentes en ese momento. El equipo original estaba compuesto por seis personas, y luego incorporamos a dos ingenieros de Android y los capacitamos en React Native. No habían trabajado en React Native con TypeScript antes, así que los capacitamos. Organizamos varias sesiones para diseñar la arquitectura de la nueva aplicación con el equipo de Android existente para aprender más sobre qué capa de datos vamos a utilizar, cómo manejar errores, navegaciones, enlaces profundos o cualquier peculiaridad nativa o módulos nativos que necesitemos escribir como parte de estas reescrituras. Luego creamos el documento de arquitectura y diseño para respaldar todos estos casos de uso actuales que tenemos en la aplicación existente. Por lo tanto, esos ingenieros, los ingenieros de Android, resultaron ser un valor increíble para el proyecto. No solo tienen contexto sobre cómo funciona la aplicación desde adentro hacia afuera, sino que también pueden consultar el código existente cuando los requisitos no están claros. Debido a que reescribimos desde cero, quiero decir que habrá muchas funciones que nadie conoce. También pueden trabajar en los módulos nativos ya que tienen experiencia en el lenguaje nativo, por lo que estos ingenieros de Android fueron clave para el éxito de nuestro proyecto. Antes de comenzar, también creamos el sistema de diseño basado en código que consta de primitivas como el color, el tema, la escala, la elevación, el diseño de espaciado y componentes como el control de botón de texto, las celdas de logotipo, las pestañas. Esos son los componentes clave, por lo que podemos construir la interfaz de usuario de manera mucho más fácil que construir una interfaz de usuario personalizada o tratar de adaptarla pantalla por pantalla. Y los ingenieros pueden centrarse en la funcionalidad en lugar de centrarse en la construcción de la interfaz de usuario, y como resultado, la interfaz de usuario es más consistente y se vuelve más pulida y de mayor calidad. Este sistema de diseño corporativo es la base que se utiliza y se mejora incluso hoy en día. Y lo último que hicimos fue establecer las métricas de control y la línea de tiempo al principio. Esto es muy importante para establecer las expectativas correctas, especialmente para la gerencia. Proporciona los hitos, la transparencia sobre cómo va el proyecto. Podemos evaluar el progreso del proyecto y tomar decisiones de continuar o detenernos en cualquier momento porque ya hemos establecido qué esperar. En cuanto a las métricas y los límites de control, es muy importante discutir, incluso antes de comenzar el proyecto, cómo se verá el éxito. Digamos que queremos lanzar la aplicación mañana, ¿cuáles serán las métricas? ¿Esperamos que las métricas se mantengan neutrales, aumenten o disminuyan, y cuánta disminución podemos tolerar? Especialmente para nuestra aplicación, cuánto

3. Cronograma del proyecto y resultados clave

Short description:

El proyecto comenzó en marzo de 2020, con el equipo desarrollando inicialmente pantallas nativas de Android e iOS. Después de alcanzar el primer hito en julio, obtuvieron más información y confianza en el éxito del proyecto. El lanzamiento de Android en octubre de 2020 fue exitoso, con métricas positivas de participación del usuario y rendimiento. Luego se desarrollaron las funciones faltantes para iOS y la aplicación se lanzó en enero de 2021. Los resultados clave mostraron un rendimiento mejorado, métricas comerciales aumentadas y calificaciones más altas de la aplicación. El equipo enfrentó desafíos con el déficit de rendimiento de React Native, pero se enfocó en la optimización.

Los ingresos de la empresa en las métricas que podemos tolerar, realizando la implementación gradual, por ejemplo. Por lo tanto, esto es realmente crítico para alinearse al principio. Voy a hablar sobre el cronograma del proyecto y los resultados clave. Comenzamos el proyecto en marzo de 2020. En ese momento, no sabíamos que la reescritura sería exitosa. Es por eso que pueden ver que aquí, en el cronograma, todavía continuamos desarrollando Android nativo. Seguimos construyendo pantallas nativas de iOS con funciones de iOS. Comenzamos a obtener más información cuando alcanzamos el primer hito, que es el grupo de pruebas internas en julio. Entonces teníamos lo básico mínimo que solo podía realizar transacciones y verificar precios. Así que pudimos ver, sentir y usarlo, ponerlo en manos de las personas dentro de la empresa. Comenzamos a obtener más información sobre la duración del proyecto y también a ganar más confianza en el éxito del proyecto. En ese momento, detuvimos el desarrollo nativo de Android. Pero seguimos desarrollando en iOS, porque no sabíamos si el lanzamiento de Android iba a tener éxito. Y luego, en octubre de 2020, estábamos listos y lanzamos Android, y fue realmente exitoso en términos de métricas, participación del usuario y también métricas de rendimiento. Después de eso, continuamos agregando todas las funciones faltantes que iOS ya tenía. Y luego lanzamos en iOS en enero de 2021. Por lo tanto, todo el proyecto tomó un poco menos de un año desde el principio. En cuanto a los resultados clave, seguimos varias métricas clave tanto en Android como en iOS. En cuanto al rendimiento, no hubo regresiones en el rendimiento que estamos monitoreando. El tiempo de inicio de las llamadas mejora. El tiempo de transición de toque y las fallas también se redujeron en las métricas clave del negocio. De hecho, aumentaron en todas las métricas que estamos monitoreando, incluidos los ingresos. Y la calificación de la aplicación para Android, la calidad de la aplicación es mayor que antes, por lo que la calificación aumentó de 3.8 a 4.4. Fue realmente una sorpresa en la reescritura del proyecto en su conjunto. Pensamos que iba a ser neutral, pero en realidad es aún mejor. Quiero compartir los desafíos y los aprendizajes del proyecto de la aplicación que tuvimos. El primero es claramente el rendimiento. Como saben, React Native tiene un déficit de rendimiento en comparación con las versiones nativas. Pusimos énfasis en el rendimiento desde el principio. Medimos el rendimiento temprano, tratamos de reducir la cantidad de renderizaciones, que es aproximadamente un 10%, y en ese momento, nuestra capa de datos utilizaba el hook de estado que llamaba a múltiples API en la misma pantalla y causaba muchas renderizaciones. Por lo tanto, hicimos mucho

4. Rendimiento de la aplicación, implementación y replataformización

Short description:

Para mejorar el rendimiento de la aplicación, agregamos algunas API principales durante el inicio en frío. Creamos una herramienta para rastrear las métricas de rendimiento y nos enfocamos en medir desde el principio. La implementación de la nueva aplicación fue un desafío, pero decidimos optar por un enfoque más simple y mitigar el lanzamiento utilizando el proceso de implementación lenta de Android. Antes de implementar, realizamos un programa beta y una encuesta cualitativa. El apoyo de la dirección es crucial y mostrar progreso y pequeñas victorias ayuda con los recursos y la comunicación. La replataformización de los ingenieros nativos existentes fue un desafío, pero teníamos un programa de capacitación y pautas para garantizar una transición exitosa.

Optimización en el lado del cliente. Fue como almacenamiento en caché y escribimos algunas de las API principales durante el inicio en frío para agregarlas en una sola API y mejorar el tiempo de inicio en frío. Como resultado, el rendimiento de la aplicación no se ha visto afectado en comparación con antes. Durante el proyecto, creamos una herramienta para rastrear el rendimiento. La clave es enfocarse y medir las métricas de rendimiento desde el principio.

El siguiente desafío es decidir cómo implementar la nueva aplicación. Hemos estado debatiendo si queremos implementarla como una aplicación totalmente nueva o una aplicación combinada que contenga tanto versiones nuevas como antiguas junto con el interruptor. Con la complejidad del cronograma, decidimos optar por el enfoque más simple implementando la nueva aplicación y mitigando el lanzamiento utilizando el proceso de implementación lenta de Android en Play Store. Definitivamente no es fácil medir el impacto, ya que no tenemos control sobre quién recibe la versión antigua y quién recibe la nueva versión. Pero nos ayudó a ahorrar mucho tiempo y mitigar el riesgo de implementación.

Antes de implementar, nivelamos el programa beta, también realizamos una encuesta cualitativa a las personas que participaron en este programa. Medimos la puntuación antes y después, también detectamos algunos errores en el proceso. Lo que aprendimos es que necesitamos involucrarnos antes y crear un programa beta y asegurarnos de entender cómo implementar y medir las métricas correctamente. Otra cosa que es realmente importante es el apoyo de la dirección. La reescritura, especialmente a esta escala, es un proyecto de un año de duración. Significa que no pudimos desarrollar una nueva función durante un año. Esto genera mucha presión. La clave es mostrar progreso y pequeñas victorias. Esto ayuda a la dirección y también ayuda con los recursos y la comunicación. Necesitamos comunicarnos con ellos y asegurarnos de hacer un seguimiento en cada hito.

Una vez que un proyecto avanza, la dirección debe incorporar a los ingenieros nativos existentes que no están trabajando en el proyecto. Necesitamos cambiar y detener el proceso de contratación cambiando de nativo a React Native y TypeScript. Durante la implementación, hubo momentos en los que tuvimos que tomar una decisión sobre si debíamos avanzar o no según las métricas. Establecer expectativas desde el principio, progreso constante y comunicación son clave para obtener apoyo y alineación de la dirección. Otro aprendizaje es la replataformización de los ingenieros nativos existentes. Si lo pensamos bien, un ingeniero nativo fue contratado por una empresa y ahora les pedimos que cambien y vuelvan a aprender el nuevo lenguaje y plataforma, el TypeScript y React Native. Teníamos un plan. Tenemos un programa de capacitación. Les brindamos apoyo y mentoría para garantizar que la transición sea exitosa. También proporcionamos pautas sobre cómo evaluamos el rendimiento individual de cada persona durante la transición para asegurarnos de no penalizarlos debido al cambio de plataforma y que no puedan operar al más alto nivel.

QnA

Transition Success and Performance Measurement

Short description:

Después de lanzar la aplicación, vimos éxito en la transición y desarrollo de funciones en React Native. Comenzamos con 20 ingenieros nativos y ahora tenemos más de 100 ingenieros. La transparencia y el apoyo durante la transición fueron clave. También respondimos preguntas sobre compartir componentes y funcionalidad entre sitios web, así como medir el rendimiento entre las dos aplicaciones.

La replataformización es definitivamente un desafío, pero factible. Y también en nuestro caso, tuvimos la suerte de no tener rotación de personal como parte de la transición. Después de lanzar, podemos ver el éxito de las personas, las transiciones y el desarrollo de funciones en React Native. Al comienzo del proyecto teníamos alrededor de 20 ingenieros nativos y ahora estamos contratando más ingenieros y aumentando el número a más de 100 ingenieros y seguimos creciendo. La clave es proporcionar transparencia a todos los ingenieros nativos existentes. Cómo los vamos a capacitar, cómo vamos a establecer las expectativas correctas durante la transición y cada hito, cuándo van a dejar de desarrollar en nativo en la aplicación existente, cuándo van a pasar a la nueva aplicación y cómo va a funcionar eso. Así que necesitamos brindarles apoyo durante la transición. Y esa es la historia de cómo reescribimos la aplicación CODES. Gracias.

Hola, qué bueno verte, bueno, verte en tu cara. Feliz de tenerte aquí, más o menos en Londres. Gracias por tu charla. Tenemos algunas preguntas interesantes de nuestra audiencia, así que vamos a entrar en ellas. Todos ustedes todavía pueden hacer preguntas y votar las preguntas que deseen que se respondan, por supuesto.

La primera pregunta es de Alice. ¿Consideraron compartir componentes y funcionalidad entre sus sitios web con React y esta nueva aplicación de React Native? Por supuesto, sí. Sabes, a largo plazo queremos lanzar la primera aplicación web en móvil, pero aún no estamos ahí. Primero necesitamos que el código se vea igual, usar las mismas tecnologías utilizando el sistema de diseño y también la capa de datos cuando las agreguemos en la lista de reproducción. Estamos lanzando en el mismo entorno, por lo que todo eso será mucho más fácil. Muy bien. Gracias. La siguiente pregunta es de Tom D. Es una buena pregunta. ¿Qué herramientas utilizaron para medir y comparar el rendimiento entre las dos aplicaciones? Sí, tenemos nuestro propio registro personalizado para comparar realmente el rendimiento. Pero inicialmente, simplemente hacíamos la comparación lado a lado y veíamos las diferencias de rendimiento obvias para poder solucionarlas. Pero en cuanto a las métricas que estábamos observando, una de ellas es el inicio en frío definitivamente. Y luego la carga de página o el cambio de pestaña que estamos utilizando. De acuerdo, gracias. La siguiente pregunta es de un usuario anónimo. Un recordatorio, si quieres ganar una camiseta, no debes publicar como anónimo, sino usar tu nombre real si estás aquí o tu ID de Discord si estás viendo de forma remota. Oh, esa fue la misma pregunta también sobre el rendimiento.

Code/Module Split and Training

Short description:

Alice preguntó sobre la división de código o módulos entre los módulos nativos y los módulos existentes de React Native. Utilizamos una combinación de ambos, incluyendo React Navigation y módulos personalizados para la biometría. Anna preguntó sobre el número de desarrolladores trabajando en el proyecto, que inicialmente comenzó con seis personas y creció a alrededor de 10 o 12. Con más de 100 desarrolladores ahora, la velocidad aumentada es evidente. Lauren preguntó sobre la capacitación de los ingenieros en el nuevo lenguaje, y aunque no ahorró tiempo para los ingenieros nativos existentes, fue beneficioso a largo plazo. La resistencia a la capacitación se abordó de manera transparente, lo que resultó en una exitosa conversión a React Native para la mayoría del equipo.

La siguiente pregunta es de Alice nuevamente. ¿Cuál es la división de código o módulos de tu aplicación entre los módulos nativos que has creado personalmente y el uso de los módulos existentes de React Native en la comunidad? ¿Puedes repetir la pregunta nuevamente? ¿Cuál es la división de código o módulos de tu aplicación entre los módulos nativos que has creado personalmente y el uso de los modelos existentes de React Native en la comunidad? Sí, utilizamos una combinación de ambos. Creo que utilizamos la navegación de React y algunos módulos personalizados que necesitamos utilizar, como por ejemplo, para la biometría. Por lo tanto, estos son módulos personalizados porque necesitamos realizar lógica personalizada allí. Así que hay una combinación de ambos.

De acuerdo, la siguiente pregunta es de Anna. Ella pregunta, veo que les llevó casi un año reescribir Coinbase. ¿Cuántos desarrolladores están trabajando en esto? Sí, inicialmente eran alrededor de seis personas, originalmente, y el equipo creció a medida que avanzaba el proyecto. Así que al final del proyecto, probablemente había alrededor de 10 o 12 personas. Así que, en promedio, si tomo un promedio, llevó a ocho desarrolladores un año. Sí. Sí. Muy bien, genial. Y ahora, por supuesto, tienes una mayor velocidad, porque solo tienes una base de código y todos los desarrolladores pueden trabajar en esa misma base de código. Sí, tenemos más de 100 desarrolladores en esta base de código. Genial.

Vamos a ver. La siguiente pregunta es de Lauren. ¿Tuvieron que capacitar a sus ingenieros en este nuevo lenguaje? Y si es así, ¿ahorraron tiempo a largo plazo en lugar de a corto plazo? Sí, creo que realmente capacitamos a muchas personas de Android y especialmente en iOS. Así que ahorrar tiempo para los ingenieros nativos existentes, no diría que realmente ahorró tiempo, pero se convirtieron correctamente. Queremos asegurarnos de que se configuren y midan correctamente, ¿verdad? Porque aprendiste el lenguaje nativo durante muchos años, y ahora debes aprender React Native. Pero el ahorro de tiempo es más a largo plazo, porque estamos contratando, en este momento, a más de 100 ingenieros en el cliente en sí. Eso es, como, una parte de ello, y también la velocidad que tenemos en la aplicación. La parte de la capacitación es, como, tal vez 10 personas o 15 personas, originalmente, que están en Nativo.

De acuerdo, y una pregunta para mí en el medio. ¿Encontraste alguna resistencia en el equipo de personas que no querían o realmente querían recibir capacitación como desarrolladores de React Native o JavaScript? Sí, totalmente. Creo que esto es algo que necesitábamos comunicar de manera transparente, porque como sabes, muchas personas pueden no querer realmente hacer React, o React Native, si haces Android, probablemente en general, o haces iOS, Swift, creo que lo clave es que necesitamos brindar el apoyo y asegurarnos de que tengan una capacitación, como cómo vamos a medir el rendimiento para todas estas personas. Así que, afortunadamente, todos necesitan realmente en React Native y se convierten con éxito, no tenemos ninguna rotación en sí, diría que tal vez una persona que quiere probar algo totalmente diferente, como backend y todo eso. De acuerdo, así que es bueno que el equipo estuviera bastante alineado todavía.

Recommendations for React Native and Best Question

Short description:

La construcción de aplicaciones en React Native depende de la aplicación. Para Coinbase, tiene sentido ya que el trabajo del lado del servidor y la interfaz de usuario son sencillos. Sin embargo, para juegos o aplicaciones con mucho contenido multimedia, React Native puede no ser adecuado. En cuanto a la mejor pregunta, destaca la relacionada con la división entre los módulos nativos y los módulos de la comunidad de React.

Muy bien, siguiente pregunta. ¿Recomendarías a partir de ahora construir todas tus aplicaciones en React Native o todavía hay ventajas en tener una aplicación nativa separada?

Sí, veo el beneficio de haber venido de la aplicación nativa y ahora estar en el mundo de React Native. Depende de la aplicación. Para la aplicación de Coinbase, creo que tiene sentido utilizar React Native. Realizamos muchas cosas en el lado del servidor y la interfaz de usuario es bastante sencilla en ciertos aspectos. Por lo tanto, si desarrollas juegos o algo que tenga mucho contenido multimedia, en ese caso, puede que no funcione para ese tipo de aplicaciones. Pero para nosotros, creo que funciona bien. Muy bien. Bueno, eso es todo el tiempo que tenemos para preguntas. Me gustaría que nominaras a un ganador para nuestra camiseta gratuita. Entonces, ¿cuál crees que fue la mejor pregunta? Bueno, no sé qué preguntas tenemos hasta ahora. Creo que las preguntas sobre tal vez el módulo nativo pueden ser realmente buenas. Sí, cuál es la división entre los módulos nativos y los módulos de la comunidad de React. Sí, exactamente. Esa fue la pregunta de Alice. Alice, ¿estás aquí? Alice, ven al escenario y te daré una camiseta.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt.In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
React Advanced Conference 2022React Advanced Conference 2022
22 min
Monolith to Micro-Frontends
Top Content
Many companies worldwide are considering adopting Micro-Frontends to improve business agility and scale, however, there are many unknowns when it comes to what the migration path looks like in practice. In this talk, I will discuss the steps required to successfully migrate a monolithic React Application into a more modular decoupled frontend architecture.
React Advanced Conference 2023React Advanced Conference 2023
22 min
Power Fixing React Performance Woes
Next.js and other wrapping React frameworks provide great power in building larger applications. But with great power comes great performance responsibility - and if you don’t pay attention, it’s easy to add multiple seconds of loading penalty on all of your pages. Eek! Let’s walk through a case study of how a few hours of performance debugging improved both load and parse times for the Centered app by several hundred percent each. We’ll learn not just why those performance problems happen, but how to diagnose and fix them. Hooray, performance! ⚡️
React Summit 2023React Summit 2023
24 min
Video Editing in the Browser
Video editing is a booming market with influencers being all the rage with Reels, TikTok, Youtube. Did you know that browsers now have all the APIs to do video editing in the browser? In this talk I'm going to give you a primer on how video encoding works and how to make it work within the browser. Spoiler, it's not trivial!

Workshops on related topic

React Advanced Conference 2022React Advanced Conference 2022
81 min
Introducing FlashList: Let's build a performant React Native list all together
Top Content
WorkshopFree
In this workshop you’ll learn why we created FlashList at Shopify and how you can use it in your code today. We will show you how to take a list that is not performant in FlatList and make it performant using FlashList with minimum effort. We will use tools like Flipper, our own benchmarking code, and teach you how the FlashList API can cover more complex use cases and still keep a top-notch performance.You will know:- Quick presentation about what FlashList, why we built, etc.- Migrating from FlatList to FlashList- Teaching how to write a performant list- Utilizing the tools provided by FlashList library (mainly the useBenchmark hook)- Using the Flipper plugins (flame graph, our lists profiler, UI & JS FPS profiler, etc.)- Optimizing performance of FlashList by using more advanced props like `getType`- 5-6 sample tasks where we’ll uncover and fix issues together- Q&A with Shopify team
React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
Top Content
WorkshopFree
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
React Summit Remote Edition 2021React Summit Remote Edition 2021
60 min
How to Build an Interactive “Wheel of Fortune” Animation with React Native
Top Content
Workshop
- Intro - Cleo & our mission- What we want to build, how it fits into our product & purpose, run through designs- Getting started with environment set up & “hello world”- Intro to React Native Animation- Step 1: Spinning the wheel on a button press- Step 2: Dragging the wheel to give it velocity- Step 3: Adding friction to the wheel to slow it down- Step 4 (stretch): Adding haptics for an immersive feel
React Summit Remote Edition 2021React Summit Remote Edition 2021
87 min
Building a Shopify App with React & Node
Top Content
WorkshopFree
Shopify merchants have a diverse set of needs, and developers have a unique opportunity to meet those needs building apps. Building an app can be tough work but Shopify has created a set of tools and resources to help you build out a seamless app experience as quickly as possible. Get hands on experience building an embedded Shopify app using the Shopify App CLI, Polaris and Shopify App Bridge.We’ll show you how to create an app that accesses information from a development store and can run in your local environment.
JSNation 2022JSNation 2022
41 min
Build a chat room with Appwrite and React
WorkshopFree
API's/Backends are difficult and we need websockets. You will be using VS Code as your editor, Parcel.js, Chakra-ui, React, React Icons, and Appwrite. By the end of this workshop, you will have the knowledge to build a real-time app using Appwrite and zero API development. Follow along and you'll have an awesome chat app to show off!
GraphQL Galaxy 2021GraphQL Galaxy 2021
164 min
Hard GraphQL Problems at Shopify
WorkshopFree
At Shopify scale, we solve some pretty hard problems. In this workshop, five different speakers will outline some of the challenges we’ve faced, and how we’ve overcome them.

Table of contents:
1 - The infamous "N+1" problem: Jonathan Baker - Let's talk about what it is, why it is a problem, and how Shopify handles it at scale across several GraphQL APIs.
2 - Contextualizing GraphQL APIs: Alex Ackerman - How and why we decided to use directives. I’ll share what directives are, which directives are available out of the box, and how to create custom directives.
3 - Faster GraphQL queries for mobile clients: Theo Ben Hassen - As your mobile app grows, so will your GraphQL queries. In this talk, I will go over diverse strategies to make your queries faster and more effective.
4 - Building tomorrow’s product today: Greg MacWilliam - How Shopify adopts future features in today’s code.
5 - Managing large APIs effectively: Rebecca Friedman - We have thousands of developers at Shopify. Let’s take a look at how we’re ensuring the quality and consistency of our GraphQL APIs with so many contributors.