Usando TypeScript con Bases de Datos Clave/Valor

Rate this content
Bookmark

Las bases de datos clave/valor (KV) se están volviendo cada vez más populares en las aplicaciones web. Sus tiempos de respuesta súper rápidos y su capacidad para admitir lecturas de consistencia eventual las hacen especialmente adecuadas para aplicaciones que se ejecutan en servidores distribuidos globalmente. Pero con lo rápido que avanza esta tecnología, es posible que no esté completamente actualizado sobre cómo usar este tipo de base de datos con TypeScript. En esta sesión, exploraremos buenos casos de uso para las bases de datos KV, examinaremos varias opciones de implementación en producción y demostraremos cómo hidratar de manera efectiva objetos TypeScript a partir de valores en una base de datos KV.

31 min
21 Sep, 2023

AI Generated Video Summary

Las bases de datos clave/valor están optimizadas para alta disponibilidad y tolerancia a particiones, lo que las hace ideales para almacenar estructuras de datos no relacionales. Priorizan la velocidad y la alta disponibilidad sobre la consistencia, lo que las hace adecuadas para modelos de datos simples o mapeos uno a uno. Sin embargo, tienen capacidades de consulta limitadas en comparación con las bases de datos relacionales. Algunas opciones disponibles para bases de datos clave/valor incluyen DynamoDB, CloudFlare Worker KV, Redis y FoundationDB. El uso de bases de datos clave/valor en TypeScript requiere abordar desafíos como la serialización, deserialización, índices secundarios, relaciones y validación. La charla incluye una demostración de una aplicación que muestra el uso de índices secundarios y la implementación de una base de datos clave/valor en Deno o Redis.

1. Introducción a las bases de datos clave-valor

Short description:

En esta parte, discutiremos las características clave de una base de datos clave-valor, incluyendo su capacidad para almacenar estructuras de datos no relacionales y su optimización para alta disponibilidad y tolerancia a particiones. También exploraremos diferentes variantes de bases de datos clave-valor y cómo utilizarlas en aplicaciones TypeScript.

¿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.

2. Características clave y técnicas de las bases de datos clave-valor

Short description:

En esta parte, discutiremos las características clave de una base de datos clave-valor, incluyendo su capacidad para almacenar estructuras de datos no relacionales y su optimización para alta disponibilidad y tolerancia a particiones. También exploraremos diferentes técnicas, como estructuras de datos jerárquicas e índices secundarios, que se pueden utilizar para crear modelos de datos complejos dentro de una base de datos clave-valor.

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.

3. Bases de datos distribuidas y compensaciones clave-valor

Short description:

En un sistema de bases de datos distribuidas, debes optimizar entre disponibilidad y consistencia. Las bases de datos clave-valor priorizan la alta disponibilidad para lecturas rápidas, incluso si los datos pueden no ser completamente consistentes en todos los nodos. Esta compensación depende del caso de uso específico y de la importancia de la consistencia.

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.

4. Comparación de Bases de Datos Clave-Valor y Relacionales

Short description:

Una base de datos clave-valor (KV) se destaca por su rapidez en lecturas y escrituras debido a su mapeo uno a uno entre claves y valores. Es ideal para almacenar datos que se ajustan estrechamente a los datos de tu aplicación. Sin embargo, las bases de datos KV tienen capacidades de consulta limitadas en comparación con las bases de datos relacionales, que ofrecen opciones de consulta más avanzadas. Las bases de datos relacionales son consistentes por defecto, lo que las hace adecuadas para sistemas que requieren transacciones e integridad de datos. Las bases de datos KV priorizan la velocidad y la alta disponibilidad, a veces sacrificando la consistencia. Utiliza bases de datos KV para modelos de datos simples o mapeos uno a uno, como carritos de compras o estados de juegos en tiempo real. Incluso las aplicaciones CRUD complejas pueden beneficiarse de las bases de datos KV si se utilizan índices secundarios y otras estrategias. Si prevés la necesidad de consultas complejas o extracciones de datos impredecibles, una base de datos relacional puede ser una mejor opción.

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.

5. Bases de Datos Clave-Valor: Opciones y Diferencias

Short description:

Si los datos son naturalmente relacionales, una base de datos relacional es una mejor opción. Para casos de alta consistencia, puede preferirse un sistema fuertemente consistente. Veamos algunas opciones disponibles para las bases de datos KV. DynamoDB es una base de datos híbrida con modos de datos de documentos y KV sin procesar. CloudFlare Worker KV proporciona un motor de almacenamiento ligero de clave-valor. Redis y FoundationDB son opciones de código abierto, siendo Redis el más conocido. Redis ofrece un conjunto robusto de comandos y opciones de estructura de datos. Se puede utilizar como caché o almacén de datos principal. Los datos de Redis son duraderos, pero se requiere configuración. Redis admite transacciones para escrituras.

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.

