Explorando Bases de Datos Modernas en Aplicaciones React

Voy a hablar sobre bases de datos modernas en el ecosistema de React. Y primero, unas pocas palabras más sobre mí. Actualmente dirijo la experiencia del desarrollador en HDB. Anteriormente trabajé mucho con código abierto en Bleach.js y también alrededor de GraphQL en The Guild y antes en Hasura. Puedes encontrarme en Twitter como Alexandra says. Así que si tienes alguna pregunta o quieres hablar sobre cualquier cosa relacionada con bases de datos, no dudes en ponerte en contacto. O puedes visitar mi sitio web personal, alexandra.codes.

Así que no hace mucho tiempo, el trabajo de desarrollo era simple. Teníamos desarrolladores de front-end en el mundo de la UI, y teníamos desarrolladores de backend tratando con bases de datos, servidores, y así sucesivamente. Y había este muro entre ellos. Y cuando quería construir una característica, el flujo era como el equipo de diseño diseñaría la aplicación, luego el equipo de backend diseñaría la API, luego todos tendrían que discutir sobre la API, y luego los desarrolladores de front-end tendrían que esperar tal vez unas pocas semanas para que el equipo de backend terminara, luego podrían comenzar su trabajo. Y si había alguna inconsistencia, el trabajo comenzaría de nuevo.

Pero luego algo interesante sucedió en 2009 con el desarrollo de Node.js, porque de repente los desarrolladores de JavaScript podían escribir código de servidor también. Y eso cambió ligeramente el ecosistema. La pila mean era muy popular, así que Mongo, Express, Angular, y Node. Y luego también apareció Next.js en 2016. Y en 2019, Next.js introdujo rutas de API, lo que lo convirtió en un framework full stack. Y ahora también quiero que eches un vistazo a algunos de los años recientes. Así que en 2020, ese también fue un punto donde mucho cambió en el ecosistema de desarrollo. Así que tuvimos Prisma beta que de alguna manera llevó al desarrollo de algunas herramientas, por ejemplo, Bit.js, donde podías importar código de servidor directamente en tus componentes de cliente y ejecutarlo sin temer que se filtrara al navegador. Y luego también tuvimos algunos frameworks como Redwood, T3 con trpc-remix. Y en 2022, Next.js 14 anunció la integración con componentes de servidor de React. Así que con todos esos cambios del ecosistema cambiando y los frameworks evolucionando hacia full stack, el panorama de las bases de datos también cambió. Así que ahora que podemos saltar dentro y fuera de nuestros servidores dentro de nuestro front-end, dentro de nuestros componentes de cliente, podemos mover este límite de red como nos convenga. Así que con eso, ahora podemos explorar algunas de las soluciones modernas y sus fortalezas cuando se trata de bases de datos.

Y eso es especialmente importante porque los desarrolladores de front-end están escribiendo más a menudo código de backend hoy en día, y React es ahora un framework full stack. Entonces, ¿cuál es el componente más importante del backend? Es una base de datos. Y esa es la base de nuestra aplicación donde almacenamos nuestros datos y esos datos impulsan nuestras características. Y no voy a darte una receta sobre cómo elegir la mejor base de datos para tu proyecto, porque esa decisión puede ser un poco más matizada que solo mirar las características. Hay algunas decisiones como relacional, no relacional, OLAP versus OLTP.

