Gestión de Funcionalidades con React

Hola a todos. Mi nombre es Fahad Hilal. Trabajo como Ingeniero Principal en la empresa DAZN. Nos dedicamos a la transmisión de deportes y muchas otras cosas relacionadas con los deportes. Y hoy, estoy aquí en React Advanced. Gracias por permitirme venir aquí y darles una charla sobre la gestión de características en las aplicaciones React.js.

Inicialmente, cuando presenté mi charla, tenía la idea de que simplemente entraría y hablaría sobre un nuevo proyecto de código abierto mío y simplemente lo publicitaría, dejaría que todos supieran sobre él, pero me di cuenta de que sería un gran fracaso si realmente lo hago de esa manera, porque entonces nadie entenderá por qué incluso construí esa herramienta y cuáles son los puntos de dolor y el sufrimiento que me llevaron a pensar en construir una herramienta así. Así que retrocedí un poco y luego hice esto mi agenda. Así que quiero centrarme más en el lado conceptual de las cosas, comenzando con la gestión de características, qué es, qué tipo de práctica es, las técnicas involucradas en ella, y cómo podemos adoptarla, cuáles son los beneficios, y también cuáles son los puntos de dolor que vienen con ella.

Y muy rápidamente, después de eso, también quiero tocar dos temas llamados infraestructura como código y también GitOps. Así que realmente quiero insistir en que entiendo que esta es una conferencia que se centra más en el lado de React en el área de front-end. Incluso si no conocen estos términos, tengo la fuerte sensación de que en realidad los conocen sin conocer estos términos. Así que aclararé eso muy, muy pronto. Y luego, una vez que hayamos cubierto el lado conceptual de las cosas, les mostraré cómo combiné estas tres prácticas diferentes, tres conceptos diferentes juntos para crear esta solución que llamo Feature Advisor. Y luego también quiero, de nuevo, mencionar que la herramienta es la parte insignificante de esta charla realmente. Una herramienta podría ser cualquier cosa, como podría ser una herramienta SaaS de terceros o esta herramienta que es de código abierto o algo que es personalizado y construido por usted mismo, realmente no importa. Así que realmente son los conceptos, la práctica en ingeniería de software. Y luego, por supuesto, porque es una conferencia de React Advanced, también quiero mostrarles cómo pueden llevar esta práctica a su aplicación React y también beneficiarse de ella. Así que prometo que les mostraré algo de código, pero al final, final.

Entonces, lo primero es lo primero, ¿qué es la gestión de características? ¿Cómo es? ¿Cómo se diferencia de algún otro tipo de gestión, como la gestión de contenidos o cosas así? Así que si estuviera en la misma sala con todos ustedes, creo que les habría pedido a todos que levantaran las manos preguntando, ¿alguna vez han usado banderas de características antes en su organización, en su código fuente, en su equipo? ¿Alguna vez han hecho eso? Pero como estamos remotos en este momento, así que seguiré adelante con mi diapositiva. Así que empezaré diciendo que la gestión de características al final es una práctica. Una práctica que consiste en varias técnicas diferentes que aplicamos en la ingeniería de software. La primera que me viene a la mente se llama banderas de características o interruptores de características que quizás ya hayan usado antes. Así que si no lo han hecho, entonces quiero mencionar que realmente es una condición if, una declaración if. Es un interruptor de encendido y apagado que revisas en tu código en algún lugar con una declaración if en algún lugar. Podría ser JavaScript, podría ser Golang, realmente el lenguaje no importa aquí. Y si algo es verdadero, haces algo. Si no, entonces haces algo más. Tan simple como eso. Pero la idea es que las condiciones que evalúan esos valores como verdaderos o falsos son algo que se gestiona externamente y algo que no está codificado en su aplicación.

Porque la idea es que queremos desacoplar el despliegue de tu aplicación de tus lanzamientos de características. Hablaré más sobre esto pronto en la próxima diapositiva, pero por ahora, supongamos que es un interruptor de encendido y apagado que simplemente controla el comportamiento de tu aplicación en ciertas áreas.

