Por qué el marco de trabajo de pila completa del futuro es un DSL

Hola a todos. Mi nombre es Vince. Soy parte del equipo fundador de Wasp. Soy responsable de las relaciones con los desarrolladores allí, y estoy aquí hoy para afirmar que el framework web del futuro será un DSL. Pero antes de comenzar a hablar sobre los DSL o por qué deberías preocuparte por ellos, me gustaría contar con la ayuda de dos buenos amigos míos aquí, Keanu Reeves y Micky Rourke.

Ahora, ellos nos ayudarán a entender una diferencia importante entre SQL y JQuery. Probablemente estés pensando, bueno, eso es fácil. La respuesta obvia es que SQL es un lenguaje de database mientras que JQuery es una biblioteca de front-end. Pero estoy hablando de algo un poco más específico que eso. Veamos, por ejemplo, la diferencia entre 2006 y 2023. Keanu Reeves allí, sigue siendo humilde, adaptable, hidratado. Está listo para asumir cualquier nuevo papel, y probablemente sea tan popular como cuando comenzó su career. Y en ese sentido, tiene mucho en común con SQL. Por otro lado, Micky tiene más en común con JQuery. Eso es desafortunado porque parece que ambos tienen sus mejores años detrás de ellos. Entonces podrías estar pensando, ¿qué demonios tiene que ver esto realmente con una presentación sobre DSL y frameworks web? Bueno, el punto simple es que SQL es un DSL y JQuery no lo es. Así que profundizaremos en este punto más adelante, pero hasta entonces, mantén esta comparación en tu mente.

Porque primero, vamos a comenzar con un breve ejercicio para poner algunas cosas en perspectiva. Y es un ejercicio bastante simple. Solo vamos a imaginar que estamos en la fase de planificación de construir una aplicación web de pila completa. Y podríamos usar literalmente cualquier aplicación como ejemplo. Pero básicamente esto es lo que pasa por mi cabeza cuando tengo que pensar en una aplicación de demostración para construir. Entonces vamos a cambiar a un editor de code y comenzar a planificar nuestra aplicación de lista de tareas en algún seudocódigo. Muy bien, aquí está el plan. Y podemos elegir cualquier tipo de sintaxis que queramos. Voy a inventar un seudocódigo similar a JavaScript o JSON o algo así. Entonces definamos una clase y la llamaremos lista de tareas. Y luego pensemos en qué tipo de cosas, quiero decir, estamos planeando una aplicación aquí. ¿Qué tipo de cosas debemos tener en cuenta? Y supongo que lo primero, lo obvio, es un título, podemos llamarlo lista de tareas app, muy imaginativo. Y lo siguiente podría ser, ya que es una aplicación de lista de tareas, necesitamos definir algunos modelos de database ¿verdad? Entonces definamos un modelo llamado Tarea.

Y los modelos generalmente tienen un ID, y simplemente lo haremos un número entero. Y una tarea de la lista de tareas tendrá algún tipo de descripción, ¿verdad? Como cortar el césped, hacer la colada. Entonces eso será una cadena. Y queremos relacionar estas tareas con el usuario. Así que pondremos una propiedad de ID de usuario aquí y la relacionaremos con un modelo de usuario y su ID.

Ahora que hemos terminado con eso, hagamos también el modelo de usuario. Y por supuesto, también le daremos un número entero de ID. Y mantengámoslo simple. Y hagamos una propiedad llamada Tareas, que es una matriz de tareas relacionadas que han definido. OK. Y dado que esto es para una aplicación de pila completa, necesitamos definir algunos puntos finales para nuestra tarea, ¿verdad? Llamaremos a eso Puntos finales de Tarea. Y sí, esta es una aplicación simple. Y básicamente necesitamos nuestros puntos finales CRUD esenciales. Tenemos obtener todos o buscar todos. Queremos crear una tarea. Y tal vez queremos actualizar una tarea, ¿verdad? Genial.

