Persistencia de Remix con DynamoDB

Hola a todos, es un verdadero placer estar aquí, y estoy emocionado de ser parte de este movimiento remix contigo. Y hoy voy a hablarles sobre la persistencia con DynamoDB. Mi nombre es Brian LaRue, pueden encontrarme en varias redes sociales, así que todavía existo bajo ese nombre, y trabajo para Begin.com.

Entonces, antes de hablar de Dynamo, voy a hablar sobre la persistencia en general. La persistencia es un requisito muy importante para aplicaciones web dinámicas. Es una complejidad esencial para cualquier cosa que sea personalizada, así que cualquier cosa que tenga un paso de autenticación y estemos guardando algunos datos sobre una persona y necesitamos hacerlo de manera segura y rápida, vamos a necesitar una base de datos. Y no se puede hacer esto con un sistema de archivos plano. No quieres hacer esto con un sistema de archivos plano porque te encontrarás con problemas de concurrencia.

Entonces, tradicionalmente, las personas elegirían una base de datos relacional, y DynamoDB es una especie de base de datos de próxima generación que se basa en clave-valor. Y así, la mayoría de las organizaciones en estos días han optado por Amazon para la infraestructura, y Dynamo es la base de datos de clave-valor insignia para AWS. Entonces, si estás usando AWS, probablemente te gustaría aprender más sobre Dynamo.

Entonces, ¿qué es exactamente Dynamo? Es una base de datos de clave-valor de baja latencia y de columna ancha que es una forma muy elegante de decir que consultamos por clave, y almacenamos valores como JSON, y podemos tener diferentes formas de diferentes columnas en cada fila. Entonces, para cada fila en mi base de datos, puedo tener diferentes atributos de elementos y todo está bien. Dynamo es una base de datos completamente administrada, y esto significa que no hay parches. No hay software para actualizar, y eso es realmente bueno. Y también es realmente bueno que se escala a cero, lo que es una forma elegante de decir que solo pagas por lo que usas, y no pagas por nada más. Entonces, es una utilización del 100%. No estás manteniendo un gran grupo de servidores solo para satisfacer la demanda que puedes tener o no. Solo usas lo que pagas, y días felices. Sigues adelante desde ahí.

Entonces, la siguiente gran pregunta que a menudo me hacen es, bueno, ¿por qué elegiría DynamoDB entre las millones de opciones de database que tenemos disponibles? Y la clave para mí es que es la base de datos administrada insignia del pionero de la cloud, y ellos mismos la utilizan en Amazon para respaldar el negocio minorista de Amazon.com. Entonces, es simplemente una buena elección. Desde ese punto de vista, tiene excelentes opciones de desarrollo local. Tiene un gran nivel gratuito. Es rápido sin importar cuántos data almacenes, lo cual es como un sueño de ciencia ficción para las bases de datos. Solía ser que al agregar servidores, se agregaba latencia, y definitivamente se agregaban problemas, lo cual no experimentamos con una base de datos administrada. Es muy pequeña, por lo que no hay mucho API que aprender. Realmente solo hay alrededor de seis llamadas clave a la API para trabajar con Dynamo, lo cual es realmente genial. Tiene un buen SDK para casi todos los runtime que puedas imaginar. Y la característica sorprendente, mi característica favorita, es que funciona muy bien con AWS Lambda, con una latencia de un solo dígito de milisegundos para consultas, sin importar cuántos data estés almacenando. Por lo general, se menciona esto, y es realmente importante porque muchas bases de datos son bastante lentas hoy en día, especialmente las bases de datos relacionales tradicionales. Se pueden acelerar, pero nunca serán tan rápidas. Y simplemente no funcionan tan bien con Lambda por diversas razones.

Entonces, la siguiente gran pregunta sería, bueno, ¿por qué no DynamoDB? Obviamente, hay compromisos, esta no será una decisión sin compromisos. Lo primero y más importante es que es exclusivo de Amazon, por lo que la gente se preocupa por eso. En realidad, esto no es totalmente preciso desde el punto de vista técnico, aunque hay ejemplos de personas que ahora clonan Dynamo para otras bases de datos clave-valor, como sucedió con muchos otros servicios de Amazon, como S3, que se ha clonado bastante. Probablemente esto continuará sucediendo.