Y luego también, si estás más en el desarrollo de productos, también podrías haber oído hablar de las pruebas A-B o las pruebas multivariantes. Entonces, lo que sucede es, imagina que tienes un nuevo proceso de registro diseñado y quieres probar diferentes variaciones, como la variación A, la variación B, la variación C. Entonces, quieres probarlo con todo tu tráfico. Entonces, tal vez el 33% del tráfico recibe la variación A, otro 33% recibe la B, y los demás la C. Y luego averiguas cuál es la que mejor se convierte. ¿Es la variación B la que te da los registros más exitosos y así sucesivamente? Así que esta es una de las técnicas también que gestionas externamente mientras influyes en tu aplicación sin requerir ningún despliegue adicional.

Y otra cosa que es muy, muy crucial que encontré en mi carrera es el concepto de despliegues graduales. Entonces, imagina que tú y tu equipo han estado construyendo una nueva característica de producto que van a lanzar, digamos, el próximo mes. Realmente no quieres ir a por un lanzamiento a lo grande. No quieres lanzarlo al mundo entero o al 100% de tu tráfico. Quieres estar seguro de que, hey, hemos construido esto durante tanto tiempo sin exponerlo a los usuarios. Tal vez deberías averiguar si realmente funciona con usuarios reales antes de exponerlo a todos. Entonces, lo que puedes hacer es lanzarlo sólo al 5% de tu tráfico. Luego al 10%, ganas algo de confianza, ves que todo funciona bien con tu sistema de back-end, con tu código de front-end y todo lo demás. Y luego gradualmente mueves el nivel de porcentaje hasta el 100%. Y sabes que, vale, ahora está completamente fuera. No se retiene nada para nadie más. Y eso es un despliegue gradual.

El otro es la configuración remota. Imagina que tienes un comportamiento de producto muy específico que puedes parametrizar, y no quieres codificar esa configuración en tu propia aplicación. Así que gestionas esa configuración externamente, y puedes ajustar la configuración cuando te apetezca, y eso influye en el comportamiento de tu aplicación de inmediato, sin requerir ningún despliegue adicional. ¿No es increíble? Imagina este nuevo rediseño que tenía algún interruptor, como encendido o apagado. Podrías simplemente apagarlo cuando te apetezca, porque piensas que esto está causando algún daño a tu entorno de producción. Y luego viene la orientación de la audiencia. Así que tomaré un ejemplo de Facebook, en realidad. Ahora se llaman Meta. Nueva Zelanda siempre fue su patio de juegos, su campo de pruebas. Así que solían lanzar siempre estas nuevas características y las exponían a los usuarios en Nueva Zelanda solamente, por alguna razón, no me preguntes por qué.

Y luego averiguarán si funciona o no. Incluso en los Países Bajos, hay grandes empresas que a veces lanzan algunos productos nuevos en los Países Bajos primero, antes de desplegarlos al resto del mundo. Así que dirigen su audiencia. Así que esto es orientación de la audiencia. Descubres en el runtime si el país es igual a los Países Bajos o el país es igual a Nueva Zelanda, quiero exponer esta característica para el resto de la audiencia. No quiero mostrar nada todavía hasta que esté listo. Así que eso es orientación de la audiencia.

Así que estoy hablando mucho. Y así que estas son en realidad solo las técnicas que he mencionado. Pero ¿por qué incluso adoptarlas? ¿Cuál es la necesidad de incluso conocer estas técnicas y por qué incorporarlas? ¿Cómo mejora tu vida? Así que ahora pasamos a la siguiente diapositiva. Así que estos son solo los pocos elementos que he ideado para esta charla. Así que el primero es desacoplar las liberaciones de los despliegues. Así que esto puede sonar un poco confuso, como ¿qué es una liberación y qué es un despliegue? Así que el despliegue es cuando envías tu código. Así que imagina que has construido una aplicación React y la has empaquetado. Ya está sentada en alguna carpeta dist, y la subes a un CDN o a tu servidor. Así que esa es la parte del despliegue. El código se está enviando, pero el hecho de que se envíe el código no significa necesariamente que ya esté siendo expuesto a los usuarios. Tal vez hay algunas características que no están en estado de habilitación, como detrás de una característica flag. Así que esa es la parte de desacoplamiento. Así que los mantienes separados, la configuración de la característica y el código de la característica en sí. Esa es una parte del envío.

