Feature Flagging in React

Hola a todos, soy Graham y estoy muy emocionado de darles una charla hoy sobre el uso de feature flags con componentes de servidor de React, así que empecemos. Soy Graham McNichol. Soy el cofundador de Growthbook. Growthbook es la plataforma de feature flagging y pruebas A-B de código abierto más popular. Pasé por Y Combinator hace un par de años y anteriormente fui el CTO de mi última startup.

El objetivo de la charla de hoy es, si aún no están familiarizados, darles una breve introducción sobre qué es el feature flagging. Vamos a dar algunos ejemplos de cómo pueden implementar feature flags en su aplicación y luego algunos ejemplos más complejos. Y luego, lo más importante de esta charla, es hablar sobre cómo interactúa el feature flagging con React y en particular con algunas de las diferentes estrategias de renderizado que tiene React. Vamos a ver cuatro ejemplos diferentes de diferentes estrategias de renderizado que tiene React y cómo pueden usar el feature flagging en cada una de ellas.

Bien, teniendo eso en cuenta, vamos a ver qué es el feature flagging. Los feature flags son lógica condicional que colocas alrededor de un bloque de código que te permite controlar el estado de esa característica de forma independiente de la implementación del código. Realmente te ayuda a separar las implementaciones del código del lanzamiento de características, ¿verdad? Y eso es realmente fundamental cuando estás trabajando con organizaciones de productos grandes. Tienes muchos commits que ocurren al mismo tiempo.

Así que veamos algunas de esas ventajas. Desde el punto de vista del desarrollo, te permite hacer commits de código, aunque esté en progreso, porque nunca será visto por un usuario. Así que puedes hacer commits con más frecuencia sin exponer esos cambios a tus usuarios. También permite el desarrollo basado en tronco, siéntanse libres de buscarlo. No tengo tiempo para entrar en eso, pero también es una forma interesante de hacer desarrollo si se encuentran constantemente con muchos conflictos de fusión. También te permite hacer lanzamientos condicionales de características. Puedes lanzar características a un subconjunto de tus usuarios, o puedes hacer pruebas en vivo en producción, por ejemplo, apuntando solo a usuarios beta, o haciendo lanzamientos canarios, o lanzando solo a un pequeño subconjunto de tus usuarios. Realmente no puedes hacer eso sin otros sistemas o codificarlo directamente. Y FeatureFlag hace que eso sea tan fácil y trivial.

Desde una perspectiva de producto, como ingenieros, una de las cosas que sucede es que podemos lanzar una característica y causar un error inesperado. En ese caso, históricamente, tenías que revertir rápidamente tu código, encontrar el error y volver a implementarlo, o volver a una versión anterior y luego implementar esa versión. Y ahora estás esperando a que termine tu canalización de CI/CD. Es un poco estresante esperar un par de minutos mientras todo se ejecuta. Esperemos que sean solo un par de minutos. A veces puede ser mucho, mucho más tiempo. Y luego hay todo tipo de efectos de interacción. Si tu implementación se lanzó con otras características, ahora estás revirtiendo el trabajo de otras personas.

Y simplemente se vuelve muy complicado. Así que usar FeatureFlag te proporciona un interruptor de apagado donde puedes desactivar tu característica. Sí. Así que eso es realmente poderoso. Y lo otro genial que hace es que te permite hacer pruebas A-B. Creemos que FeatureFlags es la mejor manera de lanzar nuevas características. Y las pruebas A-B son la mejor manera de medir el impacto de esas características. Entonces lo que haces es lanzar condicionalmente esa característica a un conjunto aleatorio de usuarios que obtienen la versión de control, un conjunto aleatorio que obtiene la nueva variante, y luego mides el impacto. Entonces te permite controlar todas las diferentes externalidades que pueden ocurrir y los cambios en tu producto que pueden ocurrir si solo miras antes y después de las pruebas.

Entonces, en un ejemplo muy simple, un FeatureFlag simplemente obtiene el estado. Aquí evaluamos una característica llamada MyFeature. Y luego lo almacenamos en la variable. Y luego podemos usar eso para mostrar condicionalmente un componente o no. Y donde almacenas ese valor de esa bandera puede ser tan simple como codificarlo en tu archivo o en otro archivo en algún lugar. Muchas empresas tienen un archivo Features.json que se incluye. Entonces, en este ejemplo, te mostré dónde se almacena el estado de la bandera en el archivo.

