Usando TypeScript con Bases de Datos Clave/Valor

¿Cómo les va, gente? Mi nombre es Kevin Winery y hoy vamos a hablar un poco sobre las bases de datos clave-valor. Y si nunca has utilizado una base de datos KV antes en el contexto de una aplicación web JavaScript, creo que realmente lo disfrutarás y aprenderás cómo es un poco diferente a algunas de las otras bases de datos que has utilizado antes y cuándo podrías querer aplicar esta tecnología en el código que ya estás escribiendo.

Entonces, en esta presentación específicamente, vamos a echar un vistazo a algunas de las características clave que hacen que una base de datos KV sea diferente de una base de datos relacional que podrías haber utilizado en el pasado. También examinaremos algunos de los casos de uso para los cuales una base de datos KV es especialmente adecuada y podría ser la herramienta que elijas en esos contextos. También veremos algunas de las diferentes opciones de bases de datos KV que existen. Hay una serie de plataformas alojadas, proveedores y proyectos de código abierto que ofrecen bases de datos KV. Así que echaremos un vistazo a algunas de las diferentes variantes de bases de datos KV que existen y qué las hace diferentes. Y finalmente, veremos cómo utilizar una base de datos KV en el contexto de una aplicación TypeScript, y cómo resolver algunos de los desafíos de programación comunes a los que probablemente te enfrentarás si estás utilizando una base de datos KV.

Así que vamos a sumergirnos hablando un poco sobre las características clave de una base de datos KV. Y lo que realmente se reduce a dos cosas clave. Una base de datos KV es realmente buena para almacenar estructuras de datos no relacionales. Y también está optimizada para ser altamente disponible y tolerante a particiones. Y nos adentraremos un poco más en ambos aspectos para entender qué significa eso. Pero comenzaremos con lo que quiero decir cuando digo estructuras de datos no relacionales, específicamente, y por qué una base de datos KV está optimizada para esas cosas. Entonces, como desarrollador de JavaScript, una estructura de datos como esta es probablemente algo que has visto antes. Es un objeto literal con claves que se asignan a otros objetos literales que contienen datos sobre un usuario que está dentro de tu aplicación, su nombre completo, su dirección de correo electrónico y cosas así. Y una base de datos KV funciona de manera similar a un objeto literal o un mapa del mundo de JavaScript. donde tienes una clave que se asigna uno a uno a un valor en tu aplicación de algún tipo.

Y esos valores pueden ser objetos JavaScript arbitrarios estructurados como desees. Y las claves, dependiendo de la base de datos que estés utilizando, pueden ser simplemente una cadena simple o una clave podría ser como un valor compuesto, como un array que podría tener múltiples tipos diferentes de valores que se combinan para formar un identificador único para uno de los valores en tu base de datos.

Ahora, la característica clave allí, sin embargo, es esa correspondencia uno a uno entre una clave y algún tipo de valor que existe en tu base de datos. Y la forma en que normalmente interactúas con una base de datos KV desde tu código es que especificarás una clave, crearás un valor, a menudo en un contexto de TypeScript habrá información de tipo asociada con ese valor antes de que se elimine en tiempo de ejecución y se convierta en un simple objeto JavaScript. Y hay una API de obtener y establecer que generalmente estará disponible en cada base de datos KV donde puedes asociar algún fragmento de datos con una clave particular en tu base de datos.

Y además de tener esta correspondencia uno a uno, también hay un par de técnicas que utilizarás para datos más complejos dentro de tu aplicación. Y una de esas cosas es el concepto de una jerarquía que podría existir en tu aplicación también. Porque una base de datos KV, por sí sola, es bastante limitada en lo que puede expresar en términos de la estructura de tus datos. Hay una clave, hay un valor, eso es prácticamente todo.

Y para casos de uso más simples como almacenar preferencias de usuario u otros casos de uso que veremos en un momento, eso podría estar bien. Pero al emplear solo un par de trucos diferentes en cómo piensas en tus datos, puedes obtener mucho más valor y expresar mucho más significado en tu base de datos clave-valor al introducir algunas técnicas diferentes en cómo administras tu espacio de claves o el conjunto de claves que utilizas para asignar tus datos. Y una de esas cosas es una jerarquía.