Verás, es difícil de pronunciar, así que son muchas decisiones. Y esas decisiones deben tomarse, como, muy temprano, porque son costosas de revertir. Pero en lugar de eso, espero darte una visión general de lo que puedes esperar en 2024 y cuáles son algunas de las características que puedes tener en cuenta al mirar bases de datos. Porque la verdad es que, no solo en el mundo de los frameworks, mucho ha cambiado, sino también en el mundo de las bases de datos. Y si no estás, como, siguiendo el mundo de las bases de datos, podría ser, como, ya sabes, hay algunos tradicionales, como Postgres o MySQL. Pero la verdad es que tenemos muchos de ellos. Como, hay bromas de que hay una nueva base de datos cada semana. Y la cosa es que esas bases de datos tradicionales, realmente no pueden seguir el ritmo de cómo React u otros frameworks construidos sobre React han cambiado. Porque muchas cosas se han vuelto más fáciles. Y ahora podemos, por ejemplo, en este código con React Server Components, podemos acceder a la base de datos directamente en nuestro componente cliente. Y eso parece divertido, eso parece fácil. Pero luego hay una pregunta, como, ¿qué es esta DB? ¿De dónde viene? ¿Y cómo configurarla? Así que, esas decisiones y soluciones que hacen que esas decisiones sean más fáciles es algo de lo que quiero hablar. Porque las bases de datos son bastante difíciles, y hay mucho bajo la superficie que no realmente necesitamos preocuparnos cuando estamos construyendo aplicaciones. Y hay soluciones que de alguna manera nos quitan esta carga.

Así que, aquí viene la primera cosa. Y son las bases de datos serverless. Así que, con las bases de datos serverless, hacen por las bases de datos lo que serverless hace por los servidores. Dejan la complejidad de lado. También lo hacen, como, el grado de alivio de la complejidad depende de la plataforma elegida. Pero básicamente, abstraen algunas de las cosas difíciles de nosotros. Y hay algunos ejemplos, como Superbase o Firebase, que no solo, no solo nos dan bases de datos serverless, sino también un SDK encima que podemos usar, y otras características, como almacenamiento adicional, autenticación o AI. Y hay otros, como AWS Aurora, o PlanetScale, o Neon. Y en lo que se centran es en hacer que Postgres o MySQL escalen más fácilmente. También hay una tercera categoría. Y en esta categoría, pondría a Xeta, por ejemplo, que abstrae completamente la base de datos. Se llaman a sí mismos, como, Postgres++, porque no solo proporcionan una base de datos serverless, sino que también envuelven Postgres para tener funcionalidades adicionales. Y hay, por supuesto, algunas ventajas y desventajas. Tengo un error tipográfico en la primera ventaja. Así que, el escalado automático es obviamente una gran ventaja de las bases de datos serverless, mantenimiento completo, características de seguridad integradas. Pero también hay cosas como la dependencia del proveedor que podrías querer considerar, o opciones de personalización limitadas.

Pero aquí viene otra cosa que es muy importante hoy en día, cuando hablamos de bases de datos, son todas las cosas relacionadas con la IA. Así que, es importante, porque, como, las bases de datos con vectores prometen proporcionar búsquedas más profundas en los datos, y especialmente en datos no estructurados. Porque en lugar de, como, buscar palabras clave exactas, podemos buscar, como, un término más amplio y aún obtener resultados relevantes. Así que, tenemos como dos direcciones aquí. La primera son las bases de datos estrictamente enfocadas en IA, como, en otras palabras, bases de datos vectoriales. Y otra son las bases de datos, las regulares, con índices vectoriales.

Así que, los primeros ejemplos son Pinecone o ChromaDB, y están optimizados para IA y solo para IA, y muy a menudo ofrecen SDK, específicamente para trabajar con vectores. Aquí hay un breve ejemplo con Pinecone, donde puedes configurar una nueva conexión, y luego usar el SDK de Pinecone para trabajar con índices. Y la otra dirección son las bases de datos regulares, como las que usábamos antes, que añadieron funcionalidades de IA, porque con los LLMs volviéndose, como, comunes con chatGPT, creo que a finales de 2022, un montón de bases de datos añadieron la extensión PGVector como algo que está integrado, como SuperBase, Neon, Timescale.