Una crítica muy válida, sin embargo, es que es un poco complicado de aprender. El modelado para una base de datos clave-valor de columnas anchas se centra mucho en las consultas, debes pensar en cómo obtener los datos antes de almacenarlos, a diferencia de los datos relacionales, donde desnormalizamos todo y podemos hacer consultas ad hoc. Otra cosa un poco extraña es que la sintaxis de consulta es un poco extraña. No es igual que en las bases de datos relacionales, aunque argumentaría que esto es solo una cuestión de familiaridad, si hubieras aprendido Dynamo primero y luego aprendido Postgres, probablemente encontrarías extraño a Postgres, así que no es realmente algo importante.

Por qué no DynamoDB también tiene muchos mitos, y quiero abordarlos directamente. Uno de los primeros mitos es que es costoso, otro es que necesitas conocer todos tus patrones de acceso por completo antes de hacer cualquier cosa, eso no es cierto. He escuchado que es difícil de modificar y migrar, eso tampoco es cierto. A veces la gente dice que no se puede usar SQL, eso no es cierto, y abordaremos los mayores obstáculos, el bloqueo y la escalabilidad al final, porque será divertido.

Entonces, ¿es caro? Bueno, la capa gratuita de DynamoDB te ofrece 25 gigabytes almacenados en disco por mes de forma gratuita, y son 25 centavos por cada gigabyte adicional. Eso es mucha capacidad de datos de inicio, 25 gigabytes, es un montón. Además del costo de almacenamiento en disco, también debes pagar por las lecturas y escrituras, y básicamente se calcula que alrededor de 200 millones de solicitudes por mes estarán en la capa gratuita. Almacenar 25 gigabytes, 200 millones de solicitudes por mes. Creo que esto no es caro en absoluto, es muy barato. Y así, incluso si, a medida que creces, encuentras que estos números se vuelven inmanejables, aún es recomendable usar Dynamo para al menos prototipar tu aplicación. Te llevará muy lejos, por muy poco. Como dato adicional, el chiste que solía decir es que sí, Dynamo es caro, pero también lo son los DBAs. Y esa broma solo tiene sentido si has tenido que fragmentar una base de datos. No voy a asumir que todos saben de qué estoy hablando ahí.

Otro gran mito es que necesitas conocer los patrones de acceso de antemano. El modelado de DynamoDB es diferente al modelado de bases de datos relacionales, y es simplemente diferente, no es mejor. Es simplemente diferente. Y así, en ambas bases de datos, ya sea relacional o clave-valor, necesitas tener un esquema de algún tipo. Necesitas decir que se esperan estos valores y así es como voy a hacer consultas. Así que realmente no importa qué base de datos elijas. En algún momento, tendrás que declarar un esquema.

Tendrás que decir que tengo una tabla de cuentas o tengo una tabla de canciones o lo que sea. Y esto es cierto, ya sea que estés trabajando con una base de datos relacional o una base de datos de columnas anchas. Así que no creo que sea un gran argumento. Estarás migrando y aprendiendo sobre tu aplicación, y a medida que crezca y comprendas mejor los patrones de acceso, podrás almacenar los datos de manera más eficiente. Y eso es cierto sin importar qué base de datos elijas.

A veces la gente dice que no se puede usar SQL con DynamoDB. Eso solía ser cierto. Ya no es el caso. Ahora tenemos un lenguaje de consulta llamado PartiQL. Suena divertido. Se parece a SQL. Así que supongo que si te divierte, lo es. Puedes hacer clic y echarle un vistazo. No se limita solo a Dynamo. En realidad, se supone que es una idea más amplia. Aunque creo que por ahora, Dynamo es probablemente el único que lo usa.

El otro gran tema que se plantea es si estás o no bloqueado. Y en cierto punto, siempre estarás bloqueado. Yo argumentaría que el mayor bloqueo de todos es elegir una complejidad inicial. Y fragmentar y administrar una instancia en ejecución para una base de datos es definitivamente mucha complejidad. A veces la gente piensa que si usas una base de datos como Postgres, eso significa que tus datos son inherentemente portátiles. Y creo que eso es mentira. Tendrás que pasar por una gran cantidad de dolor para mover esos datos entre diferentes proveedores de bases de datos, independientemente de la base de datos que elijas. Así que, para mí, no es un argumento muy sólido. Aquí en el sitio web de Martin Fowler hay un argumento escrito mucho más largo y racional que puedes revisar. Simplemente no creo que el bloqueo sea una buena razón para elegir algo. Si ya has seleccionado a Amazon como proveedor, probablemente estarás allí por un tiempo.

Esto es divertido y surge todo el tiempo. La gente pregunta, ¿escala? Sí, definitivamente escala.