Y también, como si adoptas esta forma de trabajar, como cuando están desacoplados, también ayuda a tu equipo y a tu organización a adoptar esta mentalidad de entrega continua. ¿Y qué quiero decir con eso? Así que hay diferentes enfoques para gestionar el código en un repositorio Git o cualquier otro sistema de versionado. No importa. A menudo se llama desarrollo basado en el tronco. Sigues fusionando nuevas características que desarrollas, y simplemente las fusionas a tu rama principal o rama maestra, como quieras llamarla, y simplemente envías el código. Pero en realidad no están expuestas a tus usuarios hasta que te sientes listo. Y esto ayuda a evitar tener que mantener una rama de características de larga duración durante un largo período de tiempo. Introduce tantos conflictos, si hay tantos problemas de sincronización, realmente puedes abortar todo eso. Así que la entrega realmente, realmente te ayuda allí.

Otra cosa es el aumento del control y la flexibilidad. Así que por control, me refiero a que puede controlar quién ve qué, dónde y cuándo. Mencioné la configuración basada en el país antes. Así que podría ser cualquier cosa, también podría ser como decir, Vale, solo quiero lanzar mi característica a personas mayores de 25 o menores de 50, como sea, podrías idear estas condiciones tú mismo. Siempre que la evaluación sea realizada por el código, la configuración podría venir de otro lugar, totalmente separado de tu aplicación, dándote esa flexibilidad.

Mitigación de riesgos, una cosa más. Así que lo mencioné brevemente antes. Así que si tienes alguna característica que se ha lanzado, pero te das cuenta de que está causando algún daño en tu organización o tu sistema. Así que puedes retroceder rápidamente, puedes desactivarlo muy, muy rápidamente sin tener que coordinar, no sé, despliegues en quizás 20 o 30 equipos diferentes, dependiendo del tamaño de tu organización. Así que siempre es más fácil tener todo centralizado en un solo lugar y con la centralización de toda esta gestión de banderas de características, como la configuración y su comportamiento específico del producto. También te da una visibilidad muy sólida en toda tu organización. Así que el producto, el equipo de marketing, la ingeniería, por supuesto, pueden unirse y respaldar una única fuente de verdad. Y pueden colaborar en un solo lugar sin llevar a ninguna confusión o cualquier dolor y sufrimiento que pueda venir de ello si las personas no están alineadas. Así que estas son todas cosas buenas. Quiero decir, creo que podemos estar de acuerdo en que al menos obtenemos algunos beneficios simplemente al revisar esta lista aquí.

Pero en el mundo real las cosas no son solo arco iris y mariposas todo el tiempo, ya sabes, como hay muchos, muchos puntos de dolor operativos que vienen con ello. Así que mencionaré brevemente esos dos. Y realmente puedo decirte que cada uno de los elementos aquí me ha causado un gran dolor en mi career. Los he enumerado aquí en esta lista. Así que el primero es, tener revisiones y un flujo de trabajo de aprobación. Así que lo que pasa con la mayoría de las herramientas es que hay muchas terceras partes como SaaS herramientas allí para las necesidades de gestión de características. Y las que yo mismo revisé, diría que más del 80% no tienen este flujo de trabajo de revisiones y aprobación. Así que la mayoría de nosotros en esta audiencia ahora mismo, estoy suponiendo que somos principalmente ingenieros. Así que sabemos cómo trabajar con Git y GitHub. Y sabemos cómo enviar solicitudes completas. Así que tenemos una cultura muy basada en la revisión y la aprobación, ya sabes, así que nos gusta que se revise por pares antes de que algo se ponga en vivo. Así que esto es algo que no siempre existe en las herramientas de gestión de características que realmente, realmente no me gusta. Y ha causado tantos problemas antes, como en mis trabajos, como en varios trabajos diferentes. Y esto es algo que realmente echo de menos. Otra cosa es que la mayoría de estas herramientas te permiten crear un solo proyecto y tiene sentido que quieras tener toda tu gestión de características gestionada centralmente como en un solo proyecto.