Y eso es algo que, hoy en día, se espera tener cuando tienes una base de datos moderna. Así que, puedes, por ejemplo, hacer esto, puedes crear una extensión, puedes ejecutar create extension vector en tu Postgres, como, ya base de datos Postgres que ya tienes. O otro enfoque que HDB tomó fue tener esto usando la extensión AI, que es SQL y da vectores y también un SDK adicional. Aquí hay un breve ejemplo. Así que, básicamente creas un cliente de IA, y especificas el modelo. Puedes usar los modelos de OpenAI o los modelos de Anthropx, como desees. Y luego puedes usar el SDK para hacer ciertas cosas, como, en el ejemplo de la diapositiva, llamo conContext para proporcionar contexto a mi IA, a mi IA de astronomía que voy a usar para buscar ciertos términos. Y luego uso la función queryRug para hacer una pregunta basada en los datos que tengo en la base de datos. Y ahora, una nota rápida sobre, como, ¿cuál es el caso para las bases de datos de IA? Si tenemos vectores añadidos a bases de datos regulares, ¿todavía necesitamos bases de datos separadas como Pinecone o FromDb? Así que, creo que básicamente tienen dos direcciones. Una es que tal vez también añadan características de bases de datos regulares, para que puedas usarlas no solo como tu base de datos vectorial, sino también como tu base de datos regular. Y otra dirección es que las uses como un tipo de servicio separado. Esto es algo que podrías haber visto antes con Elasticsearch. Un montón de aplicaciones están usando Elasticsearch como una base de datos separada solo para servicios de búsqueda. Y tal vez algo similar suceda con Pinecones. Y luego otra tendencia muy importante es el branching. Y eso es algo que hace, como, nuestro desarrollo diario mucho, mucho más fácil. Así que, ¿qué es el branching? Es básicamente cada vez que estás trabajando en una característica y creas una nueva rama de Git, te gustaría tener una implementación de vista previa, ¿verdad? Pero si tu aplicación también tiene una base de datos, entonces necesitarías tener una copia de la base de datos contra la que se ejecuta la implementación de vista previa. Así que, esto es lo que algunas de las bases de datos hacen de forma predeterminada. Y se integran muy bien con GitHub, así que cada vez que haces un PR, hay una nueva rama. Luego, la base de datos crea la rama, la copia de tu esquema actual. Y también están realmente bien integradas con tus soluciones de hosting, como Verso.

Y también están realmente bien integradas con tus soluciones de hosting, como Verso.

Así que, aquí hay un ejemplo donde siempre que hago una rama de característica, se añaden nuevas variables de entorno a mi Verso que conectan con la rama correcta de la base de datos. Y luego otra tendencia entre las bases de datos modernas son las bases de datos multimodales. Así que, un ejemplo aquí es SurrealDB. Y lo que hacen es que te permiten tener diferentes tipos de datos en tu almacenamiento.

Así que, no tienes que tomar una decisión como clave valor versus documento o relacional versus no relacional. Puedes tenerlo todo dentro de una sola base de datos. Y cuando estás adquiriendo tus datos, cuando estás trabajando con tus datos, puedes decidir cuál usar. Aquí hay un ejemplo muy corto con la configuración de SurrealDB.

Creo que es una de las más prometedoras cuando se trata de trabajo multimodal. Otra cosa que es imprescindible en 2024 es una buena seguridad de tipos y experiencia del desarrollador.

Pero no queremos escribir esos tipos manualmente. Así que, algo con lo que probablemente todos estamos familiarizados es Prisma. Y en Prisma, haces la configuración una vez, y luego cada vez que un esquema cambia, el nuevo cliente de Prisma se genera basado en el esquema. Y tienes un ORM que sabe qué tipo de datos hay, cuál es la forma, cuáles son las relaciones, por lo que puedes usarlo con total seguridad de tipos.

Otra cosa, un poco más nueva, es Drizzle, que es algo similar. Declaras un esquema, y luego infiere el tipo basado en ese esquema que puedes usar para ejecutar funciones de manera segura en tu base de datos. Lo importante es que también viene con herramientas de migración, tanto Prisma como Drizzle, por lo que no tienes que preocuparte por usar una herramienta separada para eso.

Otro ejemplo en el mundo de la experiencia del desarrollador (DX) y la seguridad de tipos es EdgeDB. Así que, también declaras un esquema con qué tipos hay en la base de datos, cuáles son las relaciones, y ejecutas el comando de generación para generar el generador de consultas. Luego puedes usarlo de esa manera. Así que, importas el generador de consultas y ejecutas las funciones que están disponibles en tus datos.

