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.
Comments