El Framework Full-stack del Futuro es un DSL

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 base de datos, 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, ahí está, sigue siendo humilde, adaptable, hidratado. Está listo para asumir cualquier nuevo papel. Y probablemente sea tan popular como cuando comenzó su career. En ese sentido, tiene mucho en común con SQL. Por otro lado, Miki tiene más en común con jQuery. Y eso es desafortunado porque parece que ambos tienen sus mejores años detrás de ellos.

Puede que estés pensando, ¿qué demonios tiene que ver esto realmente con una presentación sobre DSL y marcos web? Bueno, el punto simple es que SQL es un DSL y jQuery no lo es. Profundizaremos en este punto más adelante, pero hasta entonces, mantén esta comparación en la parte trasera de tu mente. Porque primero, vamos a comenzar con un breve ejercicio para poner algunas cosas en perspectiva. Y es un ejercicio bastante simple. Simplemente vamos a imaginar que estamos en la fase de planificación de construir una aplicación web de pila completa. Podríamos usar cualquier aplicación como ejemplo, pero básicamente esto es lo que pasa en mi cabeza cada vez que tengo que pensar en una aplicación de demostración para construir. Así que vamos a cambiar a un editor de code y comenzar a planificar nuestra aplicación de lista de tareas en seudocódigo.

Muy bien, aquí está un plan.

Y podríamos elegir cualquier tipo de sintaxis que queramos.

Y voy a inventar un seudocódigo similar a JavaScript o JSON o algo así.

Entonces, vamos a definir 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 necesitamos tener en cuenta?

Y supongo que lo primero obvio es un título. Podemos llamarlo aplicación de lista de tareas. Muy imaginativo.

Y lo siguiente podría ser, ya que es una aplicación de lista de tareas, necesitamos definir algunos modelos de base de datos, ¿verdad? Vamos a definir un modelo llamado tarea. Y los modelos generalmente tienen un ID, y lo haremos un número entero. Y una tarea de lista de tareas tendrá algún tipo de descripción, ¿verdad? Como cortar el césped, hacer la colada. Así que 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.

De acuerdo. Ahora que eso está fuera del camino, hagamos también el modelo de usuario. Y, por supuesto, también daremos un ID, número entero, y mantengámoslo simple. Haremos una propiedad llamada tareas, que es una matriz de tareas relacionadas que han definido.

De acuerdo. Y como esto es para una aplicación de pila completa, necesitamos definir algunos puntos finales para nuestras tareas, ¿verdad? Llamaremos a eso puntos finales de tarea. Y sí, esta es una aplicación simple. Así que básicamente necesitamos nuestros puntos finales CRUD esenciales. Tenemos, ya sabes, obtener todo o buscar todo. Queremos crear una tarea y tal vez queramos actualizar una tarea, ¿verdad? Genial. También debemos 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 importaremos una página de React allí y la llamaremos main page.tsx.

Y tal vez podemos darle la raíz de, digamos, raíz del cliente. Y esa será la raíz del cliente. Y luego queremos autenticar a las personas, ¿verdad? Queremos autenticar a los usuarios para que sus tareas estén asociadas con ese usuario. Así que vamos a seguir adelante, y como esta es una demostración dirigida a los desarrolladores, digamos que queremos autenticación social de GitHub. Esa es la única autenticación que queremos. Muy bien, genial. Así que aquí tenemos un plan bastante simple para una aplicación escrito en este pseudocódigo. Y lo que me gustaría señalar es, ¿qué tan genial sería esto si en realidad estuviera funcionando? ¿Qué tal si pudiéramos definir realmente las cosas de esta manera, como la autenticación, por ejemplo, y obtener autenticación de GitHub de pila completa, ¿verdad? Se generarían componentes de cliente para nosotros, como el botón de autenticación de GitHub, el botón de inicio de sesión, las funciones del servidor que necesitamos para autenticar a los usuarios en el servidor e incluso los modelos de base de datos.

Bueno, resulta que realmente podemos hacer esto, y lo hemos hecho. Esto es lo que hemos logrado con Wasp. Y esto es cómo se ve realmente la aplicación de tareas que acabamos de describir con Wasp. 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, es posible que estés pensando, oh no, aquí hay otro marco que tenemos que aprender, un montón de nuevas tecnologías nuevamente. ¿Por qué no puedes dejar lo que no está roto en paz? Pero el objetivo de Wasp no es realmente reinventar la rueda aquí, solo mejorarla, como dice Dwight.