También queremos considerar el cliente. Así que necesitamos un componente raíz tal vez. Digamos raíz del cliente. Y sí, esta es una aplicación simple. Así que simplemente importaremos una página de React allí. Y la llamaremos main page dot TSX. Y tal vez podamos darle la raíz de, digamos, raíz del cliente. Raíz del cliente. Y eso será la raíz del cliente. Y luego queremos authenticate a las personas, ¿verdad? Queremos authenticate a los usuarios para que sus tareas estén asociadas con ese usuario. Y así seguiremos adelante. Y dado que esta es una demostración orientada a los desarrolladores, digamos que queremos autenticación social de GitHub. Esa es la única autenticación que queremos. Muy bien.

Genial. Aquí tenemos un plan bastante simple para una aplicación escrito en este pseudocódigo. Y lo que me gustaría señalar es lo genial que sería si esto realmente estuviera funcionando code? ¿Qué tal si pudiéramos simplemente definir las cosas de esta manera, como la autenticación, por ejemplo, y obtener autenticación de GitHub de pila completa? Se generarían componentes del cliente para nosotros, como el botón de autenticación de GitHub, el botón de inicio de sesión para las funciones del servidor que necesitamos para authenticate usuarios en el servidor, e incluso los database modelos.

Bueno, resulta que realmente podemos hacer esto. Y lo hemos hecho. Esto es lo que hemos hecho con Wasp. Y esto es cómo se ve realmente la aplicación de lista de tareas que acabamos de describir con Wasp. Y se hace utilizando una sintaxis bastante similar al pseudocódigo que acabamos de escribir. Y esto es posible porque hemos implementado un DSL en Wasp.

Ahora podrías estar pensando, oh no, OK, aquí hay otro framework que tenemos que aprender, un montón de nuevas tecnologías de las que tenemos que deshacernos. ¿Por qué no puedes dejar lo que no está roto en paz? Pero el objetivo con Wasp no es realmente reinventar la rueda aquí, solo mejorarla, como dice Dwight. Ya tenemos algunas tecnologías de desarrollo web realmente geniales a nuestra disposición, como React, Node.js y Prisma. Y estas son exactamente las tecnologías que Wasp aprovecha en su framework. Entonces, el DSL de Wasp simplemente actúa como el pegamento que une todo esto de una manera más eficiente.

Junto con tu React, Node.js y lógica de negocio de Prisma, definimos una descripción de alto nivel de nuestra aplicación en una sintaxis muy similar a nuestro pseudocódigo allí, que se encuentra en el archivo de configuración de Wasp. Y luego todo esto se pasa a nuestro compilador, que es un enfoque único de Wasp. Y genera todo el proyecto, front-end, back-end y código de implementación para nosotros. Así que obtienes una aplicación completa y lista para producción con autenticación de pila completa, rutas del cliente, un servidor Express.js independiente, una base de datos Postgres, trabajos Cron y muchas otras cosas. En el futuro, incluso planeamos admitir diferentes pilas y diferentes arquitecturas. Entonces, antes de explicar más sobre Wasp, volvamos a hablar un poco más sobre los DSL.

Si recordamos nuestro pequeño ejemplo de planificación y el pseudocódigo que escribimos, básicamente estábamos inventando nuestro propio pequeño lenguaje allí. Pero este es un tipo de lenguaje muy, muy específico. No se puede usar para hacer todas las cosas que un lenguaje de propósito general como C o un lenguaje como incluso JavaScript puede hacer. Solo está destinado a hacer una sola cosa. De hecho, es tan específico que está destinado a ser utilizado en un solo dominio, como aplicaciones web de pila completa en este caso. Y eso es lo que es un DSL. Es un lenguaje específico del dominio. Wasp es solo uno de los muchos DSL, sin embargo. Y como desarrolladores, ya estamos familiarizados con varios de ellos. Probablemente estés familiarizado con este chico malo aquí.

Esto es RegEx, y está comprobando el formato de una dirección de correo electrónico. Así que RegEx es un DSL. SQL, como mencioné al principio de la presentación, también es un DSL. En estos días, es más probable que lo escribamos en forma de ORM, como Prisma o SQLite, algo así. Pero aún está con nosotros después de todos estos años, al igual que nuestro buen amigo Keanu. Así que SQL es un DSL.