Y hablando de EdgeDB, quería cubrir una tendencia más, y esa es las bases de datos relacionales de grafos. Así que, algo nuevo que hizo EdgeDB, que es algo similar a Xata que mencioné antes, porque EdgeDB también es una capa sobre Postgres. Así que, en EdgeDB, no hay concepto de tablas. Hay objetos. Así que, el enfoque es hacer que la consulta de relaciones sea mucho más fácil. Así que, es como combinar el mundo de SQL y GraphQL juntos.

Aquí hay un ejemplo, una consulta SQL que ejecutaría para obtener alguna información de la base de datos, junto con una consulta agregada. Así que, una consulta agregada, por ejemplo, calcula algunos valores, por ejemplo, el valor mínimo de cada una de las filas que tengo o un valor promedio. Y normalmente, en SQL, no existen juntos. Puedo tener datos o un valor escalar como con el agregado. Y esta es una consulta equivalente de EdgeDB donde puedo tenerlos ambos en el mismo lugar.

También tengo un ejemplo con un ORM, cómo se vería una consulta similar si quisiera tener datos. Y aquí agrego reseñas cuando tomo una calificación promedio. Y también, una consulta construida con el generador de consultas de EdgeDB para lo mismo. Y ahora es casi el final, y quería dejarte con algo más. Así que, estábamos pensando hace un tiempo, como, ¿cómo podemos combinar lo mejor de GraphQL y SQL? Y hay una cosa que sigue siendo relevante con React Server Components es una cascada de obtención de datos. Así que, imagina que tienes una aplicación, y en la raíz de tu aplicación, llamas, por ejemplo, como, la función GetSession, y luego, basado en si el usuario está autenticado o no, renderizas los componentes. Y si el usuario está, renderizas, como, un perfil de usuario y publicaciones de usuario, pero ambos necesitan esperar a que GetSession se complete.

Y hay tres enfoques. Podemos tener colocación, lectura de sondas o un compilador personalizado. Con la colocación, ejecutamos las consultas contra nuestro servidor o base de datos directamente dentro de los componentes particulares, y eso causa la cascada, y también puede ser difícil de optimizar. Luego hay otra manera. Podemos obtener todos los datos en un solo lugar, pero eso puede ser más difícil de escalar, porque tienes que pasar todas las sondas hacia abajo, y si tu aplicación crece, eso puede ser abrumador. Así que, aquí hay algo de lo que quiero hablar. Es un trabajo realizado por Terence Besman. Así que, se le ocurrió esta idea. ¿Qué pasaría si combináramos Relay de GraphQL y EdgeDB?

Porque lo que Relay hizo bien fue resolver este problema de cascada de obtención al tener un compilador personalizado y extraer todas las consultas que tenías en los componentes secundarios en un solo lugar y ejecutarlas una vez. Así que, se le ocurrió esta idea de que podríamos declarar fragmentos en las consultas de base de datos en HQL, y este es un lenguaje que está siendo utilizado por EdgeDB, y luego podemos, en este ejemplo, él tiene un fragmento de postal. También hay un defer opcional, lo que significa que puedes diferir la ejecución de eso solo si este componente está siendo utilizado, y en el componente secundario relevante, declaramos esta función. Así que, declaramos qué datos son necesarios por ese componente.

Así que, si esto es algo que te interesa, puedes escanear este código QR y crear su publicación en el blog. Hay más detalles también, y también un código fuente y algunos enlaces más. Así que, algunos puntos clave de esto. Algo con lo que quiero dejarte es que te mantengas adaptable y recuerdes que la selección de bases de datos no es permanente. Sí, esta decisión inicial es muy importante porque influye en muchas otras cosas, pero también es posible cambiar esa decisión si ya no te conviene.

Luego, también recuerda a tu usuario primero, así que ten en cuenta cuántos usuarios vas a tener, si necesitas tiempo real, y algunas otras características que podrían ser necesarias tener en tu solución de base de datos. Luego, también mantente informado conociendo más o menos cuáles son algunas de las tendencias en las bases de datos modernas, y la última es seguir construyendo, porque esta es también la manera de elegir la mejor solución.