Entonces, Jeff Barr dijo el año pasado que Amazon DynamoDB impulsa múltiples propiedades y sistemas de alto tráfico de Amazon, incluyendo Alexa y los sitios de Amazon.com y todos los centros de cumplimiento de Amazon. Durante las 66 horas del día Prime, estas fuentes realizaron billones de llamadas a la API manteniendo una alta disponibilidad con un rendimiento de milisegundos de un solo dígito alcanzando un máximo de 82 millones de solicitudes por segundo. Eso escala.

Y no solo es Amazon. La prueba social es cómo te gusta tomar decisiones. Aquí hay un montón de logotipos de personas que usan DynamoDB a gran escala para una variedad de aplicaciones. Creo que podemos dar por sentado eso.

Entonces, en resumen muy rápido, DynamoDB escala hacia arriba y hacia abajo de manera dinámica, tiene un generoso nivel gratuito, admite una sintaxis similar a SQL. Es bastante sencillo migrar, funciona muy bien con AWS Lambda. Sí, escala y sí, es un poco extraño de aprender y vamos a adentrarnos en eso.

Antes de profundizar demasiado en esto, si solo quieres desconectar y no prestar atención al resto de mi charla, te recomendaría que compres este libro y sigas a Alex DeBrie en Twitter si todavía estás aquí, es una compra imprescindible para todo tu equipo si estás usando Dynamo, es la mejor documentación escrita para DynamoDB con diferencia. Cuando comenzamos a adoptar Dynamo, desearía que este libro hubiera estado disponible porque nos habría ahorrado mucho tiempo. Es lo más barato por lo que alguna vez estarás agradecido de haber comprado. Te dará superpoderes y no puedo recomendarlo lo suficiente.

Entonces, Dynamo, profundicemos un poco más. Algunos términos que debes conocer, en primer lugar, Dynamo tiene tablas y las tablas son colecciones de elementos. Puedes pensar en ellas como páginas en una hoja de cálculo y los elementos son como filas en una hoja de cálculo o tal vez en una base de datos, si eso es lo que te resulta familiar. Y ahora los elementos tienen atributos. Entonces, si una fila, si el nombre de la tabla es cuentas y una fila es un usuario en las cuentas, podría tener atributos como nombre, correo electrónico y dirección. La clave de partición es cómo consultamos un elemento específico o una colección de elementos. La clave de partición es como una clave primaria en términos relacionales. Por lo general, es un valor bastante único, pero no tiene que serlo. Y es cómo obtenemos cosas. Una clave de ordenación es una forma secundaria de consulta. Y una clave de ordenación podría ser una forma de reducir la colección de elementos o una forma de obtener una representación más exacta de datos jerárquicos. Entonces, si quieres obtener un nodo inferior en el árbol, por así decirlo. Y luego el último concepto son los índices. Y los índices son, en realidad, básicamente como tablas. Son otra tabla con una clave primaria y una clave de ordenación diferente, para que puedas consultar por diferentes cosas. Y explicaré a qué me refiero con eso.

Entonces, modelado básico. Una clave de partición es un valor único para acceder a un elemento. Esto que ves aquí es lo que llamamos un archivo Arc. Y es un documento que usamos para aprovisionar tablas de DynamoDB en el proyecto de código abierto Architect.

Entonces decimos, Hola, tabla, quiero una tabla llamada cuentas y quiero una clave de partición de ID de cuenta. Y voy a tener un índice adicional para la tabla de cuentas. Oh, aquí hay un error tipográfico. Debería ser cuentas con una S, eso es terrible. Pero esto debería ser cuentas. Y así coincide aquí, y sería una forma diferente de consultar. Entonces, tal vez quiera obtener a mi usuario por ID de cuenta, pero tal vez solo tenga el correo electrónico, como cuando se están registrando o iniciando sesión o ingresando al sistema. Entonces necesito un índice para consultar eso por correo electrónico. Me gusta cómo mi error tipográfico se trasladó aquí, así que lamento eso.

Básicamente en 101.2, hay un concepto de clave primaria y luego hay un concepto de clave secundaria o clave de ordenación, a veces llamada clave secundaria. La clave de ordenación se utiliza para consultar relaciones de uno a muchos. Entonces, si estuviera modelando un blog en mi sistema y tengo cuentas y las cuentas tienen muchos blogs. Y así una ID de cuenta tendría más de una publicación de blog. Y podríamos tener una clave secundaria de slug para obtener publicaciones individuales. Ahora esto es genial porque también podríamos tener que consultar blogs por cuando se publicó. Y así esta es una clave secundaria en el índice donde vamos a buscar por publicado en su lugar. Y así es bastante bueno. Ahora podemos obtener todos los blogs. Podemos obtener un blog por su título y podemos obtener si ha sido publicado o no. Genial. Claves primarias y claves de ordenación, tablas e índices. Eso es lo más básico a nivel alto. Hay mucho más en ello. Una de las cosas que debes saber sobre DynamoDB y que escuchas todo el tiempo. Así que lo abordaré ahora. ¿Qué hay del diseño de tabla única? Amazon recomienda que diseñes tu aplicación con la menor cantidad de tablas posible.