Así que todos pueden ver todo. Pero el problema es el servicio de esta configuración. Así que imagina que tienes una aplicación de front-end, hay una página de inicio, hay una página de inicio de sesión página de registro, hay un flujo de pago, todo eso. Son áreas separadas de tu, como, ya sabes, como organización, cada equipo haciendo su propia cosa. Aunque desde la perspectiva del usuario final, los ves todos juntos. Pero cuando buscas la configuración, podrías estar cargando, digamos, configuración del área de pago, cuando solo estás intentando renderizar una página de inicio. Eso no está realmente bien. Como con la web, como performance es muy importante, solo queremos cargar lo menos posible para entregar el máximo valor a nuestros clientes para que podamos darles una buena experiencia, hacer que la página cargue realmente, realmente rápido y todo eso.

Así que esto realmente, realmente duele este tamaño de configuración que todos necesitamos buscar para nuestras banderas de características. La deprecación es otro problema. Así que con estas herramientas, ves que la gente sigue añadiendo y añadiendo más banderas de características y más configuración de características a la herramienta, y nunca las borran. Y porque todos tienen miedo de borrar algo, ¿qué pasa si borro algo y se rompe algo en Australia o se rompe algo en los Estados Unidos, porque no lo sabemos. Así que si tenemos un flujo de trabajo de deprecación diciendo que, está bien, si alguien está evaluando esto característica, muéstrales una advertencia para que los ingenieros puedan ocuparse de eliminarla ellos mismos. Así que este es también un problema que falta, un caso de uso que veo en muchas herramientas.

Las dependencias de las características, cuando tienes una característica que depende de otra, eso también es un concepto que no existe en muchas herramientas. Otro es establecer la propiedad de todas las características. Así que si creo una nueva bandera de características, ¿puedo asignarme a mí mismo como propietario o a un equipo como propietario? Así que como propietario, para que la próxima vez que quieras cambiar algo para que pueda saber quién es esta persona o quién es el equipo con el que necesito comunicarme. Testing y producción, otro más. Así que si tienes un equipo de QA en tu empresa, debes considerarte muy, muy afortunado porque no muchas empresas y equipos lo tienen. Así que todos tienen que probar todo ellos mismos antes de pasar a producción. Así que muchas de las herramientas no están realmente diseñadas en torno al flujo de trabajo de QA, el equipo de aseguramiento de calidad. Así que tal vez quieras exponer una bandera de características como habilitada solo para tu equipo de QA solo para que ellos puedan probar realmente en producción real antes de exponer al resto de los usuarios. Así que este es otro punto de dolor operativo que tengo. Así que he mencionado algunos de estos, cada uno de los elementos que yo mismo he enfrentado, estoy seguro de que muchos de ustedes también se han enfrentado. Y créeme cuando digo esto, los desafíos de codificación, los problemas técnicos son algo que la mayoría de nosotros podemos manejar. Pero los puntos de dolor operativos, como cuando tienes que estar en una sala llena de 15, 20 personas, todos estresados tratando de averiguar qué salió mal, dónde y no lo sabes realmente quieres evitar ese tipo de situación. Realmente, realmente no quieres estar allí. Y este es un gif que acabo de añadir en la diapositiva. Así que un gran hombre una vez dijo, como en este tipo de situaciones donde el entorno externo está tratando de ejercer demasiada presión sobre ti o como estás recibiendo demasiadas entradas, sé como el agua. Como era Bruce Lee, un hombre muy disciplinado.

Pero la realidad es que, en su mayoría, actúo así. Quiero decir, por mucho que quieras, ya sabes, estar muy compuesto, muy tranquilo, cuando el nivel de estrés es alto, y hay muchas personas de diferentes departamentos juntas, a veces puede salir una versión diferente de ti. Y todo eso, lo que aprendí en realidad, a través de este viaje, traté de verterlo en esta nueva herramienta que construí y que quiero mostrarles pronto.

