Type-Safe App Configuration

Hoy hablaré sobre la configuración de aplicaciones seguras por tipo, una práctica recomendada emergente que puede ayudarte a acelerar el desarrollo de software. Ahora, si has oído hablar de las banderas de características, puedes pensar en ellas como la punta del iceberg de la configuración de aplicaciones.

La mejor manera de entender qué es la configuración de aplicaciones es verla en acción. Así que imaginemos que somos una empresa SaaS típica llamada Potion, y esta es la página de planes de nuestra aplicación donde los usuarios pueden suscribirse a uno de nuestros planes de pago.

Supongamos que el equipo de marketing quiere ofrecer un descuento del 20% en todos nuestros planes de pago. Así que nos piden ayuda al equipo de ingeniería. Así que iremos a nuestra base de código y escribiremos código para implementar el descuento. Luego lo desplegaremos en un entorno de pruebas y enviaremos al equipo de marketing un enlace al entorno de pruebas para que puedan ver si se ve bien. Ellos dicen que se ve bien. Así que nos dicen que están contentos de que esto se despliegue en producción. Así que lo desplegamos en producción y ahora el descuento está activo.

Pero luego, después de un tiempo, el equipo de marketing vuelve a nosotros y dice que quieren pausar el descuento. Así que volvemos a la base de código, escribimos código para pausar el descuento y luego lo desplegamos en producción. Y ahora el descuento está pausado. Pero luego, después de un tiempo, vuelven a nosotros y dicen que quieren reanudarlo. Ahora, este ir y venir se está volviendo un poco tedioso. Así que decidimos ocultar el descuento detrás de una bandera de características para que ellos puedan controlar cuándo está activo o inactivo.

Ya hemos configurado un sistema de banderas de características en nuestra aplicación llamado HyperTune. Así que podemos ir al UI de HyperTune y crear una nueva bandera llamada isDiscountEnabled. Y es un booleano porque es solo activado o desactivado. Y por defecto, está desactivado. Así que guardaremos eso. Luego iremos a nuestra base de código y ejecutaremos npxHyperTune para regenerar nuestro cliente seguro por tipo para acceder a todas nuestras banderas. Y utilizaremos la bandera en nuestro código con HyperTune.isDiscountEnabled. Y pasaremos un valor de respaldo false. Desplegaremos esto en producción. Y luego enviaremos al equipo de marketing un enlace a la bandera. Así que ahora ellos pueden controlar si está activado o desactivado. Así que ahora está desactivado. Así que si entran en la aplicación, no hay descuento.

Pero si lo activan y luego hacen clic en Guardar, una vez que se propague, el descuento aparecerá en la aplicación. Esto es genial porque ellos pueden activar o desactivar el descuento por sí mismos sin tener que preguntarnos, y nosotros no tenemos que esperar a que nos digan cuándo quieren que el descuento esté activo. Ahora ambos flujos de trabajo están desacoplados y podemos avanzar mucho más rápido e independientemente.

También se dieron cuenta de que solo quieren aplicar el descuento a los usuarios del Reino Unido. Pueden desactivarlo aquí y agregar una regla específica para verificar el país del usuario, y si es el Reino Unido, entonces el descuento está activo. También se dieron cuenta de que quieren realizar pruebas A-B para ver si el descuento realmente mejora el número de actualizaciones, los ingresos totales y las ganancias totales. Así que en lugar de que esté activo para todos los usuarios del Reino Unido, agregan una prueba A-B aquí y lo activan para el grupo de prueba, que será el 50% de los usuarios, y lo desactivan para el grupo de control, que será el otro 50%. Luego recopilarán análisis de ambos grupos y podrán visualizarlos en un embudo para ver cómo el descuento impulsó las nuevas suscripciones, las actualizaciones de ingresos y ganancias, y así sucesivamente. Están bastante satisfechos con el sistema y no tenemos noticias de ellos durante un tiempo, pero luego un día vienen y nos dicen que quieren aplicar un descuento del 40% en lugar de uno del 20%. Ahora el problema es que el 20% estaba codificado en nuestra base de código. Podríamos simplemente cambiar esto a 40% para ellos, pero entonces volveríamos a caer en ese mismo proceso lento de ida y vuelta que teníamos antes de tener esta bandera de características. Veamos si podemos hacer algo similar para darles control sobre este porcentaje también.