Entonces, si has estado en el desarrollo web durante un tiempo, es posible que hayas utilizado una API RESTful donde este concepto de datos jerárquicos y a medida que construyes URLs, puedes inferir a partir de la estructura de la URL cómo se puede utilizar el datos que se encuentra en un recurso particular dentro de tu aplicación. Y cuando estás diseñando claves para los datos en tu base de datos, en realidad puedes pensar en ello de una manera muy similar donde puedes crear una jerarquía de datos en cómo estructuras tus claves. Así que verás ejemplos aquí donde si estás almacenando datos en una base de datos KV para una publicación de blog, podrías estructurar la clave de tal manera que haya una clave de publicación que luego se siga por un año clave y luego puedes construir una clave progresivamente utilizando las diferentes partes del slug de la publicación del blog o como el mes y el día en que se publicó. Y ahora tienes como parte de tu clave en realidad codificado algún datos útil que luego podrías usar más adelante para tal vez obtener todas las publicaciones de blog de un año o de un mes en particular. Entonces, estructurar tus datos de manera jerárquica te brinda una forma de agregar un poco de valor y significado adicional a las claves que estás utilizando para tus datos.

La otra técnica muy común que vas a utilizar en una base de datos KV es esta idea de un índice secundario. Las bases de datos KV no son relacionales, por lo que no vas a almacenar una tabla de unión que mapee un registro en una tabla de datos a otro. Pero eso no significa que no puedas mantener ningún tipo de relaciones o tener diferentes formas de abordar tus datos.

Entonces, una necesidad común es poder acceder al mismo tipo de información mediante una clave ligeramente diferente. Así que imaginemos que tienes una base de datos de usuarios y la clave principal que utilizas para eso es el nombre de usuario del usuario. Esa es la identificación principal que tienes para ellos en tu sistema. Sin embargo, la dirección de correo electrónico de un usuario podría ser otra forma de distinguir de manera única a un usuario en tu aplicación, por lo que deseas poder abordar y obtener datos de un usuario basado en eso también. Entonces, lo que harías es, cuando almacenes la información en tu almacén KV bajo una ID, al mismo tiempo almacenarías esa misma información bajo otra ID o un índice secundario que te permitiría buscar la misma información utilizando ese índice secundario. Y típicamente lo que harías es que almacenarías en ese índice secundario, simplemente almacenarías cualquiera que sea el valor de clave para el índice principal y luego usarías eso para que, sabes, solo un valor en tu base de datos sea la fuente de verdad para los datos asociados con ese registro.

Entonces, con una combinación de estructuras de datos jerárquicas e índices secundarios, puedes crear modelos de datos bastante complejos dentro de una base de datos KV. Tal vez no al mismo nivel que una base de datos relacional, pero te sorprendería cuánto puedes lograr con solo estas dos técnicas.

Así que hablamos un poco sobre una base de datos KV siendo una estructura de datos no relacional, hablemos un poco sobre algunas de las partes técnicas que la hacen diferente de una base de datos relacional, y específicamente sobre cómo este tipo de bases de datos tienden a ser muy altamente disponibles y tolerantes a particiones. Y para entender qué significan esas palabras, haremos un rápido y profundo recorrido para hablar de esta idea del teorema CAP.

Entonces, en una base de datos distribuida, la idea es que solo puedes garantizar que dos de estas tres cosas sean ciertas para un sistema de base de datos distribuida. Los datos que están en el sistema de base de datos pueden tener una alta disponibilidad, lo que significa que cada vez que intentas comunicarte con la API, te dará alguna respuesta, incluso si puede que no sea consistente. Y consistente significa que los datos que lees cada vez serán los mismos en diferentes clientes. Entonces, si estás en India leyendo un valor de la base de datos y yo estoy aquí en Estados Unidos leyendo un valor de la base de datos, ambos vemos los mismos datos. Eso se considera consistente.