6. Usando Bases de Datos KV en TypeScript

Short description:

Redis admite consistencia eventual para lecturas, mientras que DynamoDB ofrece un conjunto robusto de capacidades de consulta y admite consistencia eventual o fuerte. CloudFlare Workers KB proporciona escrituras rápidas pero no garantiza las escrituras, lo que lo hace adecuado para casos de uso específicos. Foundation DB ofrece un sistema de transacciones y la opción entre consistencia eventual o fuerte en las lecturas.

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.

7. Integrando Bases de Datos KV con TypeScript

Short description:

En TypeScript, usar una base de datos KV puede ser desafiante debido a la necesidad de serializar y deserializar datos no estructurados en objetos tipados. Además, se deben abordar los índices secundarios, las relaciones y la validación. Una estrategia recomendada es implementar una interfaz funcional pura que opere en objetos fuertemente tipados. La interfaz de servicio puede encargarse de guardar y recuperar objetos, mientras que una biblioteca como Zod se puede utilizar para la validación declarativa.

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.

8. Demonstración de una Aplicación de Base de Datos KV

Short description:

Voy a demostrar brevemente una aplicación que permite a los usuarios ingresar sus preferencias y guardarlas utilizando una base de datos clave-valor (KV). La aplicación muestra el uso de un índice secundario para acceder a los datos por nombre de usuario o dirección de correo electrónico. Este es un patrón de uso común para las bases de datos KV.

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.

9. Aplicación del Servidor y Configuración de Objetos

Short description:

Esta parte discute la aplicación del servidor construida en Deno y sus opciones para usar Deno KV o Redis. Cubre la fachada del servicio, la tipificación de objetos y el uso de Zod para la validación. Se explica la implementación del índice secundario, junto con la selección del motor de almacenamiento. Se muestra la implementación de Deno KV, incluyendo la creación de claves primarias y secundarias y la operación atómica para establecerlas. Se proporcionan funciones para almacenar y recuperar preferencias, con un enfoque en obtener preferencias por correo electrónico. Se recomienda explorar el código, especialmente la comparación entre las implementaciones de Deno KV y Redis. La parte concluye agradeciendo a la audiencia y animando a utilizar bases de datos clave-valor en proyectos futuros.

y dentro del código hay una aplicación del servidor, en realidad está construida sobre Deno. Hay opciones para usarlo con Deno KV o con Redis y también agregaré algunas opciones más a medida que pasa el tiempo. Y pueden ver cómo hago la fachada del servicio y también manejo la tipificación para estos objetos. Y la mayor parte de la acción ocurre en este archivo userpreferences.ts donde configuro la estructura de mi objeto.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Vue.js London 2023Vue.js London 2023
30 min
Stop Writing Your Routes
The more you keep working on an application, the more complicated its routing becomes, and the easier it is to make a mistake. ""Was the route named users or was it user?"", ""Did it have an id param or was it userId?"". If only TypeScript could tell you what are the possible names and params. If only you didn't have to write a single route anymore and let a plugin do it for you. In this talk we will go through what it took to bring automatically typed routes for Vue Router.
TypeScript Congress 2023TypeScript Congress 2023
31 min
Making Magic: Building a TypeScript-First Framework
I'll dive into the internals of Nuxt to describe how we've built a TypeScript-first framework that is deeply integrated with the user's IDE and type checking setup to offer end-to-end full-stack type safety, hints for layouts, middleware and more, typed runtime configuration options and even typed routing. Plus, I'll highlight what I'm most excited about doing in the days to come and how TypeScript makes that possible not just for us but for any library author.
React Day Berlin 2023React Day Berlin 2023
21 min
React's Most Useful Types
We don't think of React as shipping its own types. But React's types are a core part of the framework - overseen by the React team, and co-ordinated with React's major releases.In this live coding talk, we'll look at all the types you've been missing out on. How do you get the props type from a component? How do you know what ref a component takes? Should you use React.FC? And what's the deal with JSX.Element?You'll walk away with a bunch of exciting ideas to take to your React applications, and hopefully a new appreciation for the wonders of React and TypeScript working together.
React Advanced Conference 2021React Advanced Conference 2021
6 min
Full-stack & typesafe React (+Native) apps with tRPC.io
Why are we devs so obsessed with decoupling things that are coupled nature? tRPC is a library that replaces the need for GraphQL or REST for internal APIs. When using it, you simply write backend functions whose input and output shapes are instantly inferred in your frontend without any code generation; making writing API schemas a thing of the past. It's lightweight, not tied to React, HTTP-cacheable, and can be incrementally adopted. In this talk, I'll give a glimpse of the DX you can get from tRPC and how (and why) to get started.
TypeScript Congress 2022TypeScript Congress 2022
10 min
How to properly handle URL slug changes in Next.js
If you're using a headless CMS for storing content, you also work with URL slugs, the last parts of any URL. The problem is, content editors are able to freely change the slugs which can cause 404 errors, lost page ranks, broken links, and in the end confused visitors on your site. In this talk, I will present a solution for keeping a history of URL slugs in the CMS and explain how to implement a proper redirect mechanism (using TypeScript!) for dynamically generated pages on a Next.js website.