Una cosa que podemos hacer es, en lugar de devolver un simple indicador booleano aquí, podemos devolver un objeto de descuento completo con subcampos para indicar si el descuento está activado y luego qué porcentaje debería ser. Lo primero que haremos es definir un nuevo tipo de objeto de descuento en nuestro esquema en HyperTune. Agregaremos un subcampo llamado isEnabled, que será un booleano como antes, y otro subcampo llamado percentage, que será un flotante. Luego, deprecaremos nuestro simple indicador booleano de bandera de características y agregaremos una nueva bandera llamada discount, que en lugar de devolver un booleano, devuelve un objeto de descuento completo. Luego guardaremos eso, volveremos a nuestra base de código y ejecutaremos npx-hypertune para regenerar nuestro cliente seguro por tipo. Veremos un error de tipo donde todavía estamos usando esa bandera de características obsoleta. Reemplazaremos sus instancias con nuestra nueva bandera, que es hypertune.discount.isEnabled. También reemplazaremos este porcentaje codificado aquí con nuestra nueva bandera de porcentaje. Es decir, hypertune.discount.percentage, y pasaremos un valor de respaldo completo de 0. Desplegaremos esto en producción y luego le diremos al equipo de marketing que, además de poder controlar si el descuento está activado o desactivado como antes, ahora también pueden controlar el porcentaje. Por ahora, lo activan para todos y establecen el porcentaje en 40%. Guardaremos eso y una vez que se propague, verán ese nuevo descuento del 40% en la aplicación. Esto es genial y están bastante emocionados. En su emoción, preguntan si también pueden controlar el texto del descuento aquí. Lo que podemos hacer es volver al tipo de descuento en HyperTune y agregar un nuevo campo llamado name, que estableceremos como una cadena. Usaremos esto para controlar el texto del descuento. Guardaremos eso, ejecutaremos npx hypertune nuevamente y luego reemplazaremos este texto codificado aquí con nuestra nueva bandera de cadena.

Entonces eso es hypertune.discount.name, y pasaremos un valor de respaldo de solo descuento. Ahora desplegaremos esto en producción. Y ahora el equipo de marketing puede experimentar con diferentes mensajes aquí. En lugar de venta de verano, solo tendrán descuento de verano. Y una vez que guarden eso, verán esa actualización en la aplicación.

Ahora deciden que quieren experimentar con diferentes mensajes. En lugar de tener solo una cadena aquí, agregan una prueba A-B para probar tres mensajes de descuento diferentes. Así que tendrán venta de verano, luego venta de verano termina pronto, y luego venta de verano termina hoy. Luego deciden que no quieren pasar por todos los pasos de un experimento tradicional, como esperar a que se ejecute y luego recopilar datos hasta que tengan significancia estadística, y luego elegir una variante ganadora, y luego enviar eso al 100%, y luego limpiar la prueba. Quieren automatizar todos esos pasos.

Entonces van a la página de experimentos en hypertune, y lo convierten de una prueba A-B-C en un bucle de IA. Y optimizarán automáticamente las actualizaciones. Ahora hypertune aprenderá automáticamente cuál es la mejor variante para maximizar el número de actualizaciones. Y puede tener en cuenta los atributos del usuario para aprender si la mejor variante es diferente para diferentes tipos de usuarios. Así que ahora están bastante satisfechos con este sistema. Pueden dirigir el descuento a diferentes segmentos de usuarios. Pueden realizar pruebas A-B con diferentes porcentajes. Incluso pueden usar IA para personalizar el texto del descuento.

Pero un día vienen a nosotros con un caso de uso aún más complejo. Además de poder ejecutar un descuento del 20% para todos, también quieren ejecutar un descuento adicional del 10% para los usuarios que ingresen un código de referencia especial. Por lo tanto, necesitan una forma de ejecutar múltiples descuentos superpuestos al mismo tiempo.

Ahora el problema es que solo estábamos devolviendo un solo objeto de descuento desde nuestra bandera de descuento aquí. Y por lo tanto, necesitamos devolver una lista de descuentos. Entonces lo que haremos es desaprobar esta bandera. Y luego agregaremos una nueva bandera llamada descuentos, que esta vez será una lista de objetos de descuento. Y guardaremos esto. Pero antes de hacerlo, también iremos a nuestro esquema. Y en esa bandera de descuentos, también agregaremos algunos argumentos para pasar a esta bandera específicamente. Entonces pasaremos el plan que el usuario ha seleccionado o está viendo. Y también el código que han ingresado. Ahora guardaremos eso y volveremos a nuestra base de código, ejecutaremos npx hypertune y luego veremos errores de tipo donde todavía estamos usando nuestra bandera de descuento desaprobada. Y en su lugar usaremos nuestra nueva bandera de descuentos. Así que lo hemos configurado aquí, donde estamos llamando a hypertune.descuentos. Pasamos el código que el usuario ingresó, el plan que están viendo y luego filtramos los descuentos según si están habilitados o no. Así que desplegaremos una lista de producción. Y ahora el equipo de marketing puede agregar y eliminar tantos descuentos como deseen de esta lista.