La tolerancia a particiones significa que tu base de datos, al estar distribuida en múltiples máquinas, puede seguir interactuando con tu base de datos incluso cuando diferentes nodos del sistema se caigan. Y en un sistema de base de datos distribuida, realmente debes tener tolerancia a particiones o no funcionará muy bien. Por lo general, cuando diseñas una base de datos, debes optimizar en una dirección u otra entre disponibilidad y consistencia. Y las bases de datos clave-valor tienden a favorecer la alta disponibilidad en lugar de la consistencia para algunos casos de uso.

La primera razón es que los casos de uso de las bases de datos clave-valor realmente están interesados en lecturas muy rápidas. Queremos que sean muy rápidas y de alto volumen. Por lo tanto, la disponibilidad termina siendo mucho más importante para algunos casos de uso como almacenar un carrito de compras o las preferencias del usuario en lugar de que esos datos sean altamente consistentes. Y el tipo de compensación que a menudo se hace es esta idea de que los datos que provienen de una base de datos clave-valor son eventualmente consistentes. Por lo tanto, puede ser el caso de que cuando lees un valor de una base de datos KV, puede que no sea exactamente el mismo que un valor que se está leyendo en algún lugar del mundo porque tal vez, después de que los datos se hayan escrito en tu base de datos, no se hayan replicado en cada nodo de la red. Entonces es ligeramente diferente. Hay diferentes escenarios en los que los datos pueden no ser completamente consistentes todo el tiempo. Pero para algunos casos de uso, está bien. Es solo un conjunto diferente de compensaciones que harías dependiendo de lo que estés tratando de implementar.

Por lo tanto, también es útil pensar en una base de datos KV en comparación con una base de datos relacional. Una base de datos KV tiende a ser muy buena en lecturas y escrituras rápidas. Debido al mapeo uno a uno entre una clave y un valor, leer un fragmento de datos es muy rápido, y escribir un fragmento de datos también es muy rápido. Esas operaciones tienden a ser muy rápidas.

Debido a que las estructuras de datos que estás almacenando son bastante simples y la API para almacenar esos datos es bastante simple, es realmente bueno para almacenar datos que se modelan muy cerca de los datos que existen en tu aplicación. En ese ejemplo que vimos antes, vimos un objeto literal que pudimos almacenar en la base de datos y recuperar de la base de datos sin tener que hacer muchos malabarismos para convertirlo en un formato que nuestra aplicación pudiera entender.

En el lado de la base de datos relacional, las lecturas siguen siendo bastante rápidas, pero debido a que admiten consultas muy avanzadas, las lecturas pueden ser un poco más lentas que en el contexto de una base de datos clave-valor que solo tiene que hacer una búsqueda de O(1) en un fragmento de datos en particular. Y debido a que los datos en una base de datos relacional son relacionales, hay tablas de unión y punteros a otras tablas dentro de los datos. La forma en que se expresa esos datos es un poco más compleja y a veces las API para interactuar con una base de datos relacional también son un poco más complejas. Y tienes que hacer un poco de trabajo adicional para que los datos que existen en la base de datos se ajusten a un formato que tenga sentido en tu código.

Por eso a menudo verás tecnologías como los mapeadores objeto-relacional que existen para traducir de datos tabulares a un modelo de objeto que tiene más sentido para nosotros como programadores. Algo en lo que las bases de datos clave-valor, especialmente en relación con las bases de datos relacionales, no son tan buenas son las capacidades de consulta. Algunas bases de datos clave-valor proporcionan cierta capacidad de consulta para que puedas hacer referencia a los valores de los objetos y consultarlos desde tu base de datos de esa manera. Pero esas capacidades, como regla general, son mucho menos robustas que las disponibles en una base de datos SQL. Poder hacer consultas SQL en tus datos es probablemente la forma más poderosa que existe de poder consultar tus datos de esa manera. Así que es un compromiso que estás haciendo ahí.