Add to the talk notes: https://github.com/ondrabus/kontent-boilerplate-next-js-ts-congress-2022 

Workshops on related topic

React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2022React Advanced Conference 2022
148 min
Best Practices and Advanced TypeScript Tips for React Developers
Featured Workshop
Are you a React developer trying to get the most benefits from TypeScript? Then this is the workshop for you.In this interactive workshop, we will start at the basics and examine the pros and cons of different ways you can declare React components using TypeScript. After that we will move to more advanced concepts where we will go beyond the strict setting of TypeScript. You will learn when to use types like any, unknown and never. We will explore the use of type predicates, guards and exhaustive checking. You will learn about the built-in mapped types as well as how to create your own new type map utilities. And we will start programming in the TypeScript type system using conditional types and type inferring.
Remix Conf Europe 2022Remix Conf Europe 2022
195 min
How to Solve Real-World Problems with Remix
Featured Workshop
- Errors? How to render and log your server and client errorsa - When to return errors vs throwb - Setup logging service like Sentry, LogRocket, and Bugsnag- Forms? How to validate and handle multi-page formsa - Use zod to validate form data in your actionb - Step through multi-page forms without losing data- Stuck? How to patch bugs or missing features in Remix so you can move ona - Use patch-package to quickly fix your Remix installb - Show tool for managing multiple patches and cherry-pick open PRs- Users? How to handle multi-tenant apps with Prismaa - Determine tenant by host or by userb - Multiple database or single database/multiple schemasc - Ensures tenant data always separate from others
GraphQL Galaxy 2020GraphQL Galaxy 2020
106 min
Relational Database Modeling for GraphQL
WorkshopFree
In this workshop we'll dig deeper into data modeling. We'll start with a discussion about various database types and how they map to GraphQL. Once that groundwork is laid out, the focus will shift to specific types of databases and how to build data models that work best for GraphQL within various scenarios.
Table of contentsPart 1 - Hour 1      a. Relational Database Data Modeling      b. Comparing Relational and NoSQL Databases      c. GraphQL with the Database in mindPart 2 - Hour 2      a. Designing Relational Data Models      b. Relationship, Building MultijoinsTables      c. GraphQL & Relational Data Modeling Query Complexities
Prerequisites      a. Data modeling tool. The trainer will be using dbdiagram      b. Postgres, albeit no need to install this locally, as I'll be using a Postgres Dicker image, from Docker Hub for all examples      c. Hasura
TypeScript Congress 2022TypeScript Congress 2022
116 min
Advanced TypeScript types for fun and reliability
Workshop
If you're looking to get the most out of TypeScript, this workshop is for you! In this interactive workshop, we will explore the use of advanced types to improve the safety and predictability of your TypeScript code. You will learn when to use types like unknown or never. We will explore the use of type predicates, guards and exhaustive checking to make your TypeScript code more reliable both at compile and run-time. You will learn about the built-in mapped types as well as how to create your own new type map utilities. And we will start programming in the TypeScript type system using conditional types and type inferring.
Are you familiar with the basics of TypeScript and want to dive deeper? Then please join me with your laptop in this advanced and interactive workshop to learn all these topics and more.
You can find the slides, with links, here: http://theproblemsolver.nl/docs/ts-advanced-workshop.pdf
And the repository we will be using is here: https://github.com/mauricedb/ts-advanced
TypeScript Congress 2023TypeScript Congress 2023
131 min
Practice TypeScript Techniques Building React Server Components App
Workshop
In this hands-on workshop, Maurice will personally guide you through a series of exercises designed to empower you with a deep understanding of React Server Components and the power of TypeScript. Discover how to optimize your applications, improve performance, and unlock new possibilities.
 
During the workshop, you will:
- Maximize code maintainability and scalability with advanced TypeScript practices
- Unleash the performance benefits of React Server Components, surpassing traditional approaches
- Turbocharge your TypeScript with the power of Mapped Types
- Make your TypeScript types more secure with Opaque Types
- Explore the power of Template Literal Types when using Mapped Types
 
Maurice will virtually be by your side, offering comprehensive guidance and answering your questions as you navigate each exercise. By the end of the workshop, you'll have mastered React Server Components, armed with a newfound arsenal of TypeScript knowledge to supercharge your React applications.
 
Don't miss this opportunity to elevate your React expertise to new heights. Join our workshop and unlock the potential of React Server Components with TypeScript. Your apps will thank you.