Idealmente, esto significa tener solo una tabla y puedes ser muy sofisticado con las claves de partición y las claves de ordenación para almacenar relaciones realmente complejas dentro de tus tablas, dentro de una tabla.

Ahora, no me gusta hacer esto con datos efímeros y datos duraderos. Y lo que quiero decir con eso es que si tengo claves de API o tokens que expiran con un tiempo de vida, no quiero almacenar eso en el mismo lugar donde tengo cuentas de usuario que son datos duraderos que quiero conservar para siempre y tal vez hacer una copia de seguridad regularmente. No quiero hacer una copia de seguridad de tokens de corta duración. Quiero hacer una copia de seguridad de las cuentas de usuario. Por lo tanto, no queremos poner esas tablas juntas. Por lo general, tendrás más de una tabla dependiendo del ciclo de vida de los datos involucrados.

Ahora, esta es una opinión personal y todos tienen una. Así que tómalo por lo que vale. Pero creo que el diseño de tabla única es un paso de optimización una vez que conoces los patrones de acceso a tus datos. Hasta que los conozcas, probablemente deberías inclinarte hacia probar cosas y descubrir el mejor diseño para tu aplicación en ese momento. Y eso podría significar que habrá oportunidades para mejorarlo más adelante. Y eso no es algo malo. Eso es lo que sucederá independientemente de si lo diseñas para una tabla única o no.

De acuerdo. Eso es mucha emoción. Vamos a modelar algunas cosas. Primero, si vas a crear una aplicación remix para trabajar con esto. Querrás elegir el Grunge Stack. Eso utiliza Architect bajo el capó. Lo que te brinda todos estos superpoderes de AWS. Aunque no tienes que hacerlo. Y te mostraré cómo trabajar con DynamoDB directamente en tu máquina local sin una cuenta de Amazon porque eso hace las cosas mucho más fáciles. Si echas un vistazo al Grunge Stack, verás en el código generado que te brinda esta increíble aplicación de toma de notas que se acerca mucho a cómo te recomendaría que quieras trabajar de todos modos.

Por lo general, tendrías algún tipo de carpeta llamada Modelos y querrías poner toda tu lógica de acceso a datos en esos modelos. No quieres que tu capa de aplicación interactúe con DynamoDB. Quieres que interactúe con las entidades de tu sistema. Y así, en este caso, las entidades son Usuario y Nota. Y así, como quieras llamarlos, lo que sea que estés persistiendo, quieres recopilarlos en un objeto para que tu capa de aplicación se lea de manera muy clara y se enfoque más en la lógica empresarial y no en la lógica de acceso a datos. Y eso es realmente, realmente importante para separar esas responsabilidades. Y una vez que todo esto esté compilado, todo se unirá en los lugares correctos. Pero si profundizas en estos modelos, verás que encapsulan toda la fealdad de trabajar directamente con la base de datos, que no es tan fea.

Pero db.note.get con estas cosas de PK y SK es mucho menos claro que la interfaz de solo getNote, ¿verdad? Así que esa es una forma más agradable de trabajar. Ahora, iba a pasar por esto y simplemente explicar cómo funciona todo esto, pero siento que comienza con casi demasiado contexto. Y no quiero confundirte con todo este negocio adicional que está sucediendo. Solo quiero mostrarte lo más básico, básico.

Entonces, con eso, en realidad voy a ir directamente a mi terminal, y debería arreglar mi ejemplo. Muy gracioso. Voy a crear una nueva pestaña y voy a hacer un directorio y lo voy a llamar Remix DynamoDB. Y voy a entrar allí. Voy a escribir un par de paréntesis en un archivo llamado package.json, y voy a NPM instalar tape, tap spec, architect sandbox, architect functions. Y los guardaré para desarrollo. Tomará un momento. Todos estamos acostumbrados al impuesto de NPM, pero tal vez valga la pena hablar sobre qué está sucediendo aquí.