O este ejemplo obvio del mundo de React es JSX, que también es un DSL. Bueno, hemos establecido qué es un DSL y que realmente los usas con bastante frecuencia. Pero ¿por qué? ¿Por qué querríamos crear un nuevo lenguaje especializado que solo funcione para una cosa muy específica en lugar de simplemente usar esos lenguajes de programación generales que pueden hacer todo eso y más? Bueno, como dice Dwight, creemos que es posible mejorar, al menos en el caso de construir mejores aplicaciones web. ¿Realmente necesitamos especificar, por ejemplo, autenticación, enrutamiento, operaciones CRUD y todas estas cosas una y otra vez? No. Con los DSL, solo tienes que decir lo que quieres y sucede.

Veamos cómo. Aquí está nuestro ejemplo de RegEx de antes. Simplemente dijimos lo que queremos aquí. Realmente no nos importa cómo se valida o en qué orden, cuáles son los mecanismos. Solo decimos lo que queremos y obtenemos el resultado que buscamos. Entonces, si no estuviéramos usando RegEx en este caso, y en su lugar solo JavaScript por ejemplo, tendrías que escribir algo como esto, ¿verdad? Y esto es cómo podría verse el cómo, en lugar del qué. Tienes que especificar cada pequeño detalle de la comprobación. Es largo y bastante tedioso. SQL también es un ejemplo muy interesante. Nuevamente, esto es el qué. Solo tienes que especificar lo que quieres y no te importa cómo lo obtienes. Por otro lado, en el fondo está el cómo. Entonces SQL es un DSL y solo tienes que decir lo que quieres y todo esto sucede. No solo el motor de consulta SQL realiza los algoritmos de búsqueda correctos por ti, sino que también sabe cómo optimizar tu consulta para obtener velocidad, lo cual es bastante increíble que pueda empaquetar todo ese conocimiento y procesarlo en un comando tan corto.

Y aunque este es un ejemplo simple de JSX, podemos imaginar lo complicado que sería con un ejemplo más complejo, ¿verdad? Entonces, JSX nos ahorra tener que especificar exactamente cómo deben suceder las cosas. Pero, ¿por qué necesitamos un DSL para WebDev? Quiero decir, ya tenemos un montón de bibliotecas, muchos frameworks que pueden hacer todas estas cosas sin un DSL ya. ¿Realmente, realmente necesitamos esto? Además, podrías estar pensando, el próximo año, AI podrá encargarse de todo ese código boilerplate por nosotros, ¿verdad? Entonces, ¿cuál es el punto? Bueno, incluso con todo eso, esta es una búsqueda en Google que hice ayer y a pesar de todos los avances que hemos hecho en WebDev, parece que se está volviendo más complicado en lugar de más fácil, Este es un sentimiento que los desarrolladores expresan con bastante frecuencia. Así que todavía hay mucho por hacer. Entonces, ¿por qué los DSL podrían ser la posible solución a todo este lío de WebDev? Veamos tres razones por las que.

Entonces, la primera razón es básicamente un resumen de lo que hemos cubierto. Los DSL nos permiten decir lo que queremos, no cómo. Y pueden hacer esto porque son especializados, porque se centran en ese único dominio y no se centran en la implementación. Para la segunda razón, los buenos DSL son como Keanu. Envejecen muy bien, ¿verdad? Y eso se debe a que están vinculados al dominio nuevamente, que es ese problema y no la implementación o la solución. Para la tercera razón, recurramos a otro amigo nuestro, Paul Graham, fundador de YCombinator. Y voy a leer este tweet para ti. Esperaba que la tecnología hiciera que la programación fuera menos laboriosa, como lo hace con la mayoría de las cosas. Pero tengo que admitir que esperaba que sucediera mediante el cambio de los programadores a lenguajes más potentes en lugar de seguir escribiendo programas llenos de código boilerplate. Pero dejando que la IA genere la mayor parte de él. Entonces Paul tiene razón, ¿verdad? Estamos entrando en una era en la que las IA serán nuestros asistentes de codificación. Y necesitamos abstracciones que nos permitan colaborar fácilmente con ellos. Los DSL les brindan, a las IA o a los LLM, un conjunto claro de instrucciones y un camino hacia el desarrollo al tiempo que nos brindan algo que es fácil de leer y mantener. Aquí es donde los DSL realmente brillan y tal vez actualmente se pasan por alto. Podríamos decir que un buen DSL es una abstracción ideal para AI, pero eso se pierde la imagen más grande en realidad. El punto es que cualquier beneficio para los humanos también beneficiará a AI. Entonces, la tercera razón podría expresarse de la siguiente manera. Permite tanto a las personas como a AI utilizar abstracciones de nivel superior y requiere que tengan menos conocimiento experto. ¿Por qué es eso? Porque este conocimiento experto está incrustado en el DSL, como el ejemplo de SQL que vimos. Esto significa que obtenemos code que es más fácil de entender y mantener tanto para las personas como para AI.

