Video Summary and Transcription
El orador habla sobre su experiencia en el desarrollo de aplicaciones React Native y su objetivo de ofrecer altos niveles de valor de producto. Querían construir nuevas características tanto para la aplicación Facebook Messenger como para la aplicación nativa, por lo que exploraron la posibilidad de compartir código entre las dos plataformas. Intentaron compartir un archivo de colores de marca utilizando enlaces simbólicos y espacios de trabajo de Yarn, pero encontraron problemas. En última instancia, decidieron duplicar el código compartido y reescribirlo con una estricta seguridad de tipos.
1. Desarrollo de aplicaciones React Native y código compartido
Hola, mi nombre es Oli y soy uno de los ingenieros front-end y líderes técnicos en Clio. Voy a hablar brevemente hoy sobre una de las experiencias que tuvimos al comenzar nuestra nueva aplicación React Native en Clio hace un par de años y específicamente sobre un experimento que hicimos para tratar de lograr altos niveles de entrega de valor del producto y impulsar nuestra misión de luchar por la salud financiera del mundo. Clio comenzó como un chatbot de Facebook Messenger donde los usuarios podían hacer preguntas sobre su dinero y recibir respuestas sobre sus finanzas. Clio necesitaba una interfaz de usuario, y esto se presentó en forma de varias SPAs de React accesibles a través de Messenger mediante vistas web y impulsadas por nuestro backend de Ruby on Rails. Sin embargo, identificamos dos problemas con esto. El primero fue que construir sobre Messenger es un gran riesgo comercial y estábamos a merced de Facebook y su tipo de aplicación para un administrador de finanzas personales salvaje que vive dentro de su ecosistema. Entonces, naturalmente, como un pequeño equipo de desarrolladores de React que cubren el producto principal, elegimos React Native para construir la próxima versión de Clio. Pero volviendo al problema en cuestión, ahora teníamos usuarios divididos entre Facebook Messenger y la aplicación nativa, a ambos de los cuales queríamos desarrollar nuevas funciones y brindar la mejor experiencia de producto posible. La pregunta que nos planteamos fue: ¿podríamos construir esto una vez dentro de nuestro monorepo y hacerlo funcionar en ambos productos web y nativos? ¿Podríamos compartir los tipos, la lógica empresarial y los elementos visuales en las dos plataformas, de manera que reduzcamos a la mitad la cantidad de trabajo requerido para entregar nuevas funciones? La respuesta corta es que no muy fácilmente, pero por favor no me dejes aquí. Realizamos un experimento. Lo redujimos a un solo desafío. ¿Sería posible compartir un solo archivo que contenga un objeto constante de nuestros colores de marca entre la aplicación web y la nativa? Como mencioné antes, tenemos un monorepo que contiene el código web, la aplicación nativa y el backend de Rails, por lo que cualquier solución tendría que funcionar con eso. Nuestro primer intento involucró SimLinks. Seguramente esto podría ser tan simple como usar un enlace simbólico para hacer referencia al archivo compartido dentro de la ruta de cada proyecto y en cuestión de minutos teníamos la web mostrando los colores del archivo compartido. Pasamos a React Native. Después de experimentar un poco, nos encontramos rápidamente con un problema. El primer problema en el Facebook Metro Bundler, GitHub, Metro no le gustan los SimLinks. Estábamos a punto de rendirnos. Afortunadamente, no habíamos invertido demasiado tiempo en este enfoque.
Hola, mi nombre es Oli y soy uno de los ingenieros front-end y líderes técnicos en Clio.
Voy a hablar brevemente hoy sobre una de las experiencias que tuvimos al comenzar nuestra nueva aplicación React Native en Clio hace un par de años y específicamente sobre un experimento que hicimos para tratar de lograr altos niveles de entrega de valor del producto y impulsar nuestra misión de luchar por la salud financiera del mundo.
Para describir el problema que enfrentábamos, comenzaré con una breve historia de Clio. Clio comenzó como un chatbot de Facebook Messenger donde los usuarios podían hacer preguntas sobre su dinero y recibir respuestas sobre sus finanzas. Por ejemplo, preguntar sobre su saldo o cuánto gastaron en Uber este mes o recibir una notificación cuando se excedieron del presupuesto porque gastaron demasiado en McDonald's. Rápidamente descubrimos que si bien la interfaz de texto y chat era excelente para interactuar con la voz de Clio, era insuficiente para cualquier cosa más complicada.
Clio necesitaba una interfaz de usuario, y esto se presentó en forma de varias SPAs de React accesibles a través de Messenger mediante vistas web y impulsadas por nuestro backend de Ruby on Rails. Puedes ver un ejemplo de cómo se ven esas vistas web en la captura de pantalla a la derecha.
Messenger funcionó muy bien para nosotros a medida que escalamos el producto y nos permitió lanzarlo en Estados Unidos y crecer rápidamente hasta alcanzar un millón de usuarios en solo un par de años.
Sin embargo, identificamos dos problemas con esto. El primero fue que construir sobre Messenger es un gran riesgo comercial y estábamos a merced de Facebook y su tipo de aplicación para un administrador de finanzas personales salvaje que vive dentro de su ecosistema. El segundo fue que Messenger limitaba mucho la experiencia del usuario que queríamos brindar a nuestros usuarios. Clio necesitaba la libertad visual para expresarse como ese amigo salvaje que vela por ti y tu dinero, y esto no era posible en Facebook Messenger.
Entonces, naturalmente, como un pequeño equipo de desarrolladores de React que cubren el producto principal, elegimos React Native para construir la próxima versión de Clio. Pudimos adquirir nuevas habilidades y comenzar a entregar la aplicación de React Native de Clio en un par de semanas, y hemos estado iterando en ella desde entonces. Clio tenía un nuevo hogar y puedes ver algunos de los diseños iniciales de la aplicación React Native a la izquierda, y avanzando rápidamente hasta los diseños más recientes y un ejemplo de cómo hemos aprovechado al máximo romper los límites de Messenger.
Pero volviendo al problema en cuestión, ahora teníamos usuarios divididos entre Facebook Messenger y la aplicación nativa, a ambos de los cuales queríamos desarrollar nuevas funciones y brindar la mejor experiencia de producto posible. Al evaluar dos diseños, como el que se muestra en esta diapositiva, comenzamos a ver similitudes en lo que queríamos construir y entregar, aquí ambos muestran listas de gastos agrupados por categoría, ambos provenientes de la misma API y ambos con los mismos tipos de TypeScript e incluso luciendo igual, los mismos iconos y la misma forma de presentar información.
La pregunta que nos planteamos fue: ¿podríamos construir esto una vez dentro de nuestro monorepo y hacerlo funcionar en ambos productos web y nativos? ¿Podríamos compartir los tipos, la lógica empresarial y los elementos visuales en las dos plataformas, de manera que reduzcamos a la mitad la cantidad de trabajo requerido para entregar nuevas funciones? Para nosotros, esto era el Santo Grial, un poder milagroso que proporcionaba felicidad, uso eterno en una abundancia infinita. La respuesta corta es que no muy fácilmente, pero por favor no me dejes aquí. Realizamos un experimento. Lo redujimos a un solo desafío. ¿Sería posible compartir un solo archivo que contenga un objeto constante de nuestros colores de marca entre la aplicación web y la nativa?
Como mencioné antes, tenemos un monorepo que contiene el código web, la aplicación nativa y el backend de Rails, por lo que cualquier solución tendría que funcionar con eso. Nuestro primer intento involucró SimLinks. Seguramente esto podría ser tan simple como usar un enlace simbólico para hacer referencia al archivo compartido dentro de la ruta de cada proyecto y en cuestión de minutos teníamos la web mostrando los colores del archivo compartido. Pasamos a React Native. Después de experimentar un poco, nos encontramos rápidamente con un problema. El primer problema en el Facebook Metro Bundler, GitHub, Metro no le gustan los SimLinks. Estábamos a punto de rendirnos. Afortunadamente, no habíamos invertido demasiado tiempo en este enfoque.
2. Desafíos con Yarn Workspaces y Código Compartido
Nuestro segundo intento se centró en los espacios de trabajo de Yarn. Configurar el archivo compartido como un paquete y agregar esa dependencia a los proyectos nativos resultó ser más complicado de lo esperado. Nos encontramos con una serie de problemas, desde la elevación de dependencias hasta la corrección de incompatibilidades de versiones. Quedó claro que invertir más tiempo en este enfoque no valía la pena por el impacto mínimo que tendría. Por lo tanto, decidimos volver a nuestro plan original de duplicar el código compartido cuando fuera necesario. Sin embargo, aprovechamos la oportunidad para reescribir el código con una estricta seguridad de tipos. Si tienes alguna idea sobre cómo abordar este problema, por favor házmelo saber.
Nuestro segundo intento se centró en los espacios de trabajo de Yarn. Nuestra teoría era que configurar el archivo compartido como un paquete y agregar esa dependencia a los proyectos nativos permitiría que se agruparan. No fue tan simple como pensábamos. En las pocas horas que dedicamos a esto, nos encontramos con una serie de problemas. No se elevaron las dependencias nativas, tuvimos que actualizar la configuración de Metro Bundler para manejar esas dependencias elevadas, actualizar los scripts de integración continua y despliegue para manejar los cambios, deduplicar las dependencias elevadas y corregir las incompatibilidades de versiones de las dependencias entre la web y la aplicación nativa. La lista iba creciendo y empezó a parecer un poco como un meme de Star Wars.
Estábamos avanzando, pero empezábamos a perder de vista nuestro propósito inicial, que era poder ofrecer funciones de manera más fácil y rápida a los usuarios, impulsar realmente el valor del producto y cumplir nuestra misión. Parecía ser un buen momento para apoyarnos en nuestros principios de ingeniería. Hacer lo más simple primero. Innovar en nuestro producto y no en nuestra pila tecnológica. Y utilizar tecnología que pueda ser útil y beneficiosa. Creo que al leer esto rápidamente se hizo evidente que probablemente habíamos ido un poco más allá. Y como probablemente puedas ver hacia dónde se dirige esto, nuestra búsqueda de este mítico Santo Grial estaba un poco en peligro. Y aunque estábamos seguros de que era posible lograrlo, rápidamente se hizo evidente que el tiempo continuo invertido en configurar y mantener esto probablemente no valía el pequeño impacto que podría habernos dado.
Así que volvimos a nuestro plan original de duplicar el código compartido cuando fuera necesario. Esto no resultó ser algo tan malo. En lugar de simplemente copiar y pegar el código, aprovechamos la oportunidad para reescribirlo con una estricta seguridad de tipos completa. Pero si alguien tiene alguna idea o pensamiento sobre otras formas en las que podríamos abordar este problema, me encantaría saber de ti, ya sea en la sesión de preguntas y respuestas o siéntete libre de enviarme un correo electrónico. Siempre estamos abiertos a nuevas ideas y mejoras en la forma en que entregamos funciones en Clio, y sería genial escuchar de ti. Muchas gracias por escuchar y espero que hayas disfrutado de la conferencia hasta ahora, y espero escuchar cualquier pregunta más adelante.
Comments