Así que acabo de crear un archivo package.json y le agregué algunas dependencias. Esas dependencias son para pruebas, y eso es todo. Y ahí vamos. Ahora, voy a crear un archivo llamado app.arc y modificarlo. Solo lo llamaré myapp. Y comenzaremos definiendo una tabla DynamoDB llamada cats. Y le daremos una clave primaria, o una clave de partición, lo siento. Siempre quiero llamarlo clave primaria. Le daremos una clave de partición de ID de gato. Por lo general, me gusta nombrar las tablas en plural y luego cada fila sería como una cosa singular. Y así, con la forma en que funciona Architect, podremos ejecutar esto localmente, lo cual es realmente, realmente agradable. Pero antes de hacer eso, vayamos a package.json. Genial, tengo todas mis dependencias. Solo agregaremos un script. Y y tap spec. Ok, esto ejecutará tape en un archivo llamado test.mjs. Y enviará los resultados a tap spec. Ahora test.mjs aún no existe, así que creémoslo.

Y simplemente agregaremos una prueba tonta. Ups. Funciona. Ahora puedes agregar todo tipo de tooling a esto, obviamente, y puedes volverte realmente, ya sabes, loco si quieres, pero solo estoy tratando de hacer que esto funcione. Y solo quiero, como, hacer, un pequeño paso a la vez y ver cómo funciona, ya sabes. Solo dando pequeños pasos. Así que tenemos una prueba aprobada que se siente bastante bien. Pero no hay mucho más que hacer aquí.

Recuerda cuando entré en este archivo app.arc y definí esta tabla llamada cats. Sería genial si pudiéramos, ya sabes, echarle un vistazo. ¿Por qué no hacemos eso? Entonces, antes de hacer eso, vamos a necesitar Arc Sandbox. Entonces architect viene con un tiempo de ejecución DynamoDB runtime basado en una cosa llamada Dynolate, y nos permite ejecutarlo localmente, lo cual es agradable. Entonces no tienes que implementar nada en la cloud para probar tu DynamoDB. Y voy a decir, ahora se ejecuta como un servidor de desarrollo. Entonces, ya sabes, tenemos que iniciarlo y detenerlo y haremos eso antes y después de que se ejecuten nuestras pruebas. Y no estoy seguro de por qué tengo esto de la pantalla. Ahí vamos. Y terminamos. Y veremos alguna salida extraña cuando hagamos esto. Así que echemos un vistazo a eso. Oh, falta una coma. Debería instalar ESLint, pero no quiero que esto se convierta en una historia de configurar mis cosas. Entonces verás aquí, tenemos alguna salida. Y cuando se inició el sandbox, dijo que se crearon tablas en la database local, lo cual es agradable. En realidad, no quiero ver eso cada vez. Le diré que sea silencioso, verdadero. Y en lugar de simplemente decir funciona, ¿por qué no echamos un vistazo al DynamoClient de Architect? Los arquitectos son una colección de pequeñas funciones con las que trabajas con AWS. Y una de esas funciones es una capa de acceso a data. Entonces diremos que data es igual a await Arc.tables.

Entonces esto se reflejará en las tablas que hemos definido en nuestro archivo arc. Y si desplegáramos esto, ese archivo arc generaría la formación en la nube necesaria para crear la base de datos enAWS. Así que echemos un vistazo a eso.

Creemos una nueva capa de acceso adata. Entonces vamos a decir, vamos a crear una nueva formación en la nube, y luego vamos a decir, vamos a usar esta capa de acceso adata. Así que simplemente crearemos una nueva formación en la nube. Y vamos a decir, vamos a crear una nueva capa de acceso adata y vamos a decir que esto es el AX. Y luego vamos a decir, vamos a invocar esta capa de acceso adata y vamos a hacer una nueva consulta. Entonces la razón por la que esto es útil, voy a saltar rápidamente al sitio web de Architect y te lo mostraré. Aquí a la izquierda, un archivo arc, oops. Y esto a la derecha es la formación en la nube generada para ese archivo arc. Y verás aquí abajo en algún lugar, va a definir una tabla DynamoDB. Y eso es genial. Tenemos como alcance ydata e IDs y tiene un TTL. Esta tabla cuando se genera solo tendrá un GUID sin sentido como nombre. Si lo llamo cats, por ejemplo, no hay gatos aquí. Se mezclará con lo que se genera. Entonces en tiempo de ejecución, en realidad lo buscamos por clave y te permitimos tener este cliente Dynamo que es un poco más fácil de usar. Así que solo estás trabajando con arc. o data.cats, en lugar de trabajar con algún GUID.