Cambiar ese estado requiere una implementación de código, que es una de las principales ventajas de usar FeatureFlags en primer lugar. Y ahora tienes que esperar a que termine tu proceso completo de CI/CD antes de poder implementar. Y si tienes un error en esa nueva característica que acabas de implementar, bueno, la desactivas muy rápidamente. Estás un poco fuera de suerte porque ahora tienes que cambiar ese estado de la bandera en ese archivo y luego hacer una implementación completa y esperar a que tu canalización de CI/CD termine por completo. También podrías usar variables de entorno. Es un poco mejor. Pero tiene limitaciones en cuanto a la cantidad de complejidad que puedes usar en el estado de tus FeatureFlags. Es bastante bueno para banderas simples. Pero si quieres cosas más advanced que las variables de entorno, no tiene el contexto rico y las expresiones ricas que te permitan controlar eso. Entonces, si quieres, por ejemplo, controlar la implementación a un cierto porcentaje de tus usuarios o a tipos de usuarios específicos, estos estados no funcionan realmente.

Aquí tienes un ejemplo más complejo. Esto utiliza la sintaxis de growth book, pero todas son similares a otras sintaxis de feature flagging. Entonces, lo que hace es tener una característica llamada MyFeature que está desactivada de forma predeterminada. Y luego puedes ver un conjunto de reglas que se evalúan. La primera activará la característica para todos los administradores. Entonces, si eres un administrador, verás esta MyFeature como verdadera. Y se te mostrará esa característica. Y luego, si estás en los Estados Unidos o en Canadá, hay un 20% de probabilidad de que se te incluya y se te muestre en esta característica también. Es una buena manera de implementarlo gradualmente. Pero este lenguaje expresivo permite hacerlo mucho más complicado, ya que se pueden incluir operadores lógicos y se vuelve realmente complicado. Entonces, es muy complicado construir esto por ti mismo y realmente no es necesario porque hay muchas plataformas como GrowthBugger u otras que harán esto por ti. Lo que vemos es que eventualmente las personas comienzan construyendo su propio sistema y luego eventualmente pasan a usar un sistema mucho más completo. Y usar una plataforma de feature flagging tiene dos ventajas principales.

Una de las ventajas de las aplicaciones de feature flagging es que tienen una interfaz de usuario (UI) agradable para controlar las versiones de las características y un SDK que se integra con el código. La UI permite que los gerentes de producto u otras partes interesadas controlen cómo se lanzan esas características y condicionalmente controlen qué reglas se muestran. Por otro lado, el SDK se integra con tu código y evalúa el estado para ese usuario o renderizado en particular.

Ok, ahora entiendes de qué se tratan las feature flags y espero que entiendas por qué probablemente deberías estar usándolas. Pero al usarlas con React, React tiene diferentes estrategias de renderizado que pueden causar algunas complicaciones en cómo se usan las feature flags. Vamos a echar un vistazo a estas cuatro estrategias de renderizado diferentes y vamos a comenzar con los generadores de sitios estáticos. Vamos a usar Next.js como ejemplo aquí. Cada framework es un poco diferente, pero espero que entiendas la idea. Debería haber una forma de obtener props estáticos en tu aplicación que se pasen en tiempo de ejecución en cualquier framework que uses.

Entonces, las props estáticas se evalúan en tiempo de compilación y se utilizan para generar tu aplicación estática. En este ejemplo, estamos obteniendo props estáticos que estamos obteniendo del payload de nuestras feature flags. En este caso, es desde nuestro CDN de Growth Book. Pero donde sea que se almacenen las definiciones de las feature flags, se descargan en tu aplicación y luego se guardan como una prop y se pasan a tu aplicación. Ahora la aplicación puede inicializar el SDK y usarlo para evaluar las características. El `isOn` está haciendo una evaluación que devolverá verdadero o falso para mostrar la característica y se utiliza para renderizar condicionalmente ese componente `MyFeature`.