Una base de datos relacional también tiende a ser consistentemente fuerte, por defecto. Por lo tanto, para crear un sistema de registro o algún tipo de sistema para el cual la integridad transaccional y la integridad de datos son muy importantes, una base de datos relacional a veces puede ser la opción adecuada. Aunque muchas bases de datos clave-valor tienen modos de consistencia fuerte en los que pueden operar tanto en lecturas como en escrituras. Por lo tanto, no es tanto un compromiso como algo que está habilitado de forma predeterminada en una base de datos relacional. Y es algo que debes tener en cuenta cuando utilizas una base de datos KV, como el compromiso que estás haciendo por la velocidad, por la alta disponibilidad, a veces se hace en términos de consistencia. Por lo tanto, los datos que tus clientes están leyendo en un momento dado pueden ser diferentes, y debes diseñar tu sistema teniendo eso en cuenta.

Entonces, con esas diferencias en mente, los casos de uso para los que quieres aplicar una base de datos KV serían casos de uso en los que el modelo de datos es muy simple y los mapeos uno a uno de una clave a un valor realmente no representan una desventaja. Por lo tanto, casos de uso como los carritos de compras que mencioné, donde tienes un usuario registrado y su estado de carrito de compras está muy vinculado a ese usuario en particular. El mapeo uno a uno de usuario a estado de carrito de compras no importa realmente, por lo que realmente puedes aprovechar las lecturas y escrituras rápidas en una base de datos KV. O como un estado de juego en tiempo real de algún tipo donde, nuevamente, tienes una posición en un mundo de juego que se asigna uno a uno a un jugador en particular. A menudo, una base de datos KV puede ser un caso de uso realmente bueno para ese tipo de cosas también. Pero incluso si estás construyendo una aplicación CRUD que es razonablemente compleja, si puedes utilizar índices secundarios y algunas de las otras estrategias que mencionamos brevemente antes, es posible que una base de datos KV sea la forma más fácil de construir algunas de esas aplicaciones CRUD simples que todos construimos todos los días. Por lo tanto, la simplicidad de las estructuras de datos y saber cómo vas a necesitar consultar tus datos de antemano pueden ser indicadores de que una base de datos KV será una buena elección para la aplicación que estás construyendo. Por otro lado, si tienes la sensación de que sabes que tus datos van a necesitar ser consultados, tal vez haya interfaces administrativas donde no puedas predecir de manera ordenada cómo tus usuarios van a querer extraer datos del sistema, una base de datos relacional podría ser una mejor opción para ese tipo de caso de uso.