Bien, tenemos nuestra tabla. Escribamos algunos datos en ella. Entonces, escribamos un gato. El resultado es igual a await data.cats.put. Y creo que dije en el esquema que tendría un ID de gato. Y solo, ya sabes, esto no está destinado a ser código de producción. Así que hagámoslo para el ID de gato, dale un nombre. El nombre de mi gato es Sutro. Sí, una fecha de nacimiento. De acuerdo.

En lugar de decir T.compass, diremos T.OK result.cat ID tiene un registro de gato aquí para que podamos echarle un vistazo. Genial. Entonces, escribimos un gato en la base de datos y luego salimos de inmediato y desaparece porque no persistes nada en nuestro sistema de archivos local. Por defecto, esto se ejecutará en memoria y es genial porque a medida que agregas más y más pruebas y construyes una capa de acceso a datos más grande y más grande, las pruebas se ejecutarán rápidamente. En nuestro caso, para begin.com, creo que tenemos algo así como miles de pruebas y se ejecutan en milisegundos, que es cómo quieres que funcione esto.

Entonces, ¿por qué no leemos, oops, leemos todos los gatos y podemos agregar un par de gatos. En su lugar, está bien. Otro gato de esmoquin, ¿qué tal eso? Y voy a querer obtener este ID más tarde, así que solo voy a decir, mi ID de gato aquí arriba fuera del alcance de mi prueba y voy a copiar este fragmento de código aquí arriba. Entonces este ID de gato estará fuera del alcance y luego más adelante podré buscarlo. Pero por ahora, solo obtengamos todos los gatos.

Entonces data.cats.scan, como gatos. Bien, el escaneo generalmente se considera una mala práctica. Por lo general. Lo que hará el escaneo es recorrer y leer todo. Y si tu tabla es realmente grande, eso llevará mucho tiempo y tendrá que paginar a través de múltiples páginas de data. Por lo general, quieres obtener cosas consultando o dándole directamente una clave. Así que esa es la forma descuidada y rápida de trabajar. Pero sabes qué? Esto también escala durante mucho tiempo. Así que no te sientas mal por usar las herramientas que tienes disponibles, y luego iterar para mejorarla. No tiene que ser perfecto desde el principio.

Así que vamos a leer un gato, data.cats.oops! Obtienes, y vamos a consultar por ID de gato. Entonces, si vemos aquí por ID de gato, recuperamos este, y esto es extremadamente rápido, como si estuviéramos agregando consultas sin ningún problema. Leer y escribir, todo eso se realiza en unos pocos milisegundos. No está mal, es exactamente lo que quieres. Entonces, en cuanto a CRUD, tenemos crear, tenemos leer, tenemos una lista con esto, oops, con este escaneo. Hagamos una consulta. Solo para completar. Y esto es más o menos, leer gatos por ID de gato. Entonces, esta es más o menos la forma recomendada de trabajar con filas. Clave, condición, expresión. Ahora puedes hacer esto de varias formas diferentes, esta es solo una forma y hay mucho que aprender sobre cómo hacer un modelado adecuado y construir una aplicación más grande. Estoy tratando de darte una idea aquí, no estoy tratando de decir que esta es la única forma o la mejor forma, esto es, te estoy presentando a Dynamo por primera vez. Entonces tenemos una clave, una condición de expresión, estamos diciendo, dame todos los gatos donde el ID de gato sea igual a este valor. Y luego tenemos que tener un valor de atributo de expresión. Y uno de ellos será el ID de gato y pasaremos el ID de gato que generamos arriba.

Eso nos dará un resultado y vamos a inspeccionar el valor de ese resultado. Así que puedes ver que en realidad es bastante similar a ejecutar un escaneo. Pero fue prefiltrado en el ID que estábamos buscando. Ahora, a medida que design y aprendas cómo modelar aplicaciones de DynamoDB, utilizarás IDs como una forma de consultar grupos de elementos en jerarquías. Y así es como obtienes más de un elemento por ID. Y puedes agregar todo tipo de condiciones a esto, no tiene que ser demasiado complicado.

Voy a hacer otro de estos, digamos como gato, tal vez dos, y lo usaremos para este. Y así leeremos todos los gatos por ID de gato, tiene un montón de gatos, genial, genial, genial. Vamos a eliminar una fila, así que ahora tenemos todas las operaciones CRUD, tenemos crear, leer, actualizar, eliminar. Así que eliminemos un gato, eso suena triste. Eliminar una fila de gato, eso es un poco más benigno. Soy amigo de los gatos y quiero verlos lastimados.