Y había el... hay un caso para algo como la programación poliglota, que significa usar diferentes lenguajes de programación para hacer ciertas cosas, y también podría haber un caso para bases de datos poliglotas, lo que significa usar una base de datos diferente para una necesidad específica para optimizar para esa necesidad. Así que, muchas gracias. Puedes escanear este código QR y eso te llevará a las diapositivas.

Quería como que solo decir, observando este tipo de espacio, ya sabes, siendo un desarrollador en el espacio, y luego realmente como viendo la cantidad de complejidad que realmente cada desarrollador necesita como decidir para poder decidir un almacén de datos, es, ya sabes, como, ya sabes, por un lado miras como una integración SDK, ya sabes, como integración a tu marco de UI, pero luego también es el tipo de datos y rendimiento y todas esas cosas, es como, ¿qué piensas que es una rúbrica que la gente puede usar para como decidir qué es importante para ellos? ¿Hay, ya sabes, una buena especie de regla general? Bueno, como una regla general es que podrías tener algunos requisitos que son como imprescindibles y no quieres comprometerte en ellos, así que sabes que, por ejemplo, tu, no sé, tu proyecto va a ser intensivo en datos, así que probablemente no quieras ir con algo que carezca de rendimiento, y tal vez tu proyecto esté únicamente enfocado en IA, entonces este también es tu requisito. Así que, básicamente, como, enumera todos los imprescindibles y asegúrate de que la solución de base de datos los tenga. Sí, eso tiene sentido.