Si los datos son naturalmente relacionales, donde un usuario tiene muchas fotos y los grupos tienen muchos usuarios, y las relaciones entre diferentes piezas de datos son una parte importante del modelo de datos, entonces una base de datos relacional tiene mucho sentido y probablemente sea una opción mucho mejor. También hay casos de uso en los que se desea una alta consistencia, donde si estás almacenando registros de empleados o ejecuciones de nómina, ese tipo de cosas, podría ser deseable preferir un sistema que sea fuertemente consistente la mayor parte del tiempo. Tal vez a expensas de la disponibilidad, tal vez el sistema esté inactivo durante un período de tiempo sea menos disruptivo que esos datos estén inconsistentes por cualquier motivo. Ahora que hemos hablado un poco sobre las bases de datos KV y cómo son diferentes de otras, cuáles son sus características únicas, echemos un vistazo a algunas de las opciones disponibles para las bases de datos KV. A la izquierda, tenemos las dos principales bases de datos KV propietarias que forman parte de una oferta en la nube, tanto en el lado de AWS como en el lado de CloudFlare. DynamoDB es una opción interesante de base de datos que se encuentra en un espacio entre una base de datos KV pura y algo como MongoDB, que es puramente una base de datos de documentos, porque en realidad tiene ambos modos de operación donde puedes almacenar documentos en DynamoDB, así como también objetos de datos KV más crudos. Por supuesto, Dynamo está alojado por AWS y está completamente administrado de esa manera. CloudFlare Worker KV es otra opción donde, en el contexto de un worker de CloudFlare, puedes acceder a un motor de almacenamiento de clave-valor muy simple y ligero. Y luego, a la derecha, tenemos un par de opciones de código abierto, siendo Redis una de ellas. Si has oído hablar de una base de datos KVE antes, existe una excelente posibilidad de que Redis sea la que hayas oído o probado y utilizado antes. Una menos conocida es FoundationDB. Es un proyecto de código abierto de Apple que utilizan para iCloud y muchas otras aplicaciones dentro de su entorno. Y es muy similar a Redis en algunos aspectos, pero tiene cierta flexibilidad y durabilidad que se encuentra en DynamoDB u otras bases de datos más tradicionales. Por lo tanto, Redis y FoundationDB, ambas opciones de código abierto, si las vas a utilizar en una aplicación hoy en día, probablemente habrá algún tipo de proveedor de alojamiento involucrado si no quieres ejecutarlo tú mismo. Para Redis, hay muchos hosts de Redis diferentes. Uno excelente es Upstash, y de hecho, creo que si has utilizado Vercell KV, creo que ellos revenden Upstash como parte de esa oferta. Upstash es una gran versión alojada. Y para FoundationDB, Dino Deploy implementa la API Dino KV, que veremos aquí en un segundo, y en realidad utiliza FoundationDB en producción para respaldar esa API también. Entonces, muy rápidamente desglosando algunas de las diferencias. Tienden a dividirse en cómo se modelan los datos y cómo interactúas con los datos en la base de datos, y cuáles son las diferentes garantías y comportamientos en cuanto a durabilidad, consistencia y disponibilidad. Por lo tanto, con Redis, creo que de las cuatro opciones aquí arriba, tiende a ofrecer el conjunto más robusto de comandos y diferentes formas en las que puedes almacenar datos en la base de datos. En la documentación, se describe a sí mismo como un servidor de estructura de datos, y creo que eso es cierto. Hay muchas formas diferentes en las que puedes estructurar datos en el sistema. También tienen un conjunto muy amplio de consultas y comandos que puedes ejecutar para los datos que se almacenan en Redis, y scripting de Lua, porque ¿por qué no, supongo? Es posible encapsular cierta lógica empresarial y alojarla en tu base de datos también. Algunas cosas a tener en cuenta en el lado de Redis es que tus datos son duraderos ya que Redis es un almacén de datos en memoria, lo cual es una de las razones por las que es tan rápido, y puede funcionar muy bien como una caché además de ser un almacén de datos principal. Puede hacer copias de seguridad continuas del contenido del almacenamiento en memoria en disco, por lo que es razonablemente duradero después de escribir un valor en el almacenamiento en memoria. Pero hay algunas advertencias que debes entender, que definitivamente van más allá del alcance de esta charla. Pero parte de la durabilidad de Redis es algo que debes tener en cuenta en cómo configuras cuándo y cómo los datos que existen en memoria en Redis se envían al disco y luego se replican en otros nodos de un clúster, ese tipo de cosas. Redis también admite transacciones para escrituras.

Entonces, puedes tener una cantidad razonable de confianza de que, mientras estás escribiendo datos, nada está cambiando de manera que invalide la transacción. Redis admite consistencia eventual para lecturas y no un modo de lectura fuertemente consistente. Básicamente, esto significa que es posible que un cliente de una base de datos Redis escriba un valor en la base de datos y reciba una respuesta de inmediato, indicando que la escritura fue exitosa. Pero todo eso podría suceder antes de que los datos en tu clúster de Redis se repliquen en otros nodos. Por lo tanto, existe la posibilidad de que un cliente en otro lugar esté recibiendo una versión obsoleta de un dato que fue modificado por Redis. La consistencia eventual para lecturas es simplemente parte de cómo funciona el sistema.

