Video Summary and Transcription
Bienvenidos a una charla sobre el Mapeo Objeto-Relacional (ORM) y sus posibles trampas. El orador discute problemas con los modales y el patrón MVC, así como los beneficios de estructurar el código en torno a las características del sistema en lugar de ello. Presentan PlatformaticDB como una solución para el fácil desarrollo de backend, mostrando sus capacidades de despliegue y prueba. La charla también cubre la integración con Next.js, la escritura de consultas SQL personalizadas y los planes del orador para el soporte futuro y la compatibilidad con la base de datos.
1. Introducción a ORM
Bienvenidos a la charla sobre Mapeo Objeto-Relacional (ORM). ORM promete mapear tu base de datos a objetos de manera limpia, resultando en un código fantástico y bien organizado. Sin embargo, ORM puede ser un gran anti-patrón para tu código. Vamos a explorar por qué.
Hola a todos. Y bienvenidos a la charla que no te dejará dormir después del almuerzo. No sé. ¿Han comido bien hoy? Espero que sí. Pero espero que no estén durmiendo en esta charla. Así que por favor, empecemos a hacer un poco de estrés. Saben que estoy bromeando. No soy ese tipo de orador.
Entonces sí, para ser honesto, ya se ha dicho todo. No hay mucho que añadir. Hay un libro que sale sobre Fastify el 9 de junio. Así que si quieren echarle un vistazo, el nombre es Acelera el Desarrollo Web con Fastify. Está en Amazon. Probablemente es el primero de la categoría en este momento. Y está yendo como loco. De todos modos, aparte de eso, ni siquiera tengo una diapositiva para ello. Así que soy muy bueno promocionando.
De todos modos, esta charla es sobre un tema que realmente, realmente amo. Mapeo Objeto-Relacional. He estado usando Mapeo Objeto-Relacional probablemente la mayor parte de mi carrera, o una buena parte de mi carrera. Y sí, no sé. Entonces, ¿qué te prometen los ORM? Vale. Así que tienen esta especie de metáfora de, oh, vamos a mapear tu base de datos a objetos de manera muy limpia. Y si sigues estas reglas, tu código será realmente fantástico y bien organizado y no tendrá ningún problema. Sabes lo que pasa con los espaguetis cuando los cocinas, ¿verdad? Además, ¿cuántos de ustedes han usado Java en su vida? Vale, entonces para todos ustedes y para todos los demás, lo siento, ¿saben lo que le pasa a su aplicación cuando usa un ORM? Hiberna. Lo siento, chiste de Java, solo para la gente que conocía Java. He estado intentando conseguir algunos. He usado hibernate. Parece que soy joven, pero no lo soy. Entonces, ¿qué hacen los ORM que está mal y por qué es un gran anti-patrón para tu código? Así que cuando estás escribiendo, normalmente la mayoría de los ORM tienen este concepto de un objeto modal.
2. Problemas con Modales y el Patrón MVC
Los modales tienen tres responsabilidades principales: gestionar la persistencia, mantener los datos en memoria e implementar la lógica de negocio. Esto viola el principio de responsabilidad única. La popularidad del patrón MVC, modal-vista-controlador, es la razón por la que todos están usando modales. Sin embargo, este patrón tiene sus defectos. Al codificar una característica, tienes tres cajas: modal, vista y controlador. Pero en realidad, la vista a menudo falta, lo que resulta en un número excesivo de modelos. Por ejemplo, un proyecto real tenía 2.000 modelos, lo que provocaba un tiempo de carga de un minuto. Los ORM han estado entregando código spaghetti desde los años 90.
¿Cuántos de ustedes han codificado un modal? Todos, ¿verdad? No sé. ¿Quién no ha codificado nunca una clase modal en su vida? Genial. Vale, increíble. Así que bien por ti. Has esquivado una bala.
Entonces, ¿qué está mal con el concepto de un modal? El problema con los modales es que un modal típicamente tiene tres responsabilidades principales. Gestiona la persistencia, mantiene los data en memoria e implementa la lógica de negocio, lo que suena un poco demasiado. Existe algo llamado principio de responsabilidad única, que es algo, una de las cosas de ingeniería que se hizo algo popular. Entonces, no sé, pero ¿por qué todo el mundo está haciendo esto?
La razón por la que todo el mundo está haciendo esto es que existe un bonito patrón llamado patrón MVC, modal-vista-controlador. ¿Qué dice esta cosa? Es una estructura para organizar tu aplicación. Originalmente fue inventado por Smalltalk para desarrollar aplicaciones en el escritorio y luego adaptado para el front-end. Ay.
Ahora, ¿cuál es el problema? El problema es fácil de seguir. Así que típicamente, cuando, si estás codificando tu aplicación web Node o lo que sea, tienes tres cajas. Tienes el modal, la vista y el controlador. Tienes tres cajas. Así que quieres code una característica. Tienes tres cajas, pones la característica en una de tus tres cajas. ¿OK? Bien, ¿verdad? Ahora, ¿incluso tenemos, todavía tenemos vista? Probablemente no. Así que tenemos controladores y modelos. Bueno, muy rápidamente, tienes 2.000 modelos en tu aplicación. Es algo muy común, ¿verdad? Piensas que 2.000 es un número pequeño. Este es un número de un proyecto real. Tenían 200 ingenieros trabajando en una aplicación con 2.000 modelos. Y para que ese sistema comience, se tarda un minuto en cargar con todos esos códigos. ¿Por qué? Bueno, porque es un modelo vista controlador. Cargas todos tus modelos al mismo tiempo. No scale bien en complejidad, porque solo tienes dos cosas en las que reorganizas tus cajas. De hecho, los ORM son tan geniales que entregan código spaghetti desde los 90. ¿Vale? Lo siento.
3. Introducción a Fastify y Estructura de Código
En 2016, creé el marco de trabajo Fastify como una alternativa a la arquitectura de modelo-vista-controlador. En lugar de organizar el código alrededor de modelos, controladores y vistas, es mejor estructurarlo alrededor de las características del sistema. Este enfoque permite una migración más fácil a microservicios. El principio de Pareto, que establece que el 80% de los resultados provienen del 20% de las causas, se aplica al desarrollo de software. Podemos implementar muchas características con un esfuerzo mínimo, pero algunas características pueden ser desafiantes de desarrollar. El primer iPhone carecía inicialmente de la funcionalidad de copiar y pegar debido a su complejidad.
Es un sistema antiguo, finalmente. Y me gusta mi carbonara, por cierto, así que si quieres, podemos hablar de carbonara más tarde.
Entonces, en aquellos días, creé este framework llamado Fastify más o menos alrededor de 2016 y estaba buscando cómo podríamos estructurar nuestras aplicaciones. Y dije, bueno, sabes, realmente no deberíamos estar promoviendo una arquitectura de modelo-vista-controlador aquí. Entonces, ¿qué podemos hacer en lugar de modelo-vista-controlador?
Bueno, lo que realmente quieres hacer cuando estás construyendo una aplicación es que quieres estructurar tu code, organizando tu code alrededor de las características que estás construyendo. ¿De acuerdo? Entonces tienes tus productos, tienes tu carrito, ¿verdad? Y luego tienes tus pedidos. Probablemente tengas los metadatos del usuario, la publicidad, el B2B, el envío, no sé. Estoy perdiendo el último poco de espacio en mi, en el escenario. Entonces, de todos modos, tienes todas estas cosas y quieres alinearlas una tras otra y estructurar tu code alrededor de las características de tu sistema y no sobre el hecho de que es un modelo o un controlador o una vista. Entonces quieres que el code esté cerca del resto de las cosas. También te permite migrar a microservices cuando quieres migrar a microservices. ¿Correcto?
Entonces, de nuevo, ¿por qué todo esto importa? ¿Recuerdas cuando esto salió por primera vez? No sé cuántos de ustedes estaban haciendo software. Todos pensaron, oh, esto es un cambio de juego. ¿Y cómo se relaciona esto con el principio de Pareto? Bueno, el principio de Pareto nos dice que el 80% de los resultados provienen del 20% de todas las causas para cualquier evento dado. ¿Qué significa esto para nosotros y por qué se relaciona con el iPhone? Bueno, en la práctica, significa que podemos implementar el 80% de la característica, números inventados, por supuesto, con muy poco esfuerzo. De acuerdo. Podemos implementar muchas características con muy poco esfuerzo. Y algunas características van a ser increíblemente difíciles de desarrollar. Probablemente lo hayas visto todo el día. Sabes, empiezas un nuevo proyecto. Es un terreno virgen. Todos están implementando características cada semana. Y luego después de seis meses, la gerencia está muy molesta. Oh, tu velocidad está bajando. Estoy peleando con la mitad de ustedes o algo así. No sé. La gente está haciendo esto estos días. Entonces, ¿por qué importa con el iPhone? Cuando salió el primer iPhone, no tenía copiar y pegar. No sé si te acuerdas. El primer iPhone no podía copiar y pegar cadenas de data de una cosa a otra porque era muy difícil.
4. Optimizando para el Envío y Características Complejas
Perdón por la palabra. Fue extremadamente difícil implementar copiar y pegar en la vida real. Al construir algo nuevo, ¿deberías optimizar para enviar más características con menos esfuerzo o para facilitar tu vida al enviar características complejas? Muchos de nosotros caemos en la trampa de implementar cosas basadas en excelentes tutoriales que no funcionan en la práctica. Al elegir una tecnología, considera una que elimine las tareas repetitivas, incluso si puede requerir más esfuerzo en el proceso de desarrollo diario.
Perdón por la palabra. Fue extremadamente difícil. Por favor, censura en la grabación. Fue extremadamente difícil en el... Implementar copiar y pegar en la vida real. Es otro problema, desafortunadamente. Y entonces no lo hicieron. Bien. ¿De acuerdo? Envía más rápido.
Entonces, cuando estás construyendo algo nuevo, ¿qué optimizarías? ¿Optimizarías para enviar más características con menos esfuerzo? ¿O para facilitar tu vida cuando necesitas enviar las grandes? ¿Las que son realmente muy difíciles de hacer? Y típicamente como industria, todos nosotros caemos en esta trampa. E implementamos cosas que, usamos cosas que, tiene un gran tutorial y nosotros podríamos, todo es perfecto, de acuerdo. En el gran tutorial. Y ahora lo estoy usando en Root 4 Real y realmente no tiene sentido. De acuerdo. Lo he visto en la práctica. Entonces ese es el problema, ¿verdad?
¿Cómo implementamos la característica compleja? Entonces, ¿qué optimizarías? Y mira, si quieres elegir una tecnología, podrías decidir escoger una tecnología que te ayude a eliminar todas las tareas repetitivas. De acuerdo. Hasta el punto de, oh, quiero enviar algo súper rápido. Estoy usando una herramienta sin code porque es genial. De acuerdo. Puedo enviar, sabes, esa es la forma definitiva de deuda técnica de usar, escoger una herramienta sin code porque puedo enviar algo solo con unos pocos clics. Y hasta que no lo haga, es decir, no soporta mi flujo de trabajo. Y entonces estoy atascado y necesito reescribir todo desde cero. Sabes, esa es la forma definitiva de optimizar para, sabes, el comienzo de un proyecto o incluso, sabes, alguien dirá, oh, ni siquiera estoy haciendo eso. Solo estoy conectando juntas páginas de Figma para la primera iteración. Sabes, hemos visto a gente haciendo eso. Y es genial. Funciona. Pero entonces si quieres optimizar para características complejas, típicamente viene con un poco más de inconveniencia para los desarrolladores en su día a día. De acuerdo.
5. Desafíos con los ORM y Requisitos del Backend
Entonces, ¿qué haces? Volviendo a los ORM y por qué no me gustan. Los ORM te ayudan al principio de un proyecto para CRUD y tareas fáciles. Pero probablemente haya algo mejor que hacer. La mejor línea de código es la que no tengo que escribir. Cuando quiero escribir un backend, quiero que tenga la calidad que deseo y que pueda ejecutarse localmente.
Entonces, ¿qué haces? Vale. ¿Haces uno? ¿Haces el otro? No lo sé. Necesitas elegir. Oh, elige, elige. ¿Qué eliges?
Volviendo a los ORM y por qué no me gustan. Entonces, lo que ves es que estás codificando tu migración. tu esquema, y probablemente lo estás ejecutando. Y luego configuras tus ORM. Luego necesitas escribir tus modelos. Luego necesitas escribir muchas rutas o solvers para construir tus modelos. Y luego, después de un tiempo, estás jodido. Porque estás volviendo a escribir SQL personalizado de todos modos. Porque el ORM es lento y problemático y no hace lo que quieres. O no sabes lo que realmente está haciendo. Oh, solo estoy llamando a dos métodos aquí. ¿Por qué está ejecutando una consulta database tan larga? ¿Qué está pasando? De todos modos, no me gustan mucho.
¿En qué te ayudan los ORM? Bueno, los ORM te ayudan al principio de un proyecto para CRUD y muchas cosas que son fáciles. Probablemente haya algo mejor que hacer. Para mí, la mejor línea de code es la que no tengo que escribir. Tengo otra forma de decir esto, pero probablemente sea otra mala palabra que no puedo decir en el escenario. La realidad es que, si no tengo que escribir code, no se convierte en legado y no tengo que mantenerlo. Probablemente sea mejor para todos. Cuando quiero escribir un backend, tengo algunos requisitos para ello. Quiero un backend con la calidad que deseo. Lo siento, he estado haciendo esto de las notas por un tiempo. Pero quiero algo que pueda ejecutarse localmente. No quiero una de esas bases de datos sofisticadas en la cloud. Lo siento. Si te gusta Dynamo u otros, no estoy enamorado. Quiero una database que pueda ejecutar en mi computadora.
6. PlatformaticDB: Desarrollo Fácil de Backend
Quiero un backend con APIs personalizadas, autorización básica, soporte para GraphQL, REST y la capacidad de desplegarlo en cualquier lugar con múltiples bases de datos. El año pasado, creamos PlatformaticDB para ayudarte a construir una solución fácil de usar que no obstaculice el desarrollo de funciones complejas. PlatformaticDB es un paso menos que la codificación desde cero. Definir el esquema, aplicar las migraciones y PlatformaticDB se encarga del resto. Está construido sobre Fastify, con plugins de OpenAPI y GraphQL, lo que te permite codificar funcionalidades personalizadas en JavaScript. ¡Hora de la demostración! Estoy ejecutando nuestro generador para crear una base de datos y generaré los tipos más tarde.
Y decide dónde verlo. Luego quiero poder hacer consultas utilizando las APIs personalizadas de la database. Quiero una autorización básica, porque codificar la autorización es realmente super horrible. No sé cuántos de ustedes han codificado sistemas de autorización. Son horribles. Quiero GraphQL, soporte para REST, tal vez Apollo Federation, no lo sé. Quiero poder desplegarlo donde quiera y con múltiples bases de datos.
Así que vuelvo y code. Lo siento, esta era la charla. No, estoy bromeando. Y normalmente quiero tener el pastel y comérmelo al mismo tiempo. Quiero que este backend esté hecho, pero no quiero escribirlo. Así que el año pasado tuve esta idea de, tal vez puedo escribir algo que podría acelerar para todos ustedes la creación de esto. Y esta es parte de la razón por la que creamos lo que ahora se llama PlatformaticDB. Y en Platformatic lo que queremos hacer es ayudarte a construir una solución que puede ser muy fácil de usar al inicio de un proyecto, pero también algo que no se interponga en tu camino para realmente enviar funciones complejas. Así que construye algo gradualmente.
Así que PlatformaticDB, esencialmente es un paso menos que codificar tus cosas desde cero. Solo defines tu esquema, lo cual es genial, luego aplicas tu migración, lo que sea, y PlatformaticDB se encarga del resto, obtienes tus rutas y así sucesivamente. Y si necesitas algo personalizado, que por supuesto necesitarás algo personalizado, puedes simplemente codearlo con JavaScript, y te mostraré cómo hacerlo en un momento. ¿Cómo funciona? Bueno, todo está basado en Fastify, así que tenemos un plugin de OpenAPI, un plugin de GraphQL, y tu code, todo en el mismo proceso de nodo de Fastify, en el mismo sistema de Fastify, y todo funciona bien.
Así que es hora de la demostración. ¿Funcionará? Estoy desafiando al dios de las demostraciones, como siempre. Vale. No lo sé. Aparentemente tengo mala reputación por las demostraciones que no funcionan. Así que lo que estoy haciendo es ejecutar nuestro generador para crear una database. Y lo estoy haciendo ahora. Y sí, no, lo siento. No estoy haciendo NPM install ahora, pero lo haré más tarde. Y generar los tipos.
7. Despliegue y Pruebas con PlatformaticDB
Generamos un archivo de configuración, definiciones de tipo y migraciones. La tabla tiene dos campos y tipos automáticos. Desplegamos usando platformatic start, almacenamos datos como Star Wars, consultamos películas y usamos suscripciones y WebSockets. Construir APIs con esto es sencillo.
Y sí, no vamos a desplegar estos usando las GitHub Actions, aún. En otra cosa, estamos haciendo NPMI para que se instale, mientras estamos hablando.
Entonces, ¿cómo ejecuto esto? Entonces, ¿qué me genera esto? Esto ha generado algo interesante. Estamos generando un archivo de configuración y algunas definiciones de tipo, algunas migraciones. Esta es nuestra tabla de database, fácil, no fácil, lo que sea. Sabes, es una tabla con dos campos. Y también ha generado algunos tipos automáticos. Más sobre los tipos más tarde.
Entonces, lo que vamos a hacer ahora, vamos a llamar a platformatic start para desplegar esto. Ay, ¿qué pasó? Entonces podemos ir a platformatic DB, y tenemos esto. Y lo que podemos hacer es que podemos probarlo, por ejemplo. Y podemos almacenar algo llamado Star Wars aquí. Así que este es un generador de API abierta, y tenemos todas las cosas creadas para nosotros. Y lo ejecutamos, y esto ha sido almacenado como Star Wars. También podemos ejecutarlo como gráfico. Y podríamos, por ejemplo, consultar todas las películas y obtener todas las películas. ¿De acuerdo? Además, lo que podríamos hacer, podríamos usar suscripciones y WebSockets. Entonces, si queremos guardar algo más, como el Mago de Oz, podría ejecutarlo y... Oh, no, eso es cierto. Entonces necesito hacer eso. Necesito elegir Windows. Genial. Así que este Windows está ejecutando eso. Este Windows está almacenando no el Mago de Oz ahora, sino Harry Potter. Y estoy almacenando esto. Y como ves, obtuvimos Harry Potter en la otra ventana a través de la suscripción de GraphQL. Todo esto viene de serie, como dije. En realidad, es muy sencillo construir APIs con esto. ¿Qué más hay? Bueno, algunas cosas más. Así que esto ha terminado de ejecutarse.
8. Uso de Plugins Fastify y PlatformaticDB
Con los plugins de Fastify, puedes definir fácilmente tus propias rutas y personalizar tu aplicación. La función de carga en vivo en la interfaz de usuario de Waggly te permite ver los cambios en tiempo real. PlatformaticDB admite relaciones y proporciona herramientas para gestionar migraciones. Puedes agregar resolvers personalizados a GraphQL y realizar varias personalizaciones.
Entonces, lo que podríamos hacer, por ejemplo, es que tenemos un plugin. Y esto es solo un plugin normal de Fastify. Así que potencialmente podría llamar a mis decoradores, y, por ejemplo, podría definir mis propias rutas. Así que podría hacer app.get. Y no sé, obtener todos los títulos de mis películas. Y esto es realmente muy fácil de hacer. Y oh, necesito la flecha. Vale. Y no está mal, const titles. Espera. App.platformatic.entities.movie. Ves que hay autocompletado aquí. Así que find, y necesitamos pasar objetos vacíos porque los queremos todos. Y luego podemos devolver titles.map. Y aquí, m.title porque todo es correcto. Hemos actualizado esto. Y si vamos a nuestra interfaz de usuario de Waggly UI, la actualizamos, y automáticamente ya tenemos los títulos definidos. Todo esto es carga en vivo detrás de la escena. Y podríamos probarlo y ejecutarlo. Y esto está devolviendo los títulos que acabas de mostrar. Así que puedes personalizar fácilmente. Puedes agregar resolvers personalizados a GraphQL. Podrías agregar muchas cosas.
Vale, esto está bien. ¿Qué podemos hacer ahora? Bueno, admite relaciones. Admite todas las cosas que quieres pensar que podrías admitir. Así que, por ejemplo, si quieres relaciones, podríamos agregar platformatic db migrations create. Y obtuvimos una nueva migración. Y aquí, podríamos hacer otras cosas si queremos. Así que solo estoy consciente del tiempo, y estoy omitiendo algunas cosas.
9. Demostración de Migración y Platformatic DB
Puedo mostrarles cómo funciona la migración y desplegar en la nube de platformatic. Acabamos de aumentar nuestros planes de pago. Tenemos una nueva interfaz de usuario. Crea una nueva aplicación llamada jsonation-demo. Despliégala y espera a que se ejecute. Platformatic DB se construye sobre Fastify y ofrece pruebas y escritura fáciles con plugins.
Entonces, si quieren, puedo mostrarles cómo funciona la migración, si quieren venir después de la charla a mi stand, si están interesados. Algo que es muy genial, sin embargo, es que incluso podría desplegar esto en la nube de platformatic cloud, lo cual es realmente bastante agradable. Y acabamos de aumentar nuestros planes de pago. Así que si están interesados, sería genial. Y con suerte, los dioses de la demostración, terminaremos con el Wi Fi conmigo.
Así que tenemos una nueva interfaz de usuario. Así que solo necesitamos aceptar los nuevos términos de servicio. Y podemos crear una nueva aplicación. Y es jsonation-demo. Y creamos la aplicación. Necesitamos desplegar algo. Así que lo llamamos main. Y creamos una masterclass. Y esto se hace, lleva un poco de tiempo. Luego podemos descargar nuestras credenciales. Es main.plt.txt. Y solo necesito mover esto de las descargas a aquí. Vale. Y luego solo necesito hacer platformatic deploy keys main. Y ahora está desplegándose. ¿Funcionará, no funcionará? Veremos. Sobre el Wi-Fi, sobre el Wi-Fi de la conferencia. Así que normalmente, esto tarda un minuto y medio en cosas normales. Pero veremos si volvemos a ello más tarde para ver si se ha desplegado.
Entonces, mientras estamos en ello, platformatic DB está todo construido sobre Fastify. Todos esos son solo plugins de Fastify por lo que puedes usarlos cuando quieras, si quieres hacerlo. Muy fácil de probar, muy fácil de escribir. Hay docs y guías para todas estas cosas. Incluso puedes usar esos plugins en tu aplicación si quieres. Así que no necesitas usar nuestro corredor principal o cualquier cosa.
Pregunta sobre ORMs y Constructores de Consultas
¿Programé un ORM? Los constructores de consultas como Kinects o Keasley son geniales. Todos caen en la misma categoría y te ayudan a escribir consultas. Drizzle ORM es popular pero cae en la trampa de crear objetos modelo. Puede que no funcione para todas las aplicaciones.
Entonces, tengo una pregunta para ti. ¿Programé un ORM? Parecía Internet. Vale. Esta es una divertida. Como dije, platformatic cloud está disponible hoy. Así que todavía está funcionando. El Wi-Fi es lo que es. Así que estará allí en un momento.
Entonces, muchas gracias. Quizás el Wi-Fi me ayude. Estoy más o menos en el tiempo de preguntas. Así que en realidad estoy tomando la pregunta aquí hasta que esto esté hecho. Veremos si el Wi-Fi de la conferencia llega hasta mí. Así que aplaudamos a Matteo.
La primera pregunta que tengo para ti no está aquí, pero ¿qué opinas de cosas como constructores de consultas como Kinects o Keasley? ¿Están bien? ¿O están en el mismo reino de ORM? No, son geniales. Los constructores de consultas son geniales. Utiliza constructores de consultas. Realmente me gustan, para ser honesto. Internamente, PlatformRTDB está construido contra una de esas cosas. Así que soy más de una persona de tipo cadena de plantilla, pero todos caen en la misma categoría. Necesitas alguna facilidad para ayudarte a escribir esas cosas. Entonces, sí.
¿Y has oído hablar de Drizzle ORM o lo has visto? Lo hice. Mucha gente está hablando de ello. Yo medio... Es genial para los desarrolladores de TypeScript, hasta cierto punto. Todavía siento que está cayendo un poco en la misma trampa de crear objetos modelo y cosas así. No creo que... Puede funcionar para ciertas aplicaciones, pero probablemente no para todas. Vale.
Integración con Next.js y Soporte Futuro
Para hacerlo funcionar con Next.js, escribes tu API, la despliegas y la llamas usando fetch o clientes generados automáticamente. Pronto, habrá clientes fetch listos para usar. Actualmente utiliza OpenAPI pero también soportará GraphQL en el futuro.
Y luego una pregunta del público es, ¿cómo harías que algo como esto funcione con Next.js? Oh, esta es una gran pregunta. Entonces, típicamente lo que haces es que puedes escribir tu API, desplegar tu API en algún lugar, y luego llamar a esta API usando fetch, o algunos clientes generados automáticamente que usas en tu aplicación Next.js o Remix o Vue o lo que sea, Svelte. Pronto tendremos clientes fetch generados automáticamente, por lo que no necesitarás code ese cliente tú mismo, simplemente vendrá listo para usar, lo cual suena genial para ser honesto. El PR está abierto, así que esperemos que se haga pronto. ¿Eso utiliza el cliente OpenAPI? Sí, está construido alrededor de OpenAPI, pero pronto en el futuro también soportará GraphQL.
Consultas SQL personalizadas y soporte para TypeScript
Escribir consultas SQL personalizadas con Platform.js DB es súper simple, solo escribe SQL y ejecútalo contra la base de datos. Platformatic actualmente soporta SQL, pero el soporte para MongoDB está en el roadmap. Cuando se trata de consultas complejas, escríbelas en SQL. En cuanto al soporte para TypeScript, obtienes autocompletado si usas el ayudante de consulta CRUD y tipos definidos para tus tablas.
OK, genial. Hay una pregunta aquí, ¿cómo se ve escribir consultas SQL personalizadas con Platform.js DB? Oh, es realmente súper simple, solo escribes SQL y lo ejecutas contra la base de datos, es realmente súper simple. Si quieres, yo, por el tiempo es, tanto, tan poco tiempo, tanto que hablar, así puedo dar vueltas durante probablemente una hora, demostrando todas las características. Así que si quieres unirte a mí en mi stand, estaré muy feliz de darte una demostración completa.
Entonces, ¿usa algo como una plantilla etiquetada? Sí. OK. Genial.
Esta pregunta dice, ¿es posible implementar sistemas externos de PubSub para suscripciones de GraphQL en Platformatic? Entonces, tiene el suyo propio. Entonces, podrías conectarlo, potencialmente a lo que estás haciendo, sí. Gran pregunta sobre cómo necesitará... Probablemente necesitarás hacer algunas comprobaciones internamente para hacer las cosas a tu manera, pero es probable que sea factible.
Y la otra pregunta es, ¿hay algún soporte para bases de datos de documentos, o es solo SQL? En este punto, es SQL. Pero MongoDB está en el roadmap, así que eventualmente sucederá. Es en gran medida una cuestión de tiempo. Entonces, si realmente quieres hacerlo, probablemente estaré feliz de ayudarte a hacerlo. Te guiaré y contribuiré con esa característica. No es que toda la plomería necesaria esté ahí. Es solo una cuestión de hacer las cosas.
Esta próxima pregunta, creo que es más sobre consultas complejas. Están preguntando, ¿cómo manejas una cláusula WHERE en combinación con una tabla JOIN? ¿Cómo manejas consultas más complejas? Escribe tu consulta compleja en SQL. Es genial. Literalmente, es genial. Escribe tus consultas complejas en SQL, por favor. Es fantástico. Gran respuesta.
Esta próxima pregunta es sobre el soporte para TypeScript. Vi que generó tipos después de hacer eso. ¿Obtienes autocompletado dentro de tus consultas SQL? No, obtienes autocompletado si usas nuestro pequeño ayudante de consulta CRUD. Obtienes los tipos definidos para tus tablas. Si ejecutas una consulta, necesitarás convertir el resultado a ese objeto específico, esencialmente.
Entendimiento de Consultas y Soporte de Bases de Datos
El orador discute la dificultad de entender consultas complejas y menciona el soporte para varias bases de datos SQL, incluyendo Microsoft SQL. Expresan su disposición a implementar soporte para Microsoft SQL para suscriptores. El orador también aborda la compatibilidad de la plataforma con arquitecturas sin servidor, específicamente Lambda, y menciona la opción de desplegar en la nube de Platformatic.
La razón es que realmente no podemos entender lo que está haciendo tu consulta, para ser honestos. Porque si tienes consultas complejas con múltiples uniones y así sucesivamente, eso no se parece a ningún objeto que podrías haber estado usando antes. Sí, es un problema difícil de resolver.
Y esta última pregunta es simplemente sobre el soporte de Microsoft SQL. Entonces, ¿cuál es el soporte para las diversas bases de datos SQL? Soportamos PostgreSQL, MariaDB, MySQL y SQLite. Claro, podemos soportar Microsoft SQL. Si estás pagando por una suscripción, estoy feliz de implementarlo para ti la próxima semana. Espero que eso dé una respuesta de la realidad de alguien construyendo una empresa de código abierto. Así que si quieres patrocinar el trabajo, estaré muy contento de tener una charla.
Y esta última es, ¿esto funciona con serverless? Entonces, algo como Lambda, ColdStarts, ¿cuál es la historia? Entonces, OK, dos cosas. Entonces la primera, es, puedes desplegar Platformatic DB en Lambda. Hay una, tal vez. No sé. Veamos si funcionó. OK, no, no funcionó. Cosas divertidas. Y entonces, sí, no funcionó. Se estrelló. Vamos, demasiada gente usando la cloud después de que la lanzamos. Buenas cosas. Así que no funcionó. Los dioses de la demostración no estaban conmigo. Y entonces la idea es, puedes desplegarlo en Lambda, puedes desplegar en la cloud de Platformatic, y ese sería el truco. Pero, ya sabes, eventualmente funcionará. Genial. Lo siento. Muy bien. Voy a dar un gran aplauso para Matteo. Muchas gracias, Matteo. Gracias. Gracias.
Comments