Entonces pueden tener tantos descuentos superpuestos como deseen. Lo primero que hacen es agregar un descuento que se aplica a todos los usuarios, y eso es para 20%, y eso es la venta de verano. Y si guardamos eso, entonces lo ven aparecer en la aplicación. Luego agregan otro descuento, pero esta vez solo se habilita si el usuario ha ingresado un código que es 10 off. Y de lo contrario, está desactivado. El porcentaje de descuento es del 10%. Y este es nuestro descuento especial. Así que lo guardaremos. Y por lo tanto, no vemos ese descuento del 10% en este momento, pero si ingresamos el código igual a 10 off, entonces vemos que se aplica ese descuento adicional. Entonces ahora, al igual que antes, el equipo de marketing puede realizar pruebas A-B de descuentos. Pueden dirigirse a diferentes segmentos de usuarios con descuentos, probar diferentes porcentajes e incluso personalizar el texto de cada descuento con AI, y pueden tener múltiples descuentos ejecutándose al mismo tiempo.

Al evolucionar nuestra simple bandera de función booleana en esta bandera que devuelve una lista de objetos de descuento, hemos empoderado a nuestro equipo de marketing con este sistema realmente flexible y poderoso para gestionar y optimizar descuentos por sí mismos. Y de hecho, hemos hecho algo similar con otras partes de nuestra aplicación. Aquí, el equipo de marketing puede controlar los precios de todos nuestros diferentes planes. Y aquí pueden controlar qué características están en qué planes y la cuadrícula de características que mostramos a los usuarios en la aplicación. Aquí pueden controlar todo el contenido de nuestra página de destino, como el titular y el diseño, y pueden realizar pruebas A-B con diferentes titulares e incluso utilizar AI para personalizar los titulares para diferentes visitantes. Y aquí, en realidad estamos gestionando la configuración de nuestros asistentes de IA que tenemos en nuestra aplicación. Cuando los usuarios visitan nuestra aplicación, tenemos un asistente de IA que les sugiere una función para usar según lo que sabemos sobre ellos. Y aquí estamos controlando qué modelo de IA usar, qué indicación pasar. Estamos inyectando detalles del usuario en la indicación. Por lo tanto, esto es más una plantilla de indicación. Y estamos controlando los otros parámetros que pasamos, como la temperatura, los tokens máximos. Y esto significa que podemos ajustar todos estos parámetros muy rápidamente sin tener que actualizar nuestro código y realizar otra implementación, pero también significa que podemos optimizar estos parámetros. Por lo tanto, podemos realizar pruebas A-B con diferentes indicaciones y temperaturas, como estamos haciendo aquí, para ver qué impulsa el mejor aumento métrico. E incluso podemos usar AI para decidir cuál es la mejor temperatura. Entonces, en ese caso, incluso estaríamos utilizando AI para optimizar nuestro AI. De hecho, hemos utilizado un sistema de configuración de aplicaciones como este. Es muy similar a esto en Meta. Y se llamaba Configurador. Y Meta incluso publicó un artículo sobre esto llamado Gestión de configuración holística en Facebook y profundiza en cómo se utilizó Configurador para muchos casos de uso diferentes en una forma similar a la plataforma de productos y servicios de backend.

Además de implementar funciones, se utilizó para configurar permisos de funciones y límites de uso, como límites de velocidad de API, planes de precios y lógica de facturación, copia en la aplicación, contenido del CMS, internacionalización y localización, formularios, diseños de página y embudos, todos nuestros modelos de IA, indicaciones, temperaturas, pesos, cadenas, umbrales de predicción, reglas para automatizar aprobaciones y detectar spam y fraude, mapas de redireccionamiento, tiempos de espera, números mágicos, configuraciones de integración de terceros y trabajos automatizados en el backend, y una gran cantidad de otros tipos de configuración. Sin embargo, en todos estos casos de uso de configuración diferentes, obtuvimos los mismos beneficios generales. En primer lugar, obtuvimos actualizaciones instantáneas desacopladas de las implementaciones de código y del ciclo de lanzamiento. En segundo lugar, desacoplamos las dependencias en nuestra organización. Empoderamos a otros para que se auto-servieran y realizaran cambios por sí mismos sin el proceso lento de ida y vuelta con nosotros. También significaba que podíamos centrarnos en enviar código a producción sin que ellos nos bloquearan. En tercer lugar, una vez que teníamos toda esta configuración rica, se volvió fácil optimizarla con pruebas A-B y bucles de IA automatizados. En cuarto lugar, simplificamos nuestro sistema extrayendo toda esta lógica de configuración, como el código específico del usuario, de diferentes bases de código y en una única fuente de verdad. También separamos las preocupaciones de código y configuración para poder centrarnos en la lógica de alto nivel en nuestro código y luego preocuparnos por los detalles de configuración más tarde o darle a alguien más el control sobre eso. Y en quinto lugar, obtuvimos más flexibilidad para adaptarnos a los requisitos cambiantes sin necesidad de realizar cambios en el código.