Para DynamoDB, nuevamente, ofrece un conjunto bastante robusto de capacidades de consulta porque admite tanto datos de documentos como valores clave. Por lo tanto, puedes realizar consultas en campos reales dentro de los datos con los que estás trabajando. Y en general, hay un conjunto bastante flexible de opciones para almacenar y consultar los datos una vez que están allí. Las escrituras en DynamoDB serán inmediatamente duraderas después de realizar esas solicitudes. Existe un sistema de transacciones para escrituras, por lo que puedes orquestar actualizaciones más complejas de esa manera. Y DynamoDB admite tanto el modo de consistencia eventual como el modo de consistencia fuerte para lecturas. Por lo tanto, como cliente, puedes decidir qué es lo más importante para ti. ¿Realmente te importa obtener la última versión absoluta de un dato? ¿O estás bien con la consistencia eventual? Y hay muchos casos de uso para los cuales la consistencia eventual es completamente aceptable.

Para CloudFlare Workers KB, es una API de nivel bastante bajo con funciones de obtener y establecer, y hay cierta cantidad de filtrado en el prefijo de las claves. Pero una de las razones por las que es realmente rápido es porque no hay mucho que puedas hacer en términos de filtrado y consulta, y ese tipo de cosas. Las escrituras son inmediatamente duraderas cuando escribes un valor en una base de datos de CloudFlare KB Worker. Pero no hay garantía para las escrituras. Por lo tanto, no tiene un sistema de transacciones de manera que cuando estás escribiendo en una clave, podría ser que en el transcurso de lo que de otra manera podrías querer tener una transacción, los datos podrían cambiar. Por lo tanto, en ese tipo de escenario, es realmente importante comprender tu caso de uso y qué tan probable es que los datos se escriban debajo de ti y qué tan importante es eso para tu aplicación. En realidad, hay muchos casos de uso para los cuales eso no es un problema o simplemente no sucede con frecuencia. Especialmente en casos de uso como el carrito de compras, donde realmente hay una relación uno a uno entre una clave y un dato. Por lo tanto, esos tipos de casos de uso son adecuados. También tienen consistencia eventual para lecturas sin un modo de consistencia fuerte. Por lo tanto, es muy posible que un dato que obtengas de la base de datos de CloudFlare Workers KV pueda ser modificado y tal vez no sea la misma versión de los datos que alguien más está viendo. Entonces, si estás de acuerdo con esa consistencia eventual y ese comportamiento de escritura, tu recompensa es un rendimiento bastante sólido cuando usas la API.

En el caso de Foundation DB, es una capa por encima de lo que acabo de describir para CloudFlare Workers' KV, con algunos comandos adicionales para filtrado y ordenación, pero también en cuanto a la durabilidad y consistencia, es un poco más similar a lo que sucede en DynamoDB, donde las escrituras serán inmediatamente duraderas. Existe un sistema de transacciones para garantizar que tus datos se escriban de manera consistente, y también tienes la opción entre consistencia eventual o fuerte en las lecturas. Por lo tanto, como desarrollador, puedes decidir qué es lo más importante para un escenario dado.

De acuerdo, ahora que hemos tenido la oportunidad de ver los diferentes tipos de bases de datos KV, hablemos un poco sobre cómo se usaría en TypeScript. El desafío de usar una base de datos KV en TypeScript tiende a estar en la serialización y deserialización de datos no estructurados en objetos tipados. Y este no es un problema único de las bases de datos KV. Si estás trabajando con una API JSON, este es un desafío que ya has encontrado en TypeScript, pero es algo con lo que debes lidiar.

También existe la idea de los índices secundarios y las relaciones. Hay algunas capas de abstracción sobre las bases de datos KV que pueden ayudar un poco con esto, pero en general, querrás escribir tu propia capa de servicio que se sitúe encima de tu base de datos y opere en esos objetos de dominio. Y finalmente, deberás abordar la validación. Querrás asegurarte de que los datos que estás escribiendo en tu base de datos KV coincidan con la estructura de los objetos tal como lo pretendes en tu código TypeScript.