Ya tenemos algunas tecnologías de desarrollo web realmente excelentes a nuestra disposición, como React, Node.js y Prisma. Y estas son exactamente las tecnologías que Wasp aprovecha en su marco. Por lo tanto, el DSL de Wasp simplemente actúa como el pegamento que une todo esto de una manera más eficiente. Junto con tu lógica de negocio de React, Node.js y 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 el proyecto completo, el frontend, el backend y el código de implementación para nosotros. Por lo tanto, obtienes una aplicación completa y lista para producción con autenticación de pila completa, rutas de cliente, un servidor independiente de Express.js, una base de datos Postgres, trabajos cron y muchas otras cosas. En el futuro, incluso planeamos admitir diferentes pilas y diferentes arquitecturas. Antes de explicar más sobre Wasp, volvamos a los DSL y hablemos un poco más sobre ellos. Entonces, si pensamos en nuestro pequeño ejemplo de planificación y el pseudocódigo que escribimos, básicamente estábamos inventando nuestro propio lenguaje allí. Pero este es un tipo de lenguaje muy, muy específico.

No puedes usarlo para hacer todas las cosas que un lenguaje de propósito general como C o 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, aunque. Y como desarrolladores, ya estamos familiarizados con bastantes de ellos. Probablemente estés familiarizado con este chico malo aquí. Esto es regex y está verificando 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 un ORM como Prisma o SQLite, algo así. Pero todavía está con nosotros después de todos estos años, al igual que nuestro buen amigo, Keanu. Así que SQL es un DSL.

Otro ejemplo obvio del mundo de React es JSX, que también es un DSL. Bueno, hemos establecido qué es un DSL y que 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 todas esas cosas 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, puedes simplemente decir lo que quieres y sucede. Veamos cómo.

Aquí está nuestro ejemplo de regex de antes. Simplemente decimos lo que queremos aquí. No nos importa realmente cómo se valida o en qué orden, cuáles son los mecanismos. Simplemente decimos lo que queremos y obtenemos el resultado que buscamos. Entonces, si no estuviéramos usando regex en este caso, y en su lugar simplemente 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 verificació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. Así que 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 mayor velocidad, lo cual es bastante asombroso. Puede empacar 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 esto con un ejemplo más complejo, ¿verdad? JSX nos está ahorrando tener que especificar exactamente cómo deben suceder las cosas. Pero, ¿por qué necesitamos un DSL para el desarrollo web? Quiero decir, ya tenemos un montón de bibliotecas, muchos marcos que pueden hacer todo esto sin un DSL ya.

¿Realmente, realmente necesitamos esto? Además, es posible que estés pensando que el próximo año, la IA se encargará de todo ese código repetitivo 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 el desarrollo web, parece que se está volviendo más complicado en lugar de más fácil, ¿verdad? Este es un sentimiento que los desarrolladores expresan con bastante frecuencia. Así que hay mucho que aún se puede hacer.

Entonces, ¿por qué los DSL podrían ser la posible solución a todo este desorden en el desarrollo web? Veamos tres razones por las que. 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 nuevamente al dominio, 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 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 repetitivo, pero teniendo IA que genere la mayor parte de él. Así que 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 sean actualmente pasados por alto. Podríamos decir que un buen DSL es una abstracción ideal para la IA, pero eso no captura la imagen más grande, en realidad. El punto es que lo que beneficia a los humanos también beneficia a la IA. Por lo tanto, la tercera razón se podría expresar de la siguiente manera. Permite tanto a las personas como a la IA utilizar abstracciones de nivel superior y requiere que tengan menos conocimiento experto. ¿Por qué? Porque este conocimiento experto está integrado 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 la IA.

Como ejemplo, imaginemos una aplicación de pila completa generada en JavaScript frente a un DSL. El code del DSL para la autenticación se vería algo así, o en realidad así, porque este es el code real de autenticación de WASP. Por otro lado, el código repetitivo de ExpressJS para autenticar a un usuario se vería algo así. Y parece obvio cuál sería más fácil de escribir, debug, mantener, independientemente de si es IA o humano. En resumen, 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 utilizamos para implementarlas cambian continuamente. Por lo tanto, el espacio de soluciones está cambiando bastante rápido, pero el espacio del problema no lo está haciendo. Todo esto hace que el desarrollo web sea un candidato perfecto para utilizar un DSL. Y eso es exactamente lo que resuelve WASP.

