Persistencia de Remix con DynamoDB

Rate this content
Bookmark

Remix es el mejor marco de trabajo de React para trabajar con la segunda característica más importante de la web: los formularios. (Los anclajes son más importantes). Pero construir formularios es la parte divertida: la parte complicada es lo que sucede cuando un consumidor web envía un formulario. No la lógica de validación del lado del cliente, sino la lógica básica del backend para crear, leer, actualizar, destruir y listar registros en una base de datos duradera (CRUDL). Las bases de datos pueden ser intimidantes. ¿Cuál elegir? ¿Cuáles son los compromisos? ¿Cómo modelar los datos para consultas rápidas? En esta charla, aprenderemos sobre el increíblemente poderoso AWS DynamoDB. Dynamo promete una latencia de un solo dígito de milisegundos sin importar cuántos datos tenga almacenados, la escalabilidad es completamente transparente y viene con un generoso nivel gratuito. Dynamo es un nivel diferente de base de datos, pero no tiene por qué ser intimidante.

41 min
18 Nov, 2022

Video Summary and Transcription

DynamoDB es una base de datos de clave-valor de próxima generación que tiene baja latencia, es escalable y fácil de usar. Ofrece ventajas como opciones de desarrollo local, un nivel gratuito generoso y un rendimiento rápido. Se desmienten los conceptos erróneos comunes sobre DynamoDB de ser costoso o difícil de aprender. La charla cubre temas como modelado básico, separación de preocupaciones, trabajar con DynamoDB en Remix y construir un cliente de DynamoDB. En general, DynamoDB es una base de datos potente que se integra bien con Remix y proporciona patrones eficientes de acceso a datos.

Available in English

1. Introducción a DynamoDB

Short description:

Hoy voy a hablar sobre la persistencia con DynamoDB, una base de datos de clave-valor de próxima generación. DynamoDB es una base de datos de clave-valor de baja latencia y de columna ancha que permite consultar por clave y almacenar valores como JSON. Es una base de datos completamente administrada sin necesidad de parches o actualizaciones de software. Además, DynamoDB se escala a cero, lo que significa que solo pagas por lo que usas.

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

2. Ventajas de DynamoDB

Short description:

DynamoDB es la base de datos administrada insignia del pionero de la nube, utilizada por Amazon ellos mismos. Ofrece excelentes opciones de desarrollo local, un gran nivel gratuito y un rendimiento rápido independientemente del tamaño de los datos. Con solo unas pocas llamadas clave a la API y una excelente compatibilidad con AWS Lambda, DynamoDB se destaca de las bases de datos relacionales tradicionales en cuanto a velocidad e integración.

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.

3. ¿Por qué no DynamoDB?

Short description:

Entonces, el primer gran compromiso con DynamoDB es que es exclusivo de Amazon. Sin embargo, hay ejemplos de personas que clonan Dynamo para otras bases de datos clave-valor. Otra crítica válida es que es un poco complicado de aprender, especialmente la sintaxis de consulta. Pero los mitos sobre DynamoDB siendo costoso, requiriendo conocimiento previo de los patrones de acceso y siendo difícil de modificar y migrar no son ciertos. La capa gratuita de DynamoDB ofrece una generosa cantidad de almacenamiento y solicitudes de forma gratuita, lo que lo convierte en una opción rentable. No es necesario conocer los patrones de acceso de antemano, y tanto las bases de datos relacionales como las bases de datos clave-valor requieren una declaración de esquema.

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.

4. Desmintiendo Conceptos Erróneos Comunes

Short description:

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. A veces la gente dice que no se puede usar SQL con DynamoDB. Eso solía ser cierto, pero ya no es el caso. Ahora tenemos un lenguaje de consulta llamado PartiQL. Entonces, el otro gran tema que se plantea es si estás o no bloqueado. Y en cierto punto, siempre estarás bloqueado. El mayor bloqueo de todos es elegir una complejidad inicial. 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. Esto es divertido y surge todo el tiempo. La gente pregunta, ¿escala? Sí, definitivamente escala.

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.

5. Descripción general y terminología de DynamoDB

Short description:

Amazon DynamoDB impulsa propiedades y sistemas de alto tráfico de Amazon, incluyendo Alexa y los sitios de Amazon.com. Escala y es utilizado por muchas organizaciones para diversas aplicaciones. DynamoDB es fácil de escalar, tiene un generoso nivel gratuito, admite una sintaxis similar a SQL y funciona bien con AWS Lambda. Para obtener más información, recomiendo leer un libro de Alex DeBrie y seguirlo en Twitter.

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.

6. Modelado básico y Diseño de Tabla Única

Short description:

Una clave de partición es un valor único para acceder a un elemento. Es importante tener los nombres de tabla y los índices correctos al aprovisionar tablas de DynamoDB. Las claves primarias y las claves de ordenación son esenciales para consultar relaciones de uno a muchos. DynamoDB admite consultas por varios atributos, como slug y published. Amazon recomienda utilizar un diseño de tabla única siempre que sea posible.

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.

7. Modelado de Datos y Separación de Responsabilidades

Short description:

Idealmente, deberías tener una tabla para almacenar relaciones complejas. Sin embargo, para datos efímeros y duraderos, es mejor separarlos en tablas diferentes. El diseño de tabla única es un paso de optimización una vez que conoces los patrones de acceso a tus datos. Al modelar tu aplicación, considera usar el Grunge Stack o trabajar con DynamoDB localmente. Coloca tu lógica de acceso a datos en modelos separados para mantener la capa de aplicación enfocada en la lógica empresarial.

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.

8. Trabajando con DynamoDB en Remix

Short description:

Pero db.note.get con estas cosas de PK y SK es mucho menos claro que la interfaz de solo getNote. Así que esa es una forma más agradable de trabajar. Voy a crear una nueva pestaña y hacer un directorio llamado Remix DynamoDB. Voy a escribir un par de paréntesis en un archivo llamado package.json e instalar algunas dependencias para las pruebas. Ahora, voy a crear un archivo llamado app.arc y modificarlo. Comenzaremos definiendo una tabla DynamoDB llamada cats con una clave de partición de ID de gato. Podremos ejecutar esto localmente con Architect. Creemos test.mjs.

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.

9. Explorando las pruebas locales con Arc Sandbox

Short description:

Agregamos una prueba y la ejecutamos localmente usando Arc Sandbox. El tiempo de ejecución de DynamoDB nos permite probar sin implementar en la nube. Obtenemos alguna salida y podemos explorar el DynamoClient de Architect para el acceso a datos.

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.

10. Creando Capa de Acceso a Datos y Escribiendo Datos

Short description:

Entonces esto se reflejará en las tablas que hemos definido en nuestro archivo arc. Si desplegáramos esto, ese archivo arc generaría la formación en la nube necesaria para crear la base de datos en AWS. Creemos una nueva capa de acceso a datos y una nueva formación en la nube. Invocaremos esta capa de acceso a datos y haremos una nueva consulta. En tiempo de ejecución, lo buscamos por clave y te permitimos tener este cliente Dynamo más fácil de usar. Escribamos algunos datos en la tabla con un ID de gato, nombre y fecha de nacimiento.

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.

11. Escribiendo Datos en la Base de Datos

Short description:

Escribimos un gato en la base de datos y luego salimos de inmediato. Por defecto, esto se ejecutará en memoria, lo cual es genial para pruebas rápidas. En nuestro caso, para begin.com, tenemos miles de pruebas que se ejecutan en milisegundos.

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.

12. Lectura y Consulta de Datos en DynamoDB

Short description:

Vamos a leer todos los gatos y agregar un par más. Podemos consultar los gatos por ID de gato, que es una forma recomendada de trabajar con filas. Esto nos permite recuperar gatos específicos de manera rápida y eficiente. La lectura y escritura de datos en DynamoDB es rápida, solo toma unos pocos milisegundos. Entonces, en cuanto a las operaciones CRUD, tenemos crear, leer y listar con escaneo, y ahora podemos completarlo con una consulta. Esta es solo una forma de trabajar con DynamoDB, y hay mucho más por aprender sobre modelado y construcción de aplicaciones más grandes.

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.

13. Inspección de Resultados y Realización de Eliminaciones

Short description:

Eso nos dará un resultado y vamos a inspeccionar el valor de ese resultado. A medida que diseñes y aprendas cómo modelar aplicaciones de DynamoDB, utilizarás IDs para consultar grupos de elementos en jerarquías. Puedes agregar condiciones para obtener más de un elemento por ID. Vamos a eliminar una fila y realizar todas las operaciones CRUD: crear, leer, actualizar, eliminar. Utiliza un marco de pruebas como tape para proyectos de node, ya que está más cerca del metal y proporciona más confianza en los resultados de las pruebas. Obtén el código para obtener los gatos y eliminar un gato por ID, luego verifica el resultado. Además, realiza un escaneo para ver el número de elementos en el escaneo.

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.

14. Building a DynamoDB Client

Short description:

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 el proyecto madure, probablemente querrás tener un módulo separado para interactuar con el código de los gatos. Esto permite que tu aplicación consuma ese modelo de forma independiente, liberándote de preocuparte por cómo se componen los componentes. Es solo la punta del iceberg cuando se trata de aprender DynamoDB.

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.

15. Recap and Conclusion

Short description:

DynamoDB se escala dinámicamente, tiene una gran capa gratuita, admite una sintaxis similar a SQL y funciona bien con Lambda. Es un poco extraño de aprender, pero si quieres intentarlo, sígueme en las redes sociales y únete a Architect Discord para obtener ayuda.

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.

16. DynamoDB y la Integración con Remix

Short description:

DynamoDB es un gran complemento para Remix porque proporciona un excelente rendimiento y características de escalabilidad. Aunque herramientas como Postgres son seguras y ampliamente utilizadas, no funcionan bien con cómputo efímero y funciones en la nube. Por otro lado, DynamoDB es una base de datos clave-valor que se adapta bien a estos escenarios. Aunque DynamoDB es relativamente nuevo y específico de AWS, ofrece un mayor nivel de abstracción y se puede integrar perfectamente con Remix. En general, Remix proporciona una forma limpia y eficiente de manejar patrones de acceso a datos, ya sea que elijas usar Postgres o DynamoDB.

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.

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

React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Top Content
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Top Content
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.
JSNation Live 2021JSNation Live 2021
29 min
Making JavaScript on WebAssembly Fast
Top Content
JavaScript in the browser runs many times faster than it did two decades ago. And that happened because the browser vendors spent that time working on intensive performance optimizations in their JavaScript engines.Because of this optimization work, JavaScript is now running in many places besides the browser. But there are still some environments where the JS engines can’t apply those optimizations in the right way to make things fast.We’re working to solve this, beginning a whole new wave of JavaScript optimization work. We’re improving JavaScript performance for entirely different environments, where different rules apply. And this is possible because of WebAssembly. In this talk, I'll explain how this all works and what's coming next.
React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.

Workshops on related topic

React Summit 2022React Summit 2022
136 min
Remix Fundamentals
Top Content
Featured WorkshopFree
Building modern web applications is riddled with complexity And that's only if you bother to deal with the problems
Tired of wiring up onSubmit to backend APIs and making sure your client-side cache stays up-to-date? Wouldn't it be cool to be able to use the global nature of CSS to your benefit, rather than find tools or conventions to avoid or work around it? And how would you like nested layouts with intelligent and performance optimized data management that just works™?
Remix solves some of these problems, and completely eliminates the rest. You don't even have to think about server cache management or global CSS namespace clashes. It's not that Remix has APIs to avoid these problems, they simply don't exist when you're using Remix. Oh, and you don't need that huge complex graphql client when you're using Remix. They've got you covered. Ready to build faster apps faster?
At the end of this workshop, you'll know how to:- Create Remix Routes- Style Remix applications- Load data in Remix loaders- Mutate data with forms and actions
React Summit 2023React Summit 2023
106 min
Back to the Roots With Remix
Featured Workshop
The modern web would be different without rich client-side applications supported by powerful frameworks: React, Angular, Vue, Lit, and many others. These frameworks rely on client-side JavaScript, which is their core. However, there are other approaches to rendering. One of them (quite old, by the way) is server-side rendering entirely without JavaScript. Let's find out if this is a good idea and how Remix can help us with it?
Prerequisites- Good understanding of JavaScript or TypeScript- It would help to have experience with React, Redux, Node.js and writing FrontEnd and BackEnd applications- Preinstall Node.js, npm- We prefer to use VSCode, but also cloud IDEs such as codesandbox (other IDEs are also ok)
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
Remix Conf Europe 2022Remix Conf Europe 2022
156 min
Build and Launch a personal blog using Remix and Vercel
Featured Workshop
In this workshop we will learn how to build a personal blog from scratch using Remix, TailwindCSS. The blog will be hosted on Vercel and all the content will be dynamically served from a separate GitHub repository. We will be using HTTP Caching for the blog posts.
What we want to achieve at the end of the workshop is to have a list of our blog posts displayed on the deployed version of the website, the ability to filter them and to read them individually.
Table of contents: - Setup a Remix Project with a predefined stack- Install additional dependencies- Read content from GiHub- Display Content from GitHub- Parse the content and load it within our app using mdx-bundler- Create separate blog post page to have them displayed standalone- Add filters on the initial list of blog posts
React Day Berlin 2022React Day Berlin 2022
86 min
Using CodeMirror to Build a JavaScript Editor with Linting and AutoComplete
Top Content
WorkshopFree
Using a library might seem easy at first glance, but how do you choose the right library? How do you upgrade an existing one? And how do you wade through the documentation to find what you want?
In this workshop, we’ll discuss all these finer points while going through a general example of building a code editor using CodeMirror in React. All while sharing some of the nuances our team learned about using this library and some problems we encountered.
GraphQL Galaxy 2020GraphQL Galaxy 2020
106 min
Relational Database Modeling for GraphQL
Top Content
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