Entonces, como ejemplo, imaginemos una aplicación de pila completa generada en JavaScript en comparación con un DSL. El código DSL para la autenticación se vería algo así o en realidad como esto, porque este es el código real de Wasp, Wasp auth code. Por otro lado, el código boilerplate de ExpressJS para autenticar a un usuario se vería algo como esto. Y parece obvio cuál sería más fácil de escribir, depurar, mantener, ya sea para IA o para humanos.

Entonces, para resumir, el desarrollo web tiene mucho margen de mejora y a menudo sabes lo que quieres, pero tienes que pasar mucho tiempo describiendo cómo se debe hacer. Mientras tanto, la perspectiva del usuario, las partes principales y los conceptos de las aplicaciones web han permanecido iguales durante mucho tiempo. Pero las tecnologías que usamos para implementarlos cambian continuamente. Por lo tanto, el espacio de soluciones está cambiando bastante rápido, pero el espacio del problema no lo hace. Por todo esto, el desarrollo web es un candidato perfecto para usar un DSL. Y esto es exactamente lo que resuelve Wasp. Nos ahorra mucho tiempo en el cómo y nos permite simplemente decirle lo que queremos y obtenerlo a cambio.

Como mencioné antes, Wasp es un marco de aplicación web de pila completa relativamente nuevo para React, Node.js y Prisma, y ya hemos acumulado más de 14,000 estrellas en nuestros dos repositorios principales de código abierto. Puedes ver el historial de estrellas aquí. Mucho ha sucedido recientemente, pero de todos modos hemos creado más de 40,000 aplicaciones utilizando Wasp y muchos usuarios satisfechos que se unen a Discord y otros lugares donde dejan testimonios como este, donde destacaré esta parte en la que un usuario dijo, en mi opinión, Wasp es tan revolucionario para mí como lo fue React hace muchos años. La simplicidad de Wasp y cómo el DSL captura la mayoría de las tareas de ingeniería de pila completa es genial. Así que ves que un usuario se da cuenta de que esta capacidad de decir qué en lugar de cómo es realmente poderosa. Volvamos ahora a esa aplicación de tareas pendientes que comenzamos a imaginar y mostremos algunas de las fortalezas de un DSL en acción.

De acuerdo, verás aquí que en el plan. Si escaneo rápidamente hacia atrás o cambio entre el archivo de configuración de Wasp y el plan, notarás muchas similitudes allí. Eso fue intencional. Deliberadamente escribí el pseudocódigo de una manera similar a Wasp para que entiendas que realmente puedes hacer cosas como esta, definir autenticación de GitHub y obtener autenticación de pila completa tan simple como escribir GitHub, por ejemplo. Echemos un vistazo rápido al archivo main.wasp y veamos qué más tenemos. Sí, tenemos esa ruta del cliente. Tenemos, nuevamente, nuestros modelos de base de datos como una tarea y un usuario. Y podemos obtener todos nuestros puntos finales simplemente definiendo CRUD y vinculándolo al modelo o entidad de la base de datos que queremos. Simplemente hemos dicho que queremos operaciones de obtener todo, crear, actualizar y eliminar. Por lo tanto, siempre estarán asociados con la entidad de tarea. Y en realidad no tenemos que escribir ningún código backend porque esto se encargará de todo. Además de eso, tenemos nuestras rutas de manera similar a cómo se hizo en el plan o el pseudocódigo. Pero podemos hacer otras cosas, como decir que queremos que esto sea un...

