Integrar LaunchDarkly con Next.js te permite controlar feature flags y testing AB en aplicaciones que combinan renderizado en cliente y servidor. Aquí verás cómo hacerlo paso a paso, qué problemas surgen con el caché estático de Next.js y cómo resolverlos con revalidate o force-dynamic.

Esta guía es útil si trabajas con Next.js en producción y necesitas habilitar funcionalidades de forma controlada sin redeploy constante.

Qué son los feature flags y por qué usar LaunchDarkly

A medida que tu aplicación crece, liberar nuevas funcionalidades requiere más cuidado. Aquí entran los feature flags: banderas que activan o desactivan código desde un dashboard, sin tocar el deploy.

Las estrategias de testing AB dividen a tus usuarios en grupos y le muestran a cada uno una versión distinta. A veces basta con prender o apagar una bandera; otras veces decides según geolocalización, rol o permisos del usuario [01:10].

¿Qué es un feature flag? Es una bandera configurable que activa o desactiva funcionalidades en tiempo real desde un panel externo, sin necesidad de redeploy. Permite hacer rollouts graduales y testing AB.

LaunchDarkly es uno de los servicios más populares en este espacio. No necesariamente es el mejor, pero lleva años en el mercado, está presente en muchas empresas y tiene documentación extensa. Su soporte para Next.js no es directo, pero sí ofrece SDKs para Node.js y React, y eso nos basta.

Cómo configurar el cliente de LaunchDarkly en Next.js

El primer paso es instalar el SDK de Node.js de LaunchDarkly y crear un cliente reutilizable. La librería usa require en lugar de ES Modules, así que toca adaptarla [05:30].

Dentro de la carpeta de tu página crea un archivo lib para inicializar el cliente. Necesitas una variable de entorno con el SDK key, por ejemplo LAUNCHDARKLY_SDK_KEY, que obtienes desde el dashboard de LaunchDarkly.

El flujo de inicialización es así:

• Importa LaunchDarkly y llama a init pasándole el SDK key.
• Espera con waitForInitialization y un timeout de 10 segundos.
• Retorna el cliente para usarlo en tu aplicación.

js import * as LD from "@launchdarkly/node-server-sdk"; import { cache } from "react";

export const getClient = cache(async () => { const client = LD.init(process.env.LAUNCHDARKLY_SDK_KEY!); await client.waitForInitialization({ timeout: 10 }); return client; });

Por qué el cliente debe ser un singleton

La documentación de LaunchDarkly recomienda que el cliente sea un singleton, es decir, una instancia única que no se recree en cada llamada. Si lo instancias varias veces, pueden ocurrir errores difíciles de rastrear.

Para garantizarlo en React, usas la directiva cache. Esta función guarda en memoria el resultado y, si los argumentos no cambian, devuelve siempre la misma instancia gracias a memoization [08:45].

Cómo leer una variación desde un Server Component

Una vez tienes el cliente, puedes leer el valor de tu flag dentro de un React Server Component. En el ejemplo trabajamos con una flag llamada featureNewColor que renderiza un cuadrado de color distinto según esté activada o no.

El método clave es client.variation, que recibe tres parámetros:

• El key del feature flag (por ejemplo, feature-new-color).
• El contexto del usuario (geolocalización, rol, permisos).
• Un valor por defecto, en este caso false.

tsx const client = await getClient(); const variation = await client.variation( "feature-new-color", context, false );

El contexto es propio de LaunchDarkly y permite tomar decisiones según atributos del usuario. Si la flag está activa, el componente renderiza un color; si está apagada, otro.

Por qué la página no se actualiza en producción

Aquí aparece el detalle más interesante de Next.js. En desarrollo todo funciona bien: cambias la flag en el dashboard, recargas y ves el nuevo valor. Pero al hacer pnpm build y correr en modo producción, el cambio nunca se refleja [13:20].

¿Qué pasa? Next.js, por defecto, pre-renderiza las páginas como estáticas durante el build. Trae la información de LaunchDarkly una sola vez, genera el HTML y lo sirve siempre igual. No vuelve a consultar el servicio en cada request.

¿Por qué Next.js convierte mis páginas en estáticas? Porque al integrarse con React Server Components, optimiza pre-renderizando todo el contenido posible en build time. Esto reduce trabajo del servidor pero congela los datos externos.

Cómo forzar la revalidación con dynamic y revalidate

Next.js te da varias opciones para cambiar este comportamiento. Cada una tiene un costo y un caso de uso distinto.

Force dynamic para renderizar en cada request

Exportas la constante dynamic con valor "force-dynamic" desde la página. Cada petición ejecuta el componente completo, resuelve lo asíncrono y devuelve HTML fresco.

tsx export const dynamic = "force-dynamic";

Funciona como un servidor tradicional: llega request, procesa, responde. Útil si tu información cambia constantemente, pero consume más recursos.

Revalidate para incremental static regeneration

La segunda opción es revalidate, que indica cada cuántos segundos Next.js debe regenerar la página. Esto se conoce como Incremental Static Regeneration o ISR.

tsx export const revalidate = 10;

Con ese valor, después de 10 segundos la siguiente petición dispara una nueva consulta a LaunchDarkly, regenera el HTML y actualiza el caché. Solo funciona en producción [17:40].

Rebuild automático con CI

La tercera vía es disparar un nuevo build cada vez que cambias una flag, usando webhooks y CI. Suena engorroso, pero si tus valores cambian poco, es la opción más barata: cero trabajo de servidor en runtime.

Qué estrategia elegir según tu aplicación

La decisión depende del comportamiento de tu negocio:

• Si la información cambia constantemente, usa force-dynamic.
• Si cambia con frecuencia moderada, usa revalidate con un intervalo razonable.
• Si casi nunca cambia, dispara rebuilds automatizados desde CI.

Los profesionales senior se distinguen por entender el negocio detrás del código. Las herramientas son las mismas; el valor lo aporta saber cuándo usar cada una.

Para la integración del lado del cliente con React, el patrón es similar pero con la directiva "use client" en la parte superior del componente. ¿Tú cómo manejas feature flags en tus proyectos de Next.js?