1. Trabajando con una Base de Datos y Tipos
Estoy trabajando en una nueva aplicación con una base de datos para libros, autores y reseñas. El servidor web se conecta a la base de datos, ejecuta una consulta y muestra todos los libros. Encontré un error y descubrí la necesidad de tipos. Al definir una interfaz de libro y especificar la estructura de la tabla, resolví los errores de tipo. Ejecutar una migración me permitió manejar la posibilidad de valores nulos para el año de publicación.
Entonces, estoy trabajando en esta nueva aplicación genial, tiene una database donde tengo libros y sus autores y reseñas de libros. Incluso he introducido algunos data allí, por lo que tengo algunos de mis libros favoritos. Y tengo un servidor web genial aquí, se conecta a la database, ejecuta una consulta y muestra todos los libros. Entonces sí, creo que está bastante bien. Vamos a echar un vistazo.
Entonces, parece que tal vez tiene un error. Veamos qué está pasando aquí. Veamos. Entonces, ¿cuál es el tipo de libros? Es Any, es el resultado de la consulta Any, lo que significa que el libro tiene un tipo Any. Entonces, tal vez debería escribir, tal vez debería usar tipos para resolver este problema, porque después de todo, esto es el Congreso TS, por lo que podemos definir una interfaz de libro. Y vamos a mirar la estructura de esta tabla. Entonces, tenemos un ID, que es una cadena, y tenemos creado por, que es una cadena. Y tenemos un título, que es una cadena, y tenemos el año de publicación. Solo vamos a copiar eso. Para las personas de JavaScript aquí, los enteros son un tipo especial de número. Entonces, simplemente vamos con número. Y por último, pero no menos importante, tenemos contenidos, que es una cadena, o creo que podría ser nulo. Y con la biblioteca node-progress, creo que puedes especificar un tipo de retorno para una consulta. Y vaya, resulta que tenemos algunos errores de tipo. Entonces sí, creo que solo escribí mal año. Debería ser año de publicación. Entonces vamos a corregir eso. Y ahora si nos dirigimos aquí, ¿qué crees? Bastante bien. Entonces, los tipos pueden ser definitivamente útiles cuando estás trabajando con SQL. Pero no es toda la historia. Entonces, veamos qué sucede cuando ejecutas una migración. Entonces me di cuenta de que el año de publicación podría ser realmente nulo si no sabemos cuándo se publicó. Entonces, por ejemplo, ¿quién sabe exactamente cuándo se publicaron la Ilíada y la Odisea? Entonces, es mejor dejarlo como nulo. Entonces, vamos a ejecutar eso.
2. Manejo de Cambios en el Esquema de la Base de Datos
Nos encontramos con un problema cuando nuestro esquema de datos en la base de datos cambió, pero el tipo que escribimos manualmente no se actualizó en consecuencia. Al hacer que el año de publicación fuera nulo, resolvimos el error. TypeScript proporcionó un mensaje de error cuando intentamos restar nulo, lo que nos permitió solucionar el problema agregando una condicional.
Y podemos confirmar eso. Sí, tenemos nuestros nuevos libros y el año de publicación es nulo. Entonces sí, veamos qué sucede. Sí, nulo. Y hecho divertido, en
JavaScript 2022 menos nulo es de hecho 22 porque
JavaScript. Entonces el problema aquí es que cambiamos nuestro esquema de
data en la
database, pero este tipo que escribimos a mano no se actualizó para reflejar ese cambio. Entonces realmente, el año de publicación ahora es nulo. Entonces debería ser número o nulo. Y una vez que hacemos ese cambio, entonces
TypeScript nos da un error, ¿verdad? Entonces sí,
TypeScript es lo suficientemente amable para decir que no puedes restar nulo. Y entonces creo que aquí tengo la solución. Simplemente añadimos una condicional. Sí, genial. Y veamos si eso soluciona las cosas. Efectivamente, lo hace. Así que una vez más, los tipos pueden ser muy útiles, pero también hay algunos problemas potenciales aquí.
3. Uso de TypeScript y SQL con TypeORM
Voy a repasar diferentes enfoques para usar TypeScript y SQL juntos. Vimos el enfoque ingenuo de escribir SQL en bruto y codificar tipos a mano, pero carece de una única fuente de verdad. Si los tipos y la base de datos no coinciden, no sabes cuál es correcto. La primera elección es dónde quieres que esté la fuente de verdad. Si está en TypeScript, puedes usar TypeORM, que define las tablas a través de clases de JavaScript. El código del servidor utiliza el administrador de entidades para consultar la base de datos y detectar errores. TypeORM puede generar migraciones basadas en cambios en TypeScript.
Así que en esta charla de hoy, voy a repasar diferentes enfoques para usar TypeScript y SQL juntos, que creo que es una especie de enfoque de elige tu propia aventura. Hay muchas formas diferentes de hacerlo. Por cierto, si te gusta esta charla, puedes seguirme en Twitter o echar un vistazo a mi blog y mi libro. Así que vimos el enfoque ingenuo, que es escribir un SQL en bruto y codificar a mano los tipos para los resultados. Hay algunas cosas buenas sobre esto. Como vimos, obtenemos cierta seguridad de tipo. Y otra cosa buena es que realmente no introduce ninguna capa de indirección. Realmente estás tratando con muy inmediatamente con el SQL y con los tipos. El problema, sin embargo, es que no tenemos una única fuente de verdad, ¿verdad? Si los tipos y la base de datos no coinciden, que es lo que vimos cuando hicimos el año de publicación nulo, entonces no sabes cuál es correcto. Y ese es el problema fundamental con este enfoque. Así que la primera elección que realmente necesitas hacer es dónde quieres que esté la fuente de verdad. ¿Debería la fuente de verdad para los tipos estar en la base de datos o debería la fuente de verdad para los tipos estar en TypeScript? Si quieres que la fuente de verdad esté en TypeScript, entonces eso básicamente significa que estás usando un ORM. Así que vamos a ver cómo se ve este ejemplo usando TypeORM. Así que TypeORM es uno de los ORMs estándar para JavaScript. ORM es Mapeador Relacional de Objetos. Así que con TypeORM, definimos esta fuente de datos que dice cómo conectarse a nuestra base de datos y proporcionamos una lista de entidades y deberían parecer familiares. Ellos corresponden a las tablas en nuestro ejemplo anterior. Y en lugar de definir las tablas a través de SQL, las definimos a través de clases de JavaScript y proporcionamos estos decoradores para decirle a TypeORM que esto debería convertirse en una tabla y que estos deberían convertirse en columnas. Y también un poco sobre qué tipo de columna son. Así que en casos donde el tipo de TypeScript es ambiguo, necesitamos proporcionar información de tipo SQL y también podemos proporcionar información sobre la capacidad de ser nulo. Y para las relaciones extranjeras, podemos proporcionar información sobre la relación. Así que vamos a ver cómo se ve el código del servidor. Así que en lugar de ejecutar una consulta SQL en bruto, obtenemos este administrador de entidades y le decimos que encuentre la clase de libro y TypeORM sabe convertir eso en una consulta select en la tabla de libros. Y lo bueno de esto es que el tipo de resultado de esto es un array de libros, que es exactamente lo que querrías y por lo tanto tenemos suficiente información de tipo aquí para detectar el error. Así que podemos cambiar esto a año de publicación, y año de publicación, y veamos si podemos cargar esto por aquí. Hey, ahí lo tienes. Así que ¿cómo se ven las migraciones en este mundo? Así que vamos a pasar por el mismo proceso de, digamos que esta columna puede ser nula y también necesitamos añadir nulo a su tipo. Puedes ver que ya hemos obtenido un error en nuestro typescript, lo cual es bueno. Una de las cosas geniales de un ORM es que puede generar las migraciones por ti. Y así aquí va a detectar qué hemos cambiado en nuestro typescript y nos va a decir que ha generado una migración.
4. Proceso de Migración y Fuente de Verdad
Echemos un vistazo al proceso de migración y a la corrección de errores. Al incluir información sobre las relaciones entre entidades, podemos obtener datos adicionales de la base de datos. Los ORMs resuelven el problema de mantener sincronizados los tipos y la base de datos, generan migraciones y simplifican la escritura de consultas. Sin embargo, pueden ser una abstracción con fugas, requiriendo conocimiento de SQL, TypeScript y el ORM. La optimización del rendimiento de las consultas puede añadir sobrecarga, y otros usuarios pueden tener problemas con la fuente de verdad en TypeScript.
Así que echemos un vistazo a eso. Es más o menos lo que esperarías, alterar tabla, alterar columna, eliminar nulo. La migración descendente lo revierte. Reza para que nunca tengas que ejecutar la migración descendente. Así que sí, intentemos ejecutar esta migración. Dice que debería confirmar. Genial. Y ahora corrijamos este error acerca de un posible objeto nulo. Así que tengo una solución aquí. Vale. Así que demosle un segundo. Y una vez que esto cargue, debería tener una solución. Sí. Genial. Bueno. Como hemos incluido información sobre las relaciones entre las entidades, también podemos ir al siguiente nivel, podemos decirle a TypeORM que incluya la relación creada por. Y ahora podemos añadir otra columna y podemos hacer book.createdby.name. Así que esto debería incluir el nombre del autor además de la fecha de publicación. Bastante genial. Así que eso es lo que parece si pones la fuente de verdad en TypeScript. Así que hay algunas cosas buenas acerca de esto. Los ORMs definitivamente resuelven el problema de mantener tus tipos y tu database sincronizados. Es bastante agradable que generen migraciones para ti y las consultas simples son realmente bastante directas de escribir en ORMs. Y los ORMs, encontrarás mucho desagrado por ellos en línea, pero es innegable que son muy ampliamente utilizados. Así que en el lado negativo, son el ejemplo clásico de una abstracción con fugas. Así que la teoría con un ORM es que puedes tratar la database como un detalle de implementación y puedes simplemente trabajar en TypeScript. Pero en la práctica, eso realmente no funciona. Para usar un ORM de manera efectiva, necesitas conocer SQL, necesitas conocer TypeScript, y necesitas saber cómo usar el ORM. Y así, haciendo cosas como afinar el performance de una consulta, terminas trabajando con tu ORM para tratar de producir una consulta SQL muy específica, lo cual es simplemente añadir sobrecarga. Y también, si trabajas en un entorno donde hay múltiples usuarios de tu database, los otros usuarios pueden tener problemas con tu ser, estás poniendo la fuente de verdad
5. Generando Archivos de Esquema TypeScript
Si no estás utilizando un ORM, tener una versión TypeScript de tu esquema es útil. Herramientas como Schema TS, PyST Schema TS y pg2ts pueden generar archivos de esquema TypeScript desde tu base de datos. pg2ts se conecta a tu base de datos Postgres y genera un archivo de esquema DB autogenerado con interfaces para todas las tablas. Al utilizar este enfoque, te aseguras de que el archivo de esquema TypeScript y la base de datos nunca se desincronicen, ya que la base de datos es la fuente de verdad.
en
TypeScript en lugar de la
database en sí. También hay mucho más cambio en el sabor del mes con los ORMs que con las bases de datos en sí. Postgres y MySQL han estado alrededor por décadas ahora y todavía son bastante populares. Entonces, ¿qué pasa si no vas a usar un ORM? Bueno, entonces es indudablemente útil tener una versión
TypeScript de tu esquema. Entonces, puedes ir en la otra dirección. Puedes ir desde el esquema de la
database a
TypeScript. Así que, vamos a echar un vistazo a eso. Así que, vamos a ver las herramientas para generar archivos de esquema
TypeScript desde tu
database. Entonces, el abuelo en este espacio es Schema TS, que obtuvo muchas estrellas. Y luego no hay cambios en más de cuatro años. Así que también obtuvo muchos forks. Entonces, está este PyST Schema TS, que tiene alrededor de dos años de antigüedad. Entonces, hay muchos forks. Y yo también tengo uno, llamado pg2ts. Y eso es lo que voy a mostrar a todos hoy. Entonces, la idea con pg2ts es que ejecutas un comando y entonces, pg2ts generate, se conecta a tu
database Postgres y genera este archivo de esquema
DB. Entonces, vamos a echar un vistazo a ese archivo de esquema
DB. Entonces, autogenerado y tiene interfaces para todas nuestras tablas. Entonces, lo bueno de esto es que no tienes que escribir este tipo de libro a mano. Entonces, vamos a conectarlo, igual que hicimos antes. Vamos a importar, y ahora deberíamos obtener un error de tipo. Sí, debería ser año de publicación y esto también debería ser año de publicación. Ahí vamos. Y veamos si eso soluciona el problema. Efectivamente, lo hace.
Entonces, superficialmente, esto podría no parecer tan diferente a lo que hicimos antes, cuando escribimos el tipo a mano, pero la belleza de esto es que en la práctica, ejecutarías PGTTS como parte de tu integración continua testing. Y así, te asegurarías de que este archivo de esquema TypeScript y la database nunca se desincronicen entre sí. Entonces, la database es la fuente de verdad y este esquema DB se deriva de ella. Entonces, intentemos ejecutar la migración. Entonces, ahora, si miramos este año de publicación, es nulo.
6. Generador de Esquemas y Constructor de Consultas
Voy a volver a ejecutar PGTTS generate para escanear la base de datos de nuevo. El generador de esquemas produce entidades que corresponden a los tipos de base de datos en TypeScript y los mantiene sincronizados. Añade una etapa de construcción y requiere anotaciones de tipo manual para las consultas. Si no estás utilizando un ORM, se recomienda un generador de esquemas.
Y volvamos a abrir nuestro esquema
DB. Vale. Así que, simplemente voy a volver a ejecutar PGTTS generate. Así que, va a escanear nuestra
database de nuevo y he aquí, el año de publicación es ahora nulo. Y así, ahora también obtenemos un error de tipo, igual que antes. Así que eso es lo que hace un generador de esquemas. Así que, hace un muy buen trabajo produciendo entidades que corresponden a tus tipos de
database en tu
typescript y manteniéndolos sincronizados. La desventaja es que añade una etapa de construcción y tienes que añadir manualmente las anotaciones de tipo para tus consultas. A menos que añadas algún otro proceso del que hablaremos más adelante. Pero, en general, si no estás utilizando
7. Uso de Connects JS para la Construcción de Consultas
Una vez que hayas decidido si usar un constructor de consultas o SQL en bruto, Connects JS es una opción popular para JavaScript y TypeScript. Infiera automáticamente los tipos y ayuda a capturar errores. Definiendo tablas y utilizando la tabla de tipos de Connects, puedes asegurarte de que se extraigan los tipos correctos. Las migraciones se pueden utilizar para manejar cambios de esquema, y también son posibles consultas más complejas, como la unión de tablas.
un ORM, deberías usar un generador de esquemas. Entonces, una vez que hayas hecho eso, tu siguiente pregunta es si quieres usar un constructor de consultas o escribir SQL en bruto. Así que, veamos la opción del constructor de consultas. Connects JS es probablemente el constructor de consultas más popular para
JavaScript y
TypeScript. Así que, echemos un vistazo a cómo se ve este ejemplo usando Connects. Para consultar la
database, usamos este objeto Connects y le decimos que queremos mirar la tabla de libros y queremos seleccionar todo de ella. Y Connects es lo suficientemente inteligente para descubrir que tiene un tipo de libro y ya obtenemos algunos errores de tipo, que es lo que queríamos. Entonces, ¿cómo funciona esto? Así que, supongo que estás ejecutando pg2ts o algo así para obtener esta interfaz de libro definida en
TypeScript. Eso es un bloque de construcción importante. Luego está también esta tabla de tipos de Connects, que puedes usar para informar a Kinects sobre tu esquema. Así que, defines esta interfaz de tablas y tiene una lista de todas tus tablas. Y es capaz de, si consultas desde una de estas tablas, es capaz de extraer los tipos correctos. Así que, eso es bastante genial. Así que, podemos seguir adelante y corregir el error aquí. Y así, por aquí. Genial. Así que, guardemos eso. Y recargamos. Genial. El error está corregido. Así que, veamos cómo se ve una migración en este mundo. Así que, voy a seguir adelante y ejecutar mi migración. Y así, ahora, como podrías recordar, el año de publicación es nulo. Así que, ahora, tengo que regenerar el esquema de la
DB. Así que, ahora, si sigo adelante y miro en el esquema de la
DB, sí, el año de publicación es nulo. Y efectivamente, tenemos un error de tipo en index.ts, que es exactamente lo que queremos. Y así, podemos seguir adelante y solucionar el error, y si vamos por aquí, genial, está corregido. Así que, también puedes hacer consultas ligeramente más elaboradas con Connects. Así que, aquí tienes un ejemplo de unir la tabla de libros con el autor. Así que, introduzcamos eso. Así que, estamos consultando la tabla de libros como antes, pero ahora, vamos a unirnos a la tabla de usuarios, uniendo la columna book.createdBy a la columna users.id, y si miras el tipo inferido, es libro y usuarios, el tipo de intersección, que es en realidad
8. Uso de Constructores de Consultas y PGTyped
Añadamos el autor y veamos si funciona. Los constructores de consultas proporcionan tipos precisos sin anotaciones explícitas, pero pueden ser complejos. PGTyped es una herramienta que convierte las consultas SQL en tipos de TypeScript, generando un archivo de tipos. Ejecuta la consulta y devuelve el tipo como cualquier. Al agregar el tipo de consulta a la plantilla etiquetada, obtenemos un tipo agradable y podemos corregir cualquier error. PGTyped realiza una introspección en el esquema de la base de datos en vivo, lo que nos permite ejecutar migraciones y manejar campos nulos.
exactamente correcto. Entonces, vamos a añadir el autor. Creo que sale como nombre, y si guardamos, deberíamos poder cargar. Sí, funcionó, bastante genial. Bueno, ¿cómo se compara el Constructor de Consultas con algunas de las otras soluciones que hemos visto? Creo que lo bueno aquí es que definitivamente obtienes tipos precisos, y no tienes que introducirlos a mano. Es capaz de usar el esquema de la
DB y tus consultas para obtener tipos precisos sin anotaciones explícitas, lo cual es genial, pero desafortunadamente, los Constructores de Consultas son otro ejemplo clásico de una abstracción con fugas. Entonces, para usar un Constructor de Consultas, especialmente para consultas más complicadas, realmente necesitas conocer tu
TypeScript, realmente necesitas conocer tu SQL, y realmente necesitas conocer tu Constructor de Consultas. Entonces, si miramos la documentación de Connex, afirman que su soporte para
TypeScript es un esfuerzo máximo. Creo que lo están subestimando un poco. Creo que es realmente bastante bueno. Pero si miras algunas de estas consultas, no está totalmente claro para mí que la sintaxis del Constructor de Consultas sea más simple o más complicada que la sintaxis SQL de Postgres. Y en ese punto, lo que se ejecuta es SQL y probablemente deberías estar escribiendo el SQL de todos modos.
Entonces, ¿qué pasa si no vas a usar un Constructor de Consultas? Bueno, entonces tenemos otra opción, que es una herramienta para convertir tus consultas SQL directamente en tipos de TypeScript. Así que hay algunas herramientas como esta y vamos a ver PGTyped. PGTyped es una herramienta que lee consultas SQL y genera tipos de TypeScript para ti. Así que tiene una buena documentación aquí. Así que vamos a ver cómo nos puede ayudar. Así que con PGTyped, importas esta etiqueta SQL y la añades a tus consultas SQL y luego pasas tu pool de database y cualquier parámetro a la consulta y ejecuta la consulta por ti. Y el tipo vuelve como cualquier. Entonces, ¿cuál es el punto de eso? Así que lo interesante aquí es que podemos ejecutar PGTyped y generará un archivo de tipos para nosotros, así que podemos echarle un vistazo. Así que esto tiene el tipo de resultado de la consulta y si tuviéramos parámetros en la consulta, también los incluiría. Y la idea es que añades este tipo de consulta a la plantilla etiquetada y tenemos que importarlo. Y ahí lo tienes y ahora tenemos un tipo agradable y muestra el error, así que sabemos que podemos corregirlo. Lo corriges y ahí lo tienes. Así que lo interesante aquí es que no ejecuté, no generé un esquema de db, simplemente está haciendo una introspección en esta consulta contra nuestro esquema de database en vivo. Así que podemos intentar ejecutar una migración. Así que vamos a hacerlo. Así que podemos comprobar que nuestro libro, sí, el año de publicación es nulo y así aún no tenemos un error, pero si volvemos y volvemos a ejecutar pgTyped ahora sabe que el año de publicación es nulo y por lo tanto necesitamos conectar una expresión más cuidadosa allí. Así que vamos a intentarlo.
9. Uso de CreedlyTyped y PGTyped
Aquí uno manualmente el autor para extraer el nombre del autor de la otra tabla. Ejecutando pgTyped de nuevo con la consulta actualizada proporciona el tipo correcto. Aunque el SQL en bruto con tipos es genial, hay desventajas como la inferencia de tipos imperfecta y la necesidad de un paso de construcción. Los resultados de la consulta pueden ser un poco de tipo pato, resultando en diferentes tipos para la misma consulta. El punto dulce se encuentra entre la conversión de SQL a TS y los constructores de consultas. CreedlyTyped genera consultas simples, mientras que PGTyped maneja las más complejas. Vamos a explorar CreedlyTyped y PGTyped creando un typedDB y utilizando el objeto de tablas de nuestro esquema de db.
Sí, ahí vamos. Y también podemos intentar una consulta más complicada aquí. Así que aquí estoy uniendo manualmente al autor para poder obtener eso. Así que puedo extraer el nombre del autor de la otra tabla, de la tabla de usuarios. Así que ahora que he cambiado mi consulta, necesito ejecutar pgTyped de nuevo. Y si miro esta consulta, ahora tiene authorName y tiene el tipo correcto. Y así puedo entrar aquí y puedo añadir mi authorName. Y déjame ver. El servidor se reiniciará, y ahí tienes, tenemos los nombres de los autores.
Bueno, ¿cómo se compara esto? Así que lo genial es que simplemente puedes escribir SQL en bruto y obtienes tipos de vuelta para tus consultas. Sin embargo, hay algunas desventajas. No todos los tipos vuelven perfectamente. Así que hay algunos problemas al detectar cuándo una columna en los resultados de una consulta puede ser nula. Al igual que con algunos de los otros enfoques, añade un paso de construcción. Los resultados de las consultas son un poco de tipo pato. Así que si ejecutas la misma consulta exacta en dos lugares diferentes, obtendrás dos tipos distintos. Serán compatibles. Y así con la tipificación estructural, eso está bien. Pero creo que generalmente es más agradable trabajar con el esquema de DB. Y a veces parece mucho alboroto para consultas realmente simples que tienes que escribir esta declaración SQL etiquetada y luego añadir un tipo que generas para ellas. Así que creo que entre la conversión de SQL a TS y los constructores de consultas, hay una especie de punto dulce. Así que quiero mostrarte cómo se ve eso. Hay algunas enfoques. Así que Zapatos es un ejemplo. Pero voy a mostrarte PGTyped y CreedlyTyped, que es una herramienta que construí. Así que la idea con CreedlyTyped es que genera todas las consultas simples para ti. Pero si tu consulta deja de ser simple, si se complica más, entonces deberías ejecutar algo como PGTyped. No hace ningún intento de modelar esas consultas. Así que vamos a echar un vistazo. Así que vamos a crear un typedDB. Y le vamos a pasar un objeto de tablas de nuestro esquema de db, que se genera como antes. Y luego, en lugar de generar la consulta GetBooks de esta manera, vamos a hacer
10. Uso de TypeScript y SQL: Beneficios y Compromisos
Esta sección discute los beneficios de usar TypeScript y SQL juntos. Destaca un enfoque de término medio donde se utiliza rawSQL para consultas complejas, proporcionando tipos precisos. Para consultas más simples, se pueden obtener tipos precisos basados en el esquema de la DB. Sin embargo, hay desventajas, como la necesidad de un paso de construcción y la tentación de confiar demasiado en consultas generadas simples. La charla concluye enfatizando la importancia de ser consciente de los compromisos involucrados en trabajar con SQL y TypeScript.
getbooks es igual a typedDB.table. Conoce nuestras tablas. Y simplemente vamos a generar un select. Y simplemente llamamos a esto con nuestro
db pool. Y genial. Así que sabe sobre los tipos, los tipos hacen referencia a nuestro esquema
db. No tenemos esto porque no hemos hecho un join.
Y así que si vamos aquí, sí, funciona. Y puedes agregar algunas cosas un poco más complicadas como si quieres hacer un join. Realmente lo trae como un, ¿qué es? Creado por. Sí, creado por. Realmente lo trae como un sub-objeto. Así que es author.name. Y sí, ahí vamos. Bueno, ¿cómo se compara esto? Creo que bastante bien. Creo que es un buen término medio. Para consultas complicadas, simplemente llegas a escribir rawSQL y obtienes tipos precisos. Pero para las consultas más simples, que en mi aplicación principal son algo así como el 70% de las consultas. No tienes que pasar por mucho proceso y obtienes tipos precisos basados en tu esquema DB. Hay algunas desventajas. Todavía añade un paso de construcción. Y creo que a veces hay la tentación de usar las consultas generadas simples más a menudo de lo que deberías. Así que en lugar de ejecutar 10 consultas simples, probablemente deberías mover parte de esa lógica a Postgres y simplemente ejecutar una consulta. Así que esa es la charla. Hay muchas decisiones que tomar cuando estás trabajando con SQL y TypeScript y ninguna de las opciones es perfecta. Pero creo que lo importante es simplemente ser consciente de qué enfoque estás tomando y entender los compromisos. Espero que hayas disfrutado la charla. Echa un vistazo a mi libro y mi blog y sígueme en Twitter. Gracias.
React Advanced Conference 2021
Comments