Solo los usuarios autenticados pueden acceder a esta ruta, ¿verdad? A esta ruta. Así que eso se encargará de la autenticación del lado del cliente también. Muy bien. Así que cambiemos al navegador ahora y veamos esto. De hecho, tenemos esta aplicación en funcionamiento, así que veámosla en acción.

Aquí está. Aquí está la página de inicio de sesión y puedes ver que no necesitamos buscar la autenticación de GitHub. Así que tenemos el botón de autenticación de GitHub allí. Pero tal vez quiera hacer un cambio. Tal vez quiera agregar un método de inicio de sesión simple con nombre de usuario y contraseña. Y una vez que la aplicación se recompile, deberíamos ver en el frontend el formulario de inicio de sesión. Y ahí lo tenemos. Lo tenemos. Quiero decir, ya he iniciado sesión. Así que simplemente iniciaré sesión con ese nombre de usuario y contraseña. Y verás que ya lo he completado con algunas tareas pendientes. Y podría decir, hoy quiero presentar en el Congreso de Node. Y sí, solo para comprobar que se están guardando en una database y pasando por el servidor ExpressJS. Cambiemos al Database Studio. Y aquí estamos. Correcto. Así que si actualizo eso, puedes ver que nuestra nueva tarea que acabamos de ingresar allí, presentar en el Congreso de Node. Y déjame simplemente eliminarlo de allí. Y volvamos a nuestra aplicación y, sí, se ha ido.

Entonces aquí puedes ver toda la aplicación desde el backend hasta las rutas y las páginas. Y puedes ver, ¿verdad?, que la página principal está autenticada. La aplicación utiliza una base de datos SQL, SQLite en lugar de Postgres, que también podrías usar. Y tiene autenticación de GitHub y una entidad de usuario y tarea. Así que eso es una característica extra muy interesante de usar un DSL.

Genial. Y si quieres comenzar con Wasp, también tenemos dos proyectos interesantes que podrían despertar más tu curiosidad que solo una aplicación de tareas pendientes. Y esos son OpenSaaS y Mage. Y OpenSaaS es una plantilla de SaaS de código abierto lista para producción, mientras que Mage es un agente de IA que generará un prototipo de aplicación de pila completa basado en una simple indicación.

Como dije, OpenSaaS es una plantilla de SaaS de código abierto y gratuita, y está a la altura de algunas de esas plantillas de SaaS pagas que probablemente hayas visto. Viene con suscripciones de Stripe, panel de administración, análisis de Plausible o Google, carga de archivos en AWS S3, ejemplos de API de OpenAI, además está completamente documentado y brindamos soporte para cualquier pregunta o usuario en nuestro Discord. Así que eso es realmente genial si estás interesado en eso y quieres construir un SaaS. O Mage, por otro lado, aprovecha el poder de nuestro archivo de configuración DSL de Wasp y lo utiliza como un conjunto de instrucciones para ayudar a guiar al LLM o a la IA en la construcción de prototipos completos. Sí, es otro asistente de codificación de IA, pero aprovecha el poder del DSL aquí. Y ya has visto lo poderoso que puede ser el DSL por sí solo. Así que creemos que hay mucho potencial aquí para Wasp en este espacio. Entonces, si quieres probar Usemage, visita usemage.ai y te proporcionará un archivo zip del código que puedes descargar y probar localmente. O si tienes Wasp instalado, puedes, o instalas Wasp, simplemente ejecutar el comando wasp new y puedes elegir entre estas plantillas de inicio. Y OpenSaaS y Mage, también conocidos como generados por IA aquí, están incluidos. Así que esa es otra forma genial de acceder a estas plantillas. Así que con eso, muchas gracias por escuchar nuestra presentación sobre por qué el framework web del futuro será un DSL. Si escaneas el código QR, te llevará a nuestro repositorio de GitHub. Así que visítanos. Y si quieres recibir actualizaciones sobre nuestro progreso, síguenos en wasplang en X. Muchas gracias. Adiós. Adiós. Adiós.