Pero antes de ir allí, solo quiero mencionar dos nuevos temas muy, muy rápidamente. Así que el primero es infraestructura como código. Así que esta es una frase que copié de Google con algunas ediciones. Así que la infraestructura como código es una práctica en ingeniería de software donde la infraestructura se provisiona y se gestiona utilizando código declarativo. Y por código declarativo, me refiero a código que le dice al sistema qué hacer, pero no necesariamente cómo hacerlo. Porque tenemos todo el proceso manual es como si le estuviéramos diciendo a una persona que haga esto y la persona averigua cómo hacerlo y luego se hace el trabajo. Y si les doy algunos ejemplos rápidos, está Terraform, está Docker, está Kubernetes y todo eso. Así que todos están adoptando estos principios de ICC, ICC abreviatura de infraestructura como código. Pero realmente quiero centrarme solo en la última parte porque creo que es donde tenemos el terreno común en front end y back end. Muchos de nosotros ya hemos lidiado con pipelines de CI, CD, GitHub actions es uno popular. También son gratuitos para proyectos de código abierto y todo eso, está GitLab CI y hay más. Entonces, lo que sucede es que definimos lo que esperamos de nuestro pipeline de CI, CD en flujos de trabajo. Definimos un archivo YAML con un trabajo, con los pasos, y luego simplemente lo entregamos a GitHub y GitHub se encarga de todo por nosotros. Ejecuta el trabajo, nos da un estado verde o rojo según si la construcción pasó o falló. Así que todo eso es manejado por ellos. Así que realmente no nos gusta averiguar todos los pequeños cómo para hacer que eso funcione. Así que eso es realmente IAC.

El siguiente tema que quiero tocar rápidamente se llama GitOps. Así que sabemos sobre DevOps y otros tipos de trabajos operativos, pero GitOps es un nuevo término que también está ganando mucha popularidad y se basa en los principios de IAC, pero gestionamos todo en un repositorio git. Así que todo está declarado en una sintaxis declarativa como archivo YAML o JSON o TOML. Podría ser cualquier lenguaje de su elección, siempre y cuando sea declarativo, sin ningún código de programación. Usamos todo en Git. Así que todo es, esta es una fuente de verdad. Tenemos revisiones y flujo de trabajo de aprobación de serie porque todo va a través de pull requests y tenemos automation a través del pipeline de CI-CD porque todo está respaldado por él. Y por supuesto es Git, así que tenemos auditorías de serie porque mantiene todos los cambios que tenemos y tiene un historial completo. Así que no, todos sabrán quién hizo qué cuándo, así que tienes más transparencia en tu organización de inmediato. Así que aprendimos algunos conceptos diferentes.

Ahora aprendimos sobre la infraestructura como código. Aprendimos sobre la gestión de características. También tocamos GitOps. Así que realmente estaba luchando con este concepto durante los últimos dos o más años y quería averiguar si hay alguna forma de unir a estas tres partes y construir una solución que pueda hacer la vida de los ingenieros más feliz? Por eso, y este año finalmente descifré esa API en mi cabeza y realmente fui por ello. Y así es como llamo a esa herramienta Asesor de Características. Es gratis y de código abierto. Funciona con JavaScript, funciona con React, con SDKs y todo. Y de nuevo, quiero decir que la herramienta no es realmente la parte importante aquí. Te mostraré algunas de las funcionalidades de esta herramienta. Realmente puedes usar cualquier otra herramienta, pero son los principios los que realmente importan más.

Y aquí es donde realmente terminan mis diapositivas. Iré rápidamente al sitio web para mostrarte cómo funciona esa herramienta y cómo puedes incluso llevar este aprendizaje a cualquier otra herramienta de tu elección. Tal vez puedas construir algo tú mismo y beneficiarte de eso. Esta es la página de inicio. Así que ignoraré los detalles de la página de aterrizaje por ahora y te llevaré directamente al final de esta página y te mostraré la forma de trabajar con esta herramienta.

¿Cómo se aplica GitOps a la gestión de características? Así que tienes un repositorio Git. Este es tu proyecto de Asesor de Características. Este proyecto, este repositorio es independiente de tu código de aplicación. Así es como hacemos que los lanzamientos estén desacoplados de las implementaciones. Y envías solicitudes de pull para actualizar toda tu configuración de características como sus propios archivos YAML. Y una vez que la solicitud de pull es revisada y fusionada, una pipeline de CI-CD toma eso que tú mismo posees. Tengo plantillas para GitHub Actions así que puedes copiar eso si quieres. Y construirá los archivos de configuración que son consumibles, y luego los subirá a un CDN de tu elección. Será tu propio servidor.

Y el tercer paso es básicamente, una vez que esos archivos de configuración que se han construido y subido a un CDN, puedes buscarlo en el runtime de tu aplicación. Y por runtime, me refiero a si eres un desarrollador de aplicaciones React, podría ser el entorno del navegador. Buscas esa configuración desde el navegador directamente y utilizas los SDKs del Asesor de Características para evaluar esos valores como verdadero, falso, o algún otro valor variable. Y hay tres bloques de construcción para definir las características. Así que rápidamente pasaré por ellos. Los atributos son como campos. Por ejemplo, si quieres tener un conjunto de condiciones contra países, como si el país es igual a Nueva Zelanda, o el país es igual a Países Bajos, entonces define un atributo de país. Ese es tu campo contra el que tendrás una condición. Así que aquí estoy creando un archivo de atributo/país.yaml. Estoy diciendo que es de tipo string, y tengo alguna descripción solo para fines de documentation para nosotros los humanos. Y luego viene la parte de los segmentos. Los segmentos son como cómo defines, ¿cuáles son nuestras condiciones de orientación? Así que si queremos, digamos, apuntar a los usuarios de iPhone en los Estados Unidos, esta es una forma en que podríamos definirlo. Así que tendrás un archivo iPhone US.yaml. Y en nuestras condiciones, diremos que, bien, el atributo del país debe ser igual al valor de US. Ese es el código de país de US, Estados Unidos, y el dispositivo debe ser igual a iPhone. Así que de repente, tenemos como un segmento reutilizable que hemos definido que podemos usar cuando definimos nuestras reglas de permiso de características.

Los segmentos tienen una lista exhaustiva de operadores que puedes usar, más allá del operador igual . Así que realmente no tengo tiempo para repasar todos ellos, pero puedes volver a ello más tarde. Como cuando visites el sitio web.

Luego viene la parte de las características. Esta es la parte más interesante. Aquí es donde defines tus banderas de características individuales. La idea de definir una característica es que quieres evaluar uno de tres valores diferentes. El valor de la bandera en sí que es como un estado de encendido y apagado. Hay variación. Puedes usar pruebas AB. Si estás usando variables para configuraciones remotas, también puedes usar algunos pares clave valor como configuración aquí. Así que aquí esta es la forma más sencilla de definición de características en Feature Advisor. Creas un nuevo archivo sidebar.yaml porque así es como quieres llamar a tu bandera de característica. Así que tienes una barra lateral y luego defines algunas reglas de despliegue en un entorno diferente. Así que aquí solo tengo un entorno de producción, pero imagina que también podría tener un entorno de pruebas o de desarrollo o cualquier otra cosa, sabes, depende totalmente de mí personalizarlo. Y luego tengo las reglas. Estoy diciendo que, vale, quiero lanzarlo a todos. Así que asterisco significa que todos los segmentos, audiencia completa y porcentaje es como si quisiera desplegarlo gradualmente. Así que podría ser cualquier valor entre cero y cien. Y anteriormente creamos un segmento llamado iPhone US. Así que imagina que queríamos lanzar esta característica de barra lateral solo a los usuarios de iPhone US. Así que podríamos haber hecho algo como esto en los segmentos en lugar de asterisco. Podríamos decir simplemente, vale, en lugar de Alemania, podría llamar a Estados Unidos o a los usuarios de iPhone US, cualquier cosa, sabes, somos totalmente libres de componer nuestras propias condiciones de orientación de la manera que queramos personalizando contra nuestras propias necesidades. Así que esta es la parte de la definición.

Así que no tocaré los temas de la parte CICT. Es solo un comando que construye todo. Puedes usar eso desde el sitio web. Pero hablaré rápidamente sobre el SDK en sí. Así que el SDK de JavaScript, voy a pasar a React justo después de esto. Así que el SDK de JavaScript es universal.

Funciona en Node.js y también en entornos de navegador. Hay más SDK en otros lenguajes y en desarrollo, pero JavaScript es el que ya está terminado. Y simplemente lo inicializas proporcionando una URL de archivo de data. Así que imagina que descargaste, subiste tu archivo de configuración a tu propio CDN, simplemente proporcionas esa URL. Y simplemente lo inicializas usando la función de crear instancia de él. Eso es todo. Y una vez que lo tienes, puedes evaluar tus banderas de características llamando, si la característica de otra instancia tiene esta clave de característica habilitada o no, obtienes el valor y haces lo que quieras con él. Como si está habilitado, muestra esta barra lateral, si no está habilitado, no la muestres. Podría ser cualquier cosa. Lo mismo para variaciones y variables y todo eso.

Pero realmente quiero pasar al lado de React ahora. Y también porque estamos en una conferencia de React después de todo. Entonces, el SDK de React complementa el SDK principal de JavaScript, que tiene solo seis kilobytes de tamaño, el SDK principal. Es muy, muy pequeño y muy, muy eficiente. Y hay un componente proveedor que importas del paquete de React de FeatureVisor. Configuras la instancia en la raíz de tu árbol de componentes, para que todos tus componentes hijos puedan hacer uso de esto. Y tiene un montón de ganchos diferentes. Entonces, si quieres verificar el estado de la bandera, si una característica está habilitada o deshabilitada, puedes importar el gancho use flag y luego llamarlo de forma sincrónica en tu componente. Y luego evaluarlo y react a él de la manera que quieras. Lo mismo para las variaciones, como el gancho use variation o A-B test. Lo mismo para las variables si quieres tener alguna configuración remota. Entonces, todos los casos de uso comunes ya están cubiertos para ti. Y funciona con React Native también. Así que probé una aplicación iOS yo mismo. También hay un repositorio de ejemplo. Entonces, es el mismo paquete que funciona en todas partes, porque React Native ya viene con una API de fetch. Así que tienes eso cubierto. Esa es la única API de la que FeatureVisor tiene dependencia. Y entonces sí, realmente puedes desacoplar completamente tu desarrollo de aplicaciones y tu gestión de características por separado. De modo que puedes ajustar la configuración en el momento que elijas sin tener que pasar por el proceso de despliegue de todas tus aplicaciones individuales en tu organización. Y muchos de ustedes pueden tener varios equipos gestionando diferentes servicios en backend, frontend. Puedes reunirlos a todos en un solo lugar con esta herramienta. Entonces, aquí es donde realmente me gustaría parar, no tengo mucho que decir además de esto. Y realmente quiero enfatizar que la intención de esta charla es realmente hacer que entiendas los beneficios de la gestión de características. Entonces, las herramientas pueden ser reemplazables en cualquier momento, pero las prácticas realmente se quedan con nosotros. Y espero que esto te dé algunas ideas interesantes de mi propia experiencia anterior. Y tal vez puedas tomar estos puntos principales y ver cómo puedes resolverlos mejor, por ti mismo construyendo algo dentro de tu propia organización, o tal vez usando una herramienta que se ajuste a tu propósito. Y estoy muy, muy interesado en escuchar tus comentarios, qué piensas sobre esta herramienta, o si tienes algún punto de dolor con otras herramientas, porque tal vez juntos podemos hacer algo aún mejor que cubra los casos de uso de muchas otras personas. Y esa es la esencia del código abierto. Así que gracias a todos. Gracias a React Advanced por la invitación, y espero charlar contigo pronto en Discord. Adiós.