Entonces, la configuración de la aplicación es excelente, pero ¿cómo construimos un sistema de configuración de aplicaciones flexible que pueda escalar a todos esos casos de uso complejos que hemos mencionado? Bueno, primero necesitamos un lenguaje de esquema flexible y un sistema de tipos para definir las entradas que ingresan a nuestro sistema, como el entorno actual o el usuario, y las salidas que salen de nuestro sistema, como nuestras banderas de funciones o los planes de precios que ofrecemos. En segundo lugar, necesitamos un lenguaje de configuración flexible para definir la lógica que asigna las entradas a las salidas, y también deberíamos poder incorporar pruebas A-B y bucles de IA en nuestra lógica. Y luego necesitamos una interfaz de usuario para que las personas no técnicas puedan editar esa lógica de manera visual. Y en tercer lugar, necesitamos un sistema analítico para registrar eventos y luego ver los resultados de nuestras pruebas A-B y recopilar datos de entrenamiento para los bucles de IA. Cuando combinamos esos tres elementos, un lenguaje de esquema flexible, un lenguaje de configuración flexible y un sistema analítico, podemos escalar a todos los diferentes casos de uso que mencionamos anteriormente. Esto es realmente poderoso, pero también es un poco aterrador, ya que estamos trasladando la lógica empresarial fuera de nuestra base de código y hacia nuestro sistema de configuración. Si el sistema falla o realizamos un cambio incorrecto, podría causar problemas importantes. Además, tampoco queremos afectar el rendimiento o la eficiencia de nuestra aplicación al consultar un sistema de configuración externo. ¿Entonces, cómo podemos hacer que la configuración sea tan segura, confiable, eficiente y eficiente como nuestro propio código?

Bueno, primero, podemos diseñar el SDK para evaluar localmente nuestra lógica de configuración. Por lo tanto, obtiene toda la lógica de configuración del servidor de antemano en una única solicitud de red inicial. Y luego, después de eso, no hay dependencia del servidor para evaluar la configuración. Por lo tanto, es muy confiable, eficiente y eficiente. Pero aún tenemos esa única solicitud de red inicial que podría fallar. Para hacerlo más robusto, podemos incluir una instantánea de nuestra lógica de configuración en nuestro paquete de aplicaciones para que el SDK pueda usarla como respaldo en caso de que no pueda inicializarse desde el servidor. Y también podemos configurar un webhook para desencadenar una nueva compilación e implementación de nuestra aplicación cada vez que cambie la lógica de configuración, para mantener esa instantánea actualizada. Y luego, si hacemos eso, ni siquiera necesitamos inicializarnos desde el servidor en absoluto, y podemos usar el SDK en un modo solo local sin conexión. Pero luego perdemos el beneficio de poder actualizar la configuración instantáneamente desde el servidor. Pero si combinamos esos enfoques donde tenemos la instantánea actualizada en tiempo de compilación y la inicialización instantánea desde el servidor, entonces obtenemos lo mejor de ambos mundos. Lo siguiente que podemos hacer es que cuando se evalúa la configuración, podemos pasar valores de respaldo codificados en duro para el caso en que el SDK no se haya inicializado y no haya instantánea. También podemos asegurarnos de que la configuración se evalúe con una seguridad de tipos completa de extremo a extremo para evitar errores tipográficos, detectar errores en tiempo de compilación en lugar de tiempo de ejecución y permitir una experiencia de desarrollo moderna con integración de IDE para autocompletar código, encontrar todas las referencias y comentarios de js. Y finalmente, podemos controlar la versión de toda nuestra configuración en un historial estilo git para ver exactamente qué cambió y cuándo, con diferencias claras de nuestros cambios y ramas para probar y previsualizar cambios antes de fusionarlos en la rama principal para la solicitud de extracción. También podemos agregar roles y permisos de equipo para requerir que los cambios se revisen primero en una solicitud de extracción para incorporar de manera segura a miembros del equipo no técnicos. Entonces, para resumir, con la evaluación local, las instantáneas en tiempo de compilación, la seguridad de tipos y el control de versiones estilo git, podemos obtener un nivel similar de seguridad, confiabilidad, rendimiento y eficiencia como nuestro propio código. No hay ninguna herramienta o plataforma como esta, por lo que creamos Hypertune y aquí hay algunos enlaces para que nos conozcas. Y gracias por escuchar hoy. Espero que hayas disfrutado la charla.