Ok, los mayores problemas con este enfoque es que se hace en tiempo de compilación antes de implementar nuestra aplicación, no podemos realmente hacer segmentación de usuarios, ¿verdad? Entonces, en ese ejemplo anterior donde apuntamos las feature flags para los administradores, no funciona realmente porque en tiempo de compilación no conocemos el estado del usuario. No sabemos si son administradores o no. Estamos realmente limitados al tipo de segmentación que se puede hacer con un generador de sitios estáticos. Ahora, si quieres algo que esté siempre activado o siempre desactivado para todos, es una estrategia aceptable, pero no es ideal para algunos usos más avanzados. Y uno de los problemas es que también requiere una nueva implementación de tus feature flags para obtener el nuevo valor. Eso elimina una de las principales ventajas de las feature flags, que es poder desactivar algo inmediatamente si se rompe. Algunos frameworks complican un poco las cosas con la generación estática incremental de sitios, que te permite construir estáticamente una página y luego reconstruirla cada minuto o algo así. Sí, resuelve algunos de los inconvenientes, pero no completamente.

Ok, así que la siguiente estrategia que vamos a ver son los componentes del cliente. Y el mayor problema con los componentes del cliente es que no son asíncronos. Tenemos que usar `useEffect`, y el estado y el contexto son un poco necesarios. Entonces, descargar la lista de características desde un servidor es, por definición, una tarea asíncrona. Por lo tanto, tenemos que usar algunas de estas primitivas de React para superar esas limitaciones. Aquí tienes un ejemplo de código que utiliza componentes del cliente. A la izquierda tenemos nuestro envoltorio alrededor de nuestra aplicación y a la derecha tenemos un ejemplo de componente que utiliza la feature flag.

Entonces, si observamos el código de la izquierda, primero vamos a instanciar nuestro SDK. Y eso está fuera de nuestra aplicación. Esto es un singleton. Pero como es del lado del cliente, está bien. Es perfectamente aceptable hacerlo. Y luego, dentro de la aplicación, vamos a disparar un gancho de efecto de usuario para inicializar el SDK. Tan pronto como se cargue tu aplicación, se ejecutará este gancho de efecto de usuario. Y comenzará a descargar la carga útil de la feature flag. Y luego, sí, eso inicia una tarea asíncrona para obtener esa carga útil. El segundo gancho de efecto de usuario que tenemos allí, a diferencia de la generación de sitios, porque es del lado del cliente, tenemos acceso a toda la información del usuario. Por lo tanto, podemos comenzar a hacer segmentación de usuarios basada en esos atributos del usuario. Aquí tenemos un ejemplo, como un objeto de usuario, y luego devolvemos el país, pero podría ser un ID y otros atributos que conozcas sobre el usuario. Entonces, el segundo gancho de efecto de usuario obtiene los datos del usuario y luego los actualiza en tu SDK. Y luego, realmente volveremos a evaluar los estados de las feature flags basados en los cambios de los atributos. Y por último, en la parte izquierda, tenemos el proveedor de Growth Book. Y eso crea un contexto que cualquier componente debajo de él puede usar para evaluar la feature flag. Dentro de los componentes, no tenemos que preocuparnos por ninguna de estas cosas, ya sabes, la instanciación de las feature flags, podemos simplemente usar un gancho para obtener los estados de esas características. Literalmente es una línea para evaluar la feature flag dentro del componente una vez que estés usando un proveedor como este. Aquí usamos el gancho `isOn` que utiliza el contexto para evaluar el estado de `MyFeature`, y luego lo usa para renderizar condicionalmente ese componente `MyFeature`.

El mayor problema es que tenemos un ligero problema con el parpadeo. Básicamente, la primera vez que se renderiza la aplicación, todas las feature flags están desactivadas o en el estado predeterminado. Y luego lleva un poco de tiempo para que el SDK se inicialice y descargue el estado de la feature flag, y luego vuelva a renderizar esas partes de la aplicación. En ese momento, algunas de esas feature flags pueden estar activadas. Por ejemplo, si eres un usuario administrador, algunas de esas características de administrador de repente estarán activadas a medida que se cargan. Esto puede causar un ligero parpadeo en la experiencia de usuario o un problema donde muestra el estado predeterminado y luego parpadea al estado válido para ti. Es posible que estés familiarizado con esto en muchas aplicaciones de una sola página en línea en este momento. Hay formas de acelerar esto, como asegurarse de que tu solicitud de red para la carga útil de la feature flag sea realmente rápida. Nosotros, en GrowthWheek, ciertamente utilizamos una CDN muy rápida para ayudar con eso. Pero no puedes controlar completamente la conexión de red del cliente.