Entonces, nuestra estrategia general aquí será implementar una especie de interfaz funcional pura que nuestro código pueda consumir. Y simplemente opera en objetos fuertemente tipados. Podemos pedirle a esa interfaz de servicio que guarde objetos y los recupere para nosotros. Y los clientes de esa interfaz no sabrán que esos datos provienen de una base de datos KV o lo que esa capa de servicio necesita hacer para que los datos funcionen de esa manera. Y para la validación, en realidad me gusta usar una biblioteca de terceros llamada Zod, que te ayuda a configurar de forma declarativa lo que será necesario para que un objeto se valide correctamente y también te brinda un tipo TypeScript que puedes exportar y usar en toda tu aplicación para comprender cómo debe ser la estructura de tu objeto.

Así que voy a demostrar brevemente esta aplicación. Les mostraré qué hace. Vamos a analizar un poco el código. El código fuente estará disponible en GitHub, por lo que si desean tomarse su tiempo y analizarlo más detenidamente, tendrán la opción de hacerlo.

Pero por ahora, saltemos al navegador. Aquí tengo un formulario simple donde pueden ingresar un nombre de usuario, un correo electrónico y una preferencia de interfaz de usuario. Cuando hacen clic en el botón, se guardan sus preferencias. Una cosa que hace esta aplicación de muestra es mostrar cómo se utiliza esta idea de índice secundario. Al agregar este parámetro de consulta, pueden acceder a los mismos datos ya sea por nombre de usuario o por dirección de correo electrónico. Este es un patrón de uso bastante común para una base de datos KV y también es un tipo de dato bastante típico que se almacenaría en una base de datos KV también.

Tengo un enum de TypeScript para el tema de la interfaz de usuario y luego uso Zod para configurar un objeto para las preferencias del usuario. Zod tiene un validador de correo electrónico. Hay una forma de asegurarse de que el tema esté configurado como uno de los miembros de la enumeración que tenía antes. Y también, puedes establecer requisitos de longitud mínima para el nombre de usuario y cosas así. Y algo muy bueno es que exporta un tipo de TypeScript que tiene el tipo de información que desearías como consumidor. Es como lo que obtendrías si simplemente creara una interfaz, pero en lugar de solo obtener eso, también tengo esta lógica de validación aquí.

Y como parte de esta interfaz, tengo una función para almacenar preferencias y esto implementa el índice secundario del que hablaba antes. Así que comienzo aquí analizando un objeto de entrada y lanzará errores si hay algo incorrecto con la estructura de ese objeto. Y luego, dependiendo de, ya sabes, el motor de almacenamiento seleccionado, tengo esta función que almacena eso en realidad en la base de datos kv. Y si abro la implementación de Deno kv, utiliza la base de datos kv incorporada que es parte del tiempo de ejecución de Deno. Entonces, si instalas Deno, lo obtienes de forma gratuita y simplemente puedes usarlo llamando a await Deno open kv. Y aquí creo tanto mi clave primaria como mi clave secundaria para las preferencias y las preferencias por correo electrónico. Y luego hago una operación atómica donde intentaré establecer ambas claves a la vez. Y si alguna de esas cosas falla, entonces toda la transacción falla. Así que tengo las preferencias configuradas, que realmente tienen los datos para el objeto. Y luego configuro mi clave secundaria alrededor del correo electrónico. Y de manera similar para obtener preferencias o obtener preferencias por correo electrónico, tengo funciones para ambas opciones. Y para obtener preferencias por correo electrónico, comienzo obteniendo la clave primaria del objeto, que se almacena por correo electrónico. Y luego busco la fuente de verdad a partir de la clave primaria, que está asociada con un nombre de usuario. Así que nuevamente, recomiendo que revisen el código de esto. Pueden jugar con él. Y hay una versión que usa tanto Deno KV como Redis. Así que pueden ver cómo difieren esas dos implementaciones. Así que definitivamente les animo a que lo revisen. Pero estamos un poco cortos de tiempo. Así que voy a terminar aquí. Y una vez más, agradecer a todos por estar en el Congreso de TypeScript hoy. Espero que hayan aprendido un poco sobre las bases de datos clave-valor. Y espero que se diviertan usándolas en su próximo proyecto. Nos vemos pronto.