Bien, estoy usando tape aquí, muy deliberadamente. A veces, las personas en la comunidad de React piensan que deberías usar Jest, no uses Jest para probar proyectos de node, no es muy bueno para eso, es pesado, es lento y parcha los globales. Quieres algo lo más cerca posible del metal para tus pruebas. No quieres que tus pruebas sean un misterio de asesinato, quieres que sean un lugar donde puedas confiar en lo que está sucediendo, en lo que pensaste que estaba sucediendo. Muy bien, así que vamos a tomar un poco de código de allí, vamos a obtener los gatos, y vamos a decir eliminar, y es solo por ID de gato, así que podemos robar ese código. Y luego veremos si obtenemos algún tipo de resultado. Y tristemente, sí lo haremos. La forma correcta de hacer esto sería en realidad, hagamos un escaneo después, y veremos cuántos elementos tenemos en el escaneo. No, es la forma correcta, pero la forma correcta de hacer esto para aprender, debería decir. Llamemos a este resultado. Oh, y eliminemos el segundo. De acuerdo. Creo que sé dónde me equivoqué. Fue aquí arriba cuando se está creando esto. Sí. No, todavía tengo un error. Eliminar fila de gato, gatos calientes. Oh, leer gato por ID de gato.

Tengo uno. Y luego eliminar fila tiene gatos. Veamos qué tengo aquí. Oh, ¿eliminamos ambos gatos, verdad? Eliminé este gato. ¿Y eliminé ambos gatos? ¿Dónde se fue el otro gato? Saliendo del guion. Leer gatos por ID de gato. Tenemos un tuxedo, tenemos un tuxedo, tuxedo. Estamos en el gato. Eso es interesante. Casi parece que sobrescribimos nuestro gato, aquí arriba. No se hizo cats.put, no se hizo cats.put. Oh, creo que sí. Porque esto podría haber sucedido tan cerca que compartieron un ID. Sí. Eso es lo que sucedió. Compartieron un ID. Ahora esto es obviamente para fines de demostración. Podrías usar UUID aquí. Probablemente quieras usar algún otro data como correo electrónico y cosas así. Pero veamos. Sí, ahora solo tenemos uno de vuelta. Y está haciendo lo que esperamos. Genial. Entonces eso es un recorrido muy rápido de cómo construir un cliente DynamoDB en un solo archivo con tres o cuatro dependencias. A medida que madures este proyecto, probablemente quieras tener algo llamado gatos, ¿verdad? Y no estarías interactuando con el código Dynamo aquí. Estarías interactuando con el código de los gatos. Y así, el ejercicio para el lector sería mover esto a algún tipo de modelo aquí y luego tu aplicación consumiría ese modelo, se probaría de forma independiente y guardaría la interfaz de usuario de tu aplicación y no tendrías que preocuparte por cómo se componen estas cosas. Pueden componerse perfectamente juntas a medida que construyes tu aplicación. Ok, eso fue como el nivel más alto, la carrera más rápida para aprender Dynamo que pude darte. Obviamente, solo rasca la superficie.

Un gran resumen aquí. Entonces, DynamoDB se escala hacia arriba y hacia abajo dinámicamente. Tiene una gran capa gratuita, admite una sintaxis similar a SQL. Es muy fácil de migrar, funciona muy bien con Lambda. Sí, se escala y sí, es un poco extraño de aprender. Se me acabó el tiempo, así que por favor sígueme en las diferentes redes sociales en Bryan LaRue. Si quieres intentarlo, prueba el stack grunch, remix y si tienes algún problema, simplemente únete a nosotros en Architect Discord. Nos puedes encontrar en arc.codes. Siempre estamos felices de ayudar. Muchas gracias.

Permítanme que Bryan se una a mí para las preguntas y respuestas y primero repasemos la encuesta que tuvimos que es, ¿qué base de datos usas? Y veamos los resultados. La mayoría de las personas eligieron Postgres, DynamoDB superó a MongoDB y luego nadie eligió otra opción. Respuesta muy interesante y sé que estábamos hablando antes y dijiste algo como, oh, todos solo quieren jugar a lo seguro y cosas así. Dejando de lado las bromas, quiero hablar sobre, ¿cómo complementa DynamoDB a Remix en tu opinión? ¿Por qué es una gran combinación? Sí, y no quería que mi charla fuera como, aquí está cómo construir un foro con Remix. Sentí que todos entendían esa parte pero para mí, la parte más emocionante de Remix es que tenemos cargadores y acciones ubicados junto con nuestros foros y esos foros son foros reales de base de datos. Entonces, van a comunicarse directamente con un backend. Y luego la parte difícil se convierte en, ¿qué va a hacer ese foro? ¿Y cómo me comunico con una base de datos? En mi opinión, Dynamo es probablemente el mejor en su clase de bases de datos administradas en la actualidad. Me adentro bastante en eso en la charla pero hablando empíricamente tiene probablemente el mejor rendimiento y las mejores características de escalabilidad, tal vez no las mejores características de precios y herramientas como Postgres son geniales y están bien y te llevarán muy lejos. Y creo que es totalmente una elección segura todos están usando Postgres. Pero el problema con Postgres es que no se comunica tan bien con cosas de cómputo efímero. Entonces, cosas que se comunican a través de Cloud Functions y Remix está diseñado para trabajar en el borde con Cloud Functions. Y por lo tanto, funcionará mejor con una base de datos clave-valor como Dynamo o Mongo. De hecho, me sorprende que Dynamo haya superado a Mongo, tal vez sea porque era una charla sobre Dynamo pero Dynamo todavía es un poco nuevo, también está en este rincón de AWS y no todos se sienten cómodos yendo a AWS. Quieren un mayor nivel de abstracción. Y por lo tanto, no me sorprende ver estos tipos de resultados en la encuesta y sí, y creo que los usuarios de Remix estarían, lo que elijas poner en tu cargador o acción, ya sea Postgres o DynamoDB, esa es la belleza de Remix, obtienes esta capa agradable que hace que el acceso a datos sea realmente elegante y limpio. Sí, no, eso es genial. Y volviendo al tema de DynamoDB, quiero saber cuál sería la razón para elegir DynamoDB sobre bases de datos basadas en SQL? Bueno, el principal para mí son las diferencias de latencia que se ven en una base de datos clave-valor, que está sobre HTTP como Dynamo en comparación con Postgres. Las bases de datos relacionales tradicionales son efectivamente basadas en sockets, lo que significa que nuestra computadora o servidor de aplicaciones creará una conexión de socket con el servidor de base de datos y luego tendrán este canal dúplex de comunicación. El problema con las funciones en la nube es que desaparecen. No permanecen allí en vivo con un socket abierto. Se inician y luego hacen algo de trabajo y luego desaparecen. Y por lo tanto, ese modelo de conexión no es muy bueno porque significa que mi función en la nube se inicia, tiene que conectarse a Postgres o algo similar a Postgres, hacer su trabajo y luego desconectarse. Y esto crea una sobrecarga de conexiones, por lo que tienes que tener un grupo de conexiones en el medio y todo esto se suma en latencia. En DynamoDB obtenemos una latencia de un solo dígito en milisegundos sin importar cuántos datos estemos transfiriendo, por lo que esto es un rendimiento increíble. Y como mencioné en la charla, podemos obtener hasta decenas de millones de solicitudes por segundo de rendimiento, algo que Postgres simplemente no puede hacer. Y sí, si alguien está construyendo un producto donde la escalabilidad se convierte en un tema muy importante, ¿por qué recomendarías DynamoDB en lugar de su contraparte SQL? Bueno, está el problema de latencia de conexión, pero también está lo que sucede una vez que te vuelves más grande que un servidor. Entonces, Postgres está diseñado para trabajar en lo que se llama un modelo de inquilino único, donde tienes un servidor de base de datos y colocas datos en ese servidor, pero el servidor solo puede crecer hasta cierto punto. Y si tu sistema se expande más allá de los límites de ese servidor, necesitarás más de un servidor. Ahora, has entrado en un mundo llamado fragmentación. Y hay dos formas diferentes, puedes tener un líder y seguidores, o puedes tener líder, líder. De cualquier manera, una vez que agregas servidores a la historia, la escalabilidad se vuelve realmente difícil y tu lógica de aplicación termina asumiendo gran parte de ese trabajo también. Y por lo tanto, tienes este acoplamiento entre cómo se implementa tu capa de acceso a datos a nivel de infraestructura y a nivel de aplicación. A veces la gente llama a esto arquitectura física versus arquitectura lógica. Con DynamoDB, no tienes ninguno de esos problemas. Simplemente se escala de manera transparente para ti sin importar cuántos datos tengas, y mantiene una latencia constante sin importar cuántos datos tengas. Esas son cosas realmente importantes cuando comienzas a escalar una empresa. Sí, no, todos esos son excelentes puntos. Y sé que no tuvimos tanto tiempo como quisieras para hacer preguntas, pero muchas gracias, Brian, por venir, dar una gran charla, y responder las preguntas que tuvimos. Así que con eso dicho, gracias por unirte a nosotros, y volvamos a Brittany.