Muy bien, pasemos a las preguntas de la audiencia. La pregunta más votada aquí es realmente una pregunta que siempre tengo que pensar yo mismo también, que es, ¿cuáles son tus pensamientos sobre la adopción de bases de datos de vanguardia? Como, ¿quiénes son los primeros en adoptarlas fuera de los proyectos paralelos? Porque la base de datos es lo último que una persona, como cualquier desarrollador, quiere que desaparezca por eso. Sí, sí, quiero decir, esto es cierto, pero también, quiero decir, si estás pensando en nuevas bases de datos, y sí, existe el riesgo de que desaparezcan, el riesgo de bloqueo del proveedor, o sabes, tal vez no desaparezcan, pero simplemente como las personas que trabajan en ello dejarán de trabajar en ello, y luego tendrás que arreglar los errores tú mismo. Sé que ese es un riesgo, pero también, al ser un adoptador temprano, obtienes casi soporte a tiempo completo. Así que esa es la ventaja, porque, como, creo que las personas que crean la base de datos se asegurarán de ayudar y de dar forma a la herramienta como sea que, ya sabes, los primeros usuarios quieran. Pero sí, también es cierto que la mayoría de las nuevas bases de datos están destinadas primero a proyectos paralelos, porque primero necesitan una base de usuarios amplia para dar forma a la superficie de la API, y así sucesivamente. Sí, parece que, ya sabes, no conozco ninguno de los datos del mercado o tendencias del mercado, pero parece que las bases de datos que están experimentando mucha adopción son las que se basan en, ya sabes, motores SQL estándar, como, ya sabes, PlanetScale o Neon, y supongo que es el viejo, ya sabes, nadie fue despedido por elegir Postgres, ya sabes, ese tipo de cosas. Pero, ¿sientes que con una base de datos más personalizada, como HDB o algo así, hay una especie de enfoque de migración realista para las personas, ya sabes, si encuentras que tal vez la elección no fue la correcta, o tal vez la base de datos está evolucionando en una dirección que no? Sí, creo que esa es una buena pregunta, y es una pregunta que mucha gente tiene, y también la tenemos mencionada en los documentos. Como, hay una salida, por supuesto, si decides que no la quieres, y una buena cosa es que está construida sobre Postgres, así que no es como si estuviéramos, como, empezando desde cero y haciendo todo nosotros mismos. Pero sí, hay un cierto bloqueo del proveedor que debes tener en cuenta. No es imposible, ya sabes, volver atrás. Genial. La siguiente pregunta más votada aquí es, ¿cómo convencerías, ya sabes, a tus colegas, tal vez, o a tu jefe en, ya sabes, una tienda tradicional de SQL Server para probar algo como HDB? Como, ¿cuál es el argumento para las personas que ya tienen una herramienta anticuada y están contentas con ella? Creo que diría que puedes comenzar a enviar muy rápido. Sé que es como lo que todos dicen, que, como, puedes enviar rápido, pero realmente puedes, porque todas las complejidades de configurar la base de datos se eliminan. Como, si quieres tener, como, un Postgres regular, ¿cómo lo ejecutas? ¿En un Docker? Eso requiere un conocimiento de Docker, algo más, y algo más. Así que eso se elimina por completo. Y luego tienes todas las características, como la autenticación de IA que ya está ahí para que comiences a construir de inmediato sin configuración y sin herramientas adicionales. Como, sé algo para Elf, algo más para la base de datos de IA. Sí, eso tiene sentido. Ahora pasemos a preguntas un poco más técnicas. Aquí hay una. ¿Por qué es malo tener un servidor en cascada? ¿No es eso lo que ya hacen los servidores GraphQL? Bueno, no es inherentemente malo, pero a veces puede que no quieras esperar a que otros componentes se rendericen si sabes que los datos pueden ejecutarse en paralelo, por ejemplo, la solicitud. Sé que, como, cada navegador tiene, como, un límite de cuántas solicitudes pueden ejecutarse al mismo tiempo, pero aún así, podrías evitar tener que poner, por ejemplo, como un estado de carga o usar el suspense. Sí, eso tiene sentido. La siguiente pregunta que estaba mirando, como, tal vez esto ya estaba medio cubierto, pero también tal vez no estoy seguro de la respuesta, así que déjame preguntarlo de nuevo. Oh, ¿por qué usarías una base de datos vectorial personalizada sobre una base de datos con índices vectoriales? ¿Por qué no simplemente usar Postgres para esto? Como, ¿cuáles son, como, las características o las cualidades que obtienes? Bueno, para ser honesto, como, hoy en día usaría una base de datos con índices vectoriales porque la mayoría de ellas ya los tienen. Por ejemplo, si estás usando SuperBase, que es muy popular, SuperBase agregó pgVector, y hubo un tiempo en que, como, Pinecon o bases de datos similares, como, tuvieron, ya sabes, su momento, pero ahora creo que están siendo ligeramente desplazadas. Sin embargo, si quieres, si tu enfoque es solo en vectores, entonces podrías querer optimizar para eso. Ese es el único caso de uso. Como, si sabes que necesitas una fuerte optimización y no te importan otros tipos de datos.

Sí, y creo que la última diapositiva que tenías con una especie de, como, el mundo de las multi-bases de datos, ya sabes, como, creo que hay generalmente un adagio de programador de usar la mejor herramienta para el trabajo. Así que si un tipo específico de datos no se ajusta a tu almacén de datos existente, entonces tal vez en lugar de intentar meterlo allí, esa es una oportunidad para también probar algunos trucos nuevos.

Muy bien, bueno, estamos en el tiempo. Hay algunas preguntas más aquí, pero creo que estarás haciendo la sala de preguntas y respuestas después del panel.

Sí, exactamente ahora, supongo. Oh, después del panel. Oh, en realidad no sé. ¿Cuándo harás la sala de preguntas y respuestas? No tengo idea. Ahora, después del panel. De acuerdo. Así que Alexandra se unirá a nosotros para el panel en 10 minutos aquí en el escenario y en este stream. Y luego, después de eso, ya sabes, si ella no está ya exhausta de hablarnos durante una hora en ese momento, ya sabes, puedes hacerle las preguntas restantes que no pudimos abordar aquí. Así que muchas gracias, Alexandra. Muchas gracias. Y te veré en 10 minutos. Muy bien. Nos vemos.