Nos ahorra tanto 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 aplicaciones web de pila completa relativamente nuevoframework para React, Node.js y Prisma. Y ya hemos acumulado más de 14,000 estrellas en nuestros dos principales repositorios de código abierto. Y puedes ver el historial de estrellas aquí. Mucho ha sucedido recientemente, pero de todas formas, hemos tenido más de 40,000 aplicaciones creadas utilizando WASP y muchos usuarios satisfechos que se unen a Discord y otros lugares, donde dejan testimonios como este, donde destacaré esta parte, donde este 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 abarca la mayoría de las tareas de ingeniería de pila completa es pura genialidad. Así que ves a un usuario darse cuenta de que esta capacidad de decir qué en lugar de cómo es realmente poderosa. Así que volvamos ahora a esa aplicación de lista de tareas que comenzamos a imaginar y mostremos algunas de las fortalezas de un DSL en acción.

Muy bien. Aquí verás que en el plan, si vuelvo rápidamente o cambio entre el archivo de configuración de WASP y el plan, notarás muchas similitudes allí. Así que eso fue intencional. Deliberadamente escribí el pseudocódigo de una manera similar a WASP para que entiendas la idea de 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. Tenemos esa ruta del cliente allí. 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. Y simplemente hemos indicado que queremos operaciones de obtener todo, crear, actualizar y eliminar. Por lo tanto, siempre estarán asociadas a la entidad de la tarea. Y en realidad no tenemos que escribir ningún código de backend porque esto se encargará de todo por nosotros. Además de eso, tenemos nuestras rutas de manera similar a como se hizo en el plan o el pseudocódigo. Pero también podemos hacer otras cosas, como decir que queremos que esto sea... Solo los usuarios autenticados pueden acceder a esta ruta, ¿verdad? A esta ruta. Por lo tanto, esto también se encargará de la autenticación del lado del cliente. Genial. Cambiemos ahora al navegador 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 definir la autenticación de GitHub.

Así que tenemos el botón de autenticación de GitHub allí. Pero tal vez quiero hacer un cambio. Tal vez quiero agregar un método simple de inicio de sesión con nombre de usuario y contraseña. Y una vez que la aplicación se recompila, deberíamos ver en el frontend aparecer el formulario de inicio de sesión. Y ahí vamos.

Lo tenemos. Quiero decir, ya he iniciado sesión. Así que simplemente voy a 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 persistiendo en una database y pasando por el servidor Express.js, cambiemos al Database Studio. Y ahí vamos. Correcto. Así que si actualizo eso, podemos ver 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. Así que genial.

Eso es básicamente cómo funciona Wasp en pocas palabras. Y puedes hacer mucho más. Tienes trabajos programados. Tienes seguridad de tipo de pila completa. Y también tienes envío de correos electrónicos. Y todas estas cosas se encargan a través del archivo de configuración y del DSL en Wasp. Otra cosa realmente genial que podemos hacer, porque tenemos este archivo de configuración y este DSL, es que Wasp comprende toda tu aplicación. Y tenemos una pequeña característica experimental como esta, donde realmente tenemos una visualización de toda la aplicación. Y esto es solo el comienzo, porque puedes hacer muchas cosas con cosas como esta. Pero esto te muestra el poder, una vez más, de los DSL para hacer cosas interesantes. Así que aquí puedes ver toda la aplicación desde el backend hasta las rutas y páginas. Y puedes ver, ¿verdad?, que la página principal está autenticada.

La aplicación utiliza una base de datos SQLite en lugar de Postgres, que también podrías usar. Y tiene autenticación de GitHub y entidades de usuario y tarea. Así que eso es una característica bastante genial y agradable 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. Y esos son OpenSaaS y Mage. OpenSaaS es una plantilla de SaaS de código abierto lista para producción y completamente gratuita, mientras que Mage es un agente de IA que generará un prototipo de aplicación de pila completa basado en una indicación simple.

Como dije, OpenSaaS es una plantilla de SaaS de código abierto y gratuita. Está a la altura de algunos de esos boilerplates de SaaS pagados que probablemente hayas visto. Viene con suscripciones de Stripe, panel de administración, Plausible o Google Analytics, carga de archivos en AWS S3, ejemplos de API de OpenAI. Además, está completamente documentado y brindamos soporte para cualquier pregunta y usuarios en nuestro Discord. Así que eso es realmente genial. Si estás interesado en eso y quieres construir un SaaS.

Por otro lado, Mage 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. Si quieres probar UseMage, visita usemage.ai y te proporcionará un archivo zip de la base de código que puedes descargar y probar localmente.

O si tienes Wasp instalado o lo instalas, simplemente ejecuta el comando wasp new y puedes elegir entre estas plantillas de inicio. Y OpenSaaS y Mage, también conocido como AI Generated aquí, están incluidos. Así que esa es otra forma genial de acceder a estas plantillas. 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.