Entonces, existen algunas formas en las que no se puede hacer mucho al respecto. Aquí hay algunas soluciones alternativas donde es bastante común mostrar un gran spinner de carga durante el primer segundo aproximadamente mientras todo se renderiza en segundo plano. Pero aún así, no es ideal. Y por último, si estás utilizando feature flags para SEO, no es ideal porque la carga inicial de HTML que se te sirve o se solicita no incluye todo el contenido completo de la feature flag. Por lo tanto, si estás tratando de clasificar para SEO ese contenido que está en una feature flag, puede causar algunos problemas. Sí, generalmente no es un caso de uso muy común. La mayoría de las veces, las feature flags se utilizan para casos específicos de usuarios, no para SEO.

De acuerdo, veamos los componentes del servidor. Los componentes del servidor son nuevos para React 19. Y debes estar utilizando un framework de React más moderno como Next.js para acceder a esto. Una de las cosas buenas de los componentes del servidor de React es que son asíncronos. Por lo tanto, todo el complicado useEffect y state con el que teníamos que lidiar antes, ya no necesitamos lidiar con eso. Requiere un enfoque completamente diferente al que vimos antes. Veamos un ejemplo de código. Aquí a la izquierda, configuramos nuestro SDK. Y luego lo tenemos aquí cargando dentro de nuestro componente como antes. Pero veamos el lado izquierdo aquí. Estamos usando react.cache aquí a la izquierda. Y eso es realmente poderoso si no estás familiarizado con eso. Te permite almacenar en caché una operación costosa como una instancia en el SDK. Y se reutiliza durante una renderización. Pero lo bueno de react.cache es que está limitado al ámbito de la solicitud actual. Por lo tanto, puedes ver que dentro de nuestra llamada a react.cache, en realidad estamos usando atributos del usuario. Por lo tanto, estamos accediendo a las cookies y podemos establecer valores en función de eso. Y debido a que los servidores están procesando miles de estas solicitudes, tan pronto como esta solicitud finalice, llega la siguiente, la caché se borrará y se volverá a evaluar. Y luego, en el lado derecho, obtengo el valor de esa feature flag con la llamada a la función getSdk, que está esperando que la función de caché devuelva. Y la primera vez que lo llames, será un poco lento, pero cualquier llamada posterior debería ser mucho, mucho más rápida. Y luego lo usamos para evaluarlo. También debo mencionar que Growth Book dentro del SDK y probablemente muchos otros SDK también tienen su propia caché interna. Por lo tanto, no es tan malo como podrías pensar en términos de, ya sabes, borrar esta caché para cada solicitud.

No es tan malo porque nuestro SDK tendrá su propia caché en memoria para eso. Genial. Y el resto del código es bastante similar. Solo usamos eso, ya sabes, el isOn para evaluar la feature y luego renderizar condicionalmente ese componente.

Ok, esta estrategia tiene algunas desventajas. Y la más grande es que el renderizado dinámico puede ser costoso. Básicamente, todas esas solicitudes que llegan deben pasar por Node, deben renderizarse, deben hacer una llamada de red, deben ejecutar React en el lado del servidor. Y eso puede volverse realmente costoso a escala. Dependiendo de cuánto tráfico tengas y especialmente si estás utilizando una plataforma como Bristle, donde te cobran en función de las solicitudes de cómputo, realmente puede comenzar a sumar para sitios grandes. También puede ser un poco lento, especialmente la primera vez. Ahora, las funciones de borde generalmente son bastante rápidas, pero no son tan rápidas como simplemente servir un HTML en caché estáticamente desde un CDN. La otra complicación con esta estrategia de renderizado es el seguimiento de eventos, como el seguimiento de qué características están utilizando tus usuarios y si deseas enviar eso, por ejemplo, a DataDog o Sentry, entonces eso será bastante difícil porque tendrás que mover datos entre el lado del servidor y el lado del cliente. Y la mayoría de esas herramientas no necesitan ser rastreadas directamente desde el lado del servidor, por lo que agrega cierta complejidad si deseas algunos casos de uso más avanzados.

Entonces, la última estrategia de renderizado que vamos a ver es el enfoque híbrido servidor-cliente. Básicamente, es una combinación de las dos últimas estrategias de las que hablé. Y la idea aquí es obtener lo mejor de ambos mundos sin ninguno de esos inconvenientes. Realmente quieres obtener un renderizado sin parpadeo de la feature flag en el lado del cliente sin tener que ser realmente costoso para el renderizado dinámico. Sí, sería genial si pudiéramos hacer esto, ¿verdad? Veamos cómo podemos hacerlo. El primer paso aquí es convertir tu aplicación externa en un componente del servidor. La clave aquí es que no podemos acceder a cookies o encabezados dentro del componente del servidor aquí. Aunque tenemos un componente del servidor con renderizado dinámico, porque no estamos mirando ninguna de las cosas del encabezado, podemos almacenar en caché esto en gran medida. En este ejemplo, puedes ver que estamos obteniendo la carga de la feature flag desde el CDN y la estamos almacenando en caché durante cinco minutos. Por lo tanto, solo golpeará el servidor de Node una vez cada cinco minutos y todo lo demás estará completamente en caché. Por lo tanto, es mucho más económico y rápido a escala. Descargas la carga de las feature flags y luego la pasamos a la aplicación del cliente. El componente externo es el componente del servidor y el componente interno es el componente del cliente. Veamos el componente del cliente. Como ya tenemos todo disponible de forma síncrona, realmente no necesitamos usar el gancho UseEffect. Podemos usar el gancho UseMemo. Y luego estamos usando el método initSync, porque ya tenemos esa carga en memoria.

Simplemente lo pasamos ahí mismo. Y luego podemos obtener de inmediato esa instancia del SDK disponible para nosotros. Y luego, como segundo paso, envolvemos nuestra aplicación principal en un proveedor, que nuevamente proporciona ese contexto disponible para todos los componentes que están debajo de él. A la derecha, es lo mismo que antes, donde evaluamos esa feature. Entonces esto realmente nos brinda lo mejor de ambos mundos. Sin embargo, hay algunas desventajas leves, como que es un poco más complejo de configurar. Pero si estás utilizando algo como Next.js con React componentes de servidor, esta es una forma realmente genial de construir tu aplicación con una implementación de feature flags moderna y un alto rendimiento también. Muy bien, aquí están las conclusiones. La implementación de feature flags es realmente impresionante. Si aún no la estás utilizando, realmente deberías hacerlo. Hay muchas ventajas de usar feature flags, desde la facilidad de poder desactivar rápidamente las cosas, hasta las pruebas A-B, para evaluar el impacto de cada función que implementas. Los sistemas de feature flags son bastante difíciles de construir. Es muy fácil construir algo simple. Pero los casos de uso se expanden rápidamente y luego se vuelve realmente difícil construirlo por ti mismo. Así que utiliza una plataforma probada en batalla si puedes. Hay muchas opciones disponibles. Puedes usar la que prefieras. Todas son generalmente bastante similares. Soy un poco parcial. Creo que Growthbook es el mejor, pero sí. Muy bien, la última conclusión aquí es que las aplicaciones de React pueden ser bastante complejas. Hay muchas estrategias de renderizado diferentes y todas tienen diferentes ventajas y desventajas, dependiendo de tus casos de uso. Y la implementación de feature flags puede adaptarse a cualquiera de esos casos de uso, solo tienes que entender los pros y contras de cada una de esas situaciones. No importa cómo estés renderizando tu aplicación, puedes usar feature flags y obtener todos los beneficios de esos sistemas. Muchas gracias. Si necesitas contactarme, puedes hacerlo en hello at growthbook.io, o a mi correo electrónico personal gram at growthbook.io. Muchas gracias. Nos vemos la próxima vez.