Usando Nitro - Construyendo una Aplicación con el Último Motor de Renderizado de Nuxt

Entonces... Genial. Simplemente me lanzaré de lleno, y yo... Veamos. Me destacaré a mí mismo para que puedas ver mi pantalla. Vamos a crear una nueva aplicación Nox desde cero. Entonces... Solo voy a... Parece que lo he hecho por accidente en segundo plano. Vamos a entrar en otra carpeta, y crear una nueva aplicación, a la que llamaremos Nox Reworkshop. Así que esto está utilizando la nueva Noxie CLI, que es la Nox CLI. Bueno, ¿está desenfocado para todos? Ahí lo tienes. ¡Sí! La resolución de tu pantalla de video es un poco... Sí....un poco mejor. Ahí lo tienes. ¿Podemos ajustar la resolución de nuestras propias pantallas de Zoom en algún lugar? Porque no lo encontré de inmediato. Es mejor, pero todavía está interpolado. Creo que normalmente, si cambias la resolución de tu pantalla, se soluciona el problema. Veamos. Lo cambiaré a HD en Zoom. ¿Eso ha hecho alguna diferencia para alguien más? Todavía no. ¿No realmente? Veré si puedo cambiar realmente la resolución de mi pantalla, tal vez eso podría marcar la diferencia para ustedes. Configuraciones de filmación. ¿Se siente mejor para la gente? Quiero decir, es perfectamente legible, creo que deberíamos seguir adelante, porque probablemente sean las conexiones de red locales de las personas y Zoom, etc. Bueno, genial. Si hay algo que pueda hacer para mejorar las cosas, ¡solo dilo! Así que he abierto una carpeta en lo que hemos llamado Nitro Workshop, y vamos a abrir eso ahora.

Y un nuevo proyecto NUXT va a tener muy poco en su lugar. Así que solo va a tener un archivo App.Vue y una configuración NUXT, y habrá una configuración TS que hará algo de magia para nosotros también. Probablemente no necesitamos hacer ningún cambio en la configuración TS aquí.

El app.vue es el reemplazo. No existe en NUXT 2. Y soy consciente de que hay algunas personas aquí que no han usado NUXT 2. Así que explicaré lo que hace. Este es tu punto de entrada a tu aplicación. Si lo borras, está bien. Habrá uno básico que existirá que NUXT usará para ti.

Solo crearé un pequeño repositorio. Todavía es ilegible para muchas de las personas. Empeoró aún más. Es extraordinario. Eso es muy, muy borroso. Tal vez si también desactivas tu cámara, ¿tal vez el upstream no lo maneja realmente? Sí, Daniel, te enviaré una captura de pantalla por Twitter para que puedas ver. Podrías asegurarte de que tus descargas de BitTorrent estén en pausa. ¿Alguien está viendo esto correctamente? ¿O absolutamente todos lo encuentran borroso? Muy, muy borroso. Bueno, vamos a entrar en una rápida solución de problemas. No sé si desactivar todas nuestras cámaras puede ayudar. Pero eso sería cierto, creo, si el problema es realmente el—¿qué tal si probamos esto? Ignoremos mi cámara. Y simplemente compartamos mi pantalla a ver si eso hace alguna diferencia. Podría ayudar un poco. Bueno, ahora verán. Ooh, ahora estamos hablando. Ahora sí, genial. Ahora está muy nítido. Ahora estamos hablando, sí. Genial. Bueno, eso funcionará para nosotros. Puedes alejar un poco si quieres.

Bueno. Ahí vamos. Problema de edad. Entonces, bueno. Y solo— Ni OBS. Bueno, aquí estamos. Primero Daniel, para interrumpirte, lo siento mucho. ¿Puedo preguntarte si se supone que debemos seguir el code? No tienes que seguir el code en absoluto. Así que lo que vamos a hacer es que estoy a punto de crear un repositorio Git, y lo subiré a GitHub para que puedas ver lo que hacemos a medida que lo hacemos. Si eso te es útil. Sí, eso sería genial. Exactamente. Bueno, vamos a llamar a esto Nitro Masterclass. Lo siento, tengo una pequeña sugerencia. ¿Podrías simplemente por primera vez revisar la estructura de este proyecto? ¿Puedo hacer qué? Sí, genial. Bueno, deberías poder ver eso. Así que tienes un pequeño repositorio aquí. La estructura es realmente muy simple. Esto es lo que obtendrías si ejecutaras Nuxty init y lo llevaras a un directorio. Así que si encuentras tu app.vue, que es tu punto de entrada a tu aplicación Nuxt, simplemente iniciaremos el servidor de desarrollo. Así que será simplemente localhost 3000. Y vamos allá. Verás que hay este componente de bienvenida. Por cierto, si alguna vez estás jugando con Nuxt, encontrarás que esto no funciona en producción, deliberadamente. No queremos que accidentalmente termine en tu paquete de producción. Así que si quieres desplegar una pequeña aplicación y probarla, por favor cambia el componente de bienvenida de Nuxt y reemplázalo con algo más o pensarás que las cosas no están funcionando. Así que si hacemos eso, diremos que esta es mi aplicación. Verás que se actualiza de inmediato. Así que eso es con lo que estamos trabajando hoy. Hay algunos otros directorios mágicos que existen. Así que la configuración RTS, me encanta TypeSupport así que no te voy a decir cómo funciona todo. Extendemos un tipo generado, la configuración RTS que existe dentro de este directorio dotnuxt. La mayoría de las cosas, por cierto, que habrías visto en el directorio de construcción NUXT 2 simplemente no existen en NUXT 3. Todos están en memoria, lo que significa que pueden ser super rápidos. Y significa que pueden ser actualizados de diferentes maneras, también. Así que las únicas cosas que tenemos aquí son algunas declaraciones de tipo, una plantilla de documento, que realmente no va a cambiar. Eso solo va a ser una estructura básica de tu HTML, un servidor Nitro. Esto se va a recompilar cada vez que cambiemos algo en el lado del servidor.

Pero lo que sí tenemos es esta configuración TS que contiene, por ejemplo, rutas resueltas para todos los alias de Nuxt. Así que si estabas usando alias de Nuxt antes, tendrías que haber añadido estos a tu configuración TS, mientras que ahora todo esto se hace por ti. Y si estás usando modules que añaden sus propios alias, esto se actualizará automáticamente para eso. También extraemos tipos para todos los modules que usas en tu aplicación. Y generamos tipos para cosas como las importaciones automáticas que proporcionamos. Estas son funciones de ayuda y le estamos diciendo a TypeScript que estas están disponibles globalmente. Así que cuando estoy escribiendo en mi aplicación, puedo simplemente usarlas. Están allí y disponibles para mí y esto es realmente cierto. Así que no tengo que importarlas. Están allí para mí. Así que si quisiera, por ejemplo, ver cuál es mi configuración en tiempo de ejecución, puedo simplemente mostrarla así y verás que esa es mi configuración en tiempo de ejecución para mi aplicación. Puedo explicar un poco más sobre lo que es la configuración en tiempo de ejecución si eso sería útil para la gente. Pero ahora mismo sólo quiero mostrarte que puedes acceder a estas importaciones automáticas en cualquier parte de tu aplicación.

En términos de otras carpetas mágicas, tenemos una página, podemos crear una carpeta de páginas. Podemos crear una carpeta de plugins y podemos crear una carpeta de servidor. Hay otras también en las que podríamos profundizar. Voy a crear una carpeta de servidor porque es probablemente donde va a ocurrir la mayoría de nuestro NitroMagic hoy. Y he creado una subcarpeta dentro de ella llamada API. Y vamos a crear un pequeño punto final de chequeo de health para el servidor que vamos a crear.

Ahora, Nuxt 3. Ahora, la mayoría de las cosas que escuchas sobre Nuxt 3 y la mayoría del enfoque es, por supuesto, en el front end. Esa es la parte de vista, después de todo. Pero mucho de lo que es diferente acerca de Nuxt 3 viene del back end, el Nitro, la cama del servidor de la que estamos hablando hoy. Y así que nosotros... Por lo tanto... Pasaremos algún tiempo en eso. Así que tenemos aquí un pequeño punto final que devolverá el estado OK. Y si creo otra terminal y la arrastro, eso simplemente se convertirá automáticamente en API health, y obtenemos una respuesta. Así que un punto final bastante útil. ¿Qué está pasando aquí? Normalmente, si escribieras esto en una API de nodo, como la que estás usando todo el tiempo, ward supongo, tendrías un objeto de solicitud y respuesta. Y harías algo como console resultados igual a estado. OK, res y JSON, stringify, salt. Y probablemente también establecerías algunos encabezados, tipo de aplicación, JSON. Y eso también funcionará para nosotros. Así que si dijéramos, hazlo un poco diferente. Eso va a funcionar bien también. Ese es tu manejador de tipo de middleware de nodo Express normal. Pero básicamente, es mucho más simple hacer eso. Y así lo hacemos automáticamente para cualquiera de nuestros servidores. Así que esos puntos de entrada son rutas de API, y todo eso está alimentado por un paquete llamado H3, que básicamente maneja automáticamente el paso de respuestas de cadena de caracteres desde estos puntos finales. Tenemos algo similar en el otro extremo también. Así que cuando obtienes una. Una respuesta. Así que si íbamos a decir, echemos un vistazo a nuestro. Si normalmente ibas a buscar, buscarías desde localhost 3000. Digamos, y tus resultados, probablemente necesitarías hacer algo como un JSON. Y entonces vas a tener un resultado. Y podríamos hacerlo aparecer y mostrarlo en nuestro Bobby. Pero eso va a parecer algo como. Ah, no puedo leerlo por la razón que sea. Está bien porque este es un punto de entrada interno. Y esto es realmente lo que espero usar. Un externo real. Ella podría simplemente mostrarte lo que pasa. Si hacemos esto. Obtenemos un valor de marcador de posición allí. Ahora, cuando usamos una función que proporcionamos con next three, que es el signo de dólar fetch. Por cierto, esto es algo que puedes usar en un proyecto no next three también. Simplemente puedes importarlo de un paquete llamado Oh my fetch, que funcionará de la misma manera en cualquier aplicación. Esto realmente pasará automáticamente JSON para nosotros. Así que podemos simplemente cambiar eso. Y en este caso, deberíamos encontrar exactamente el mismo resultado que está sucediendo. Podríamos decir que es un objeto JSON completamente válido. Y cuando estábamos justo para tu propia comodidad, probablemente podrías permitirte alejarte un poco más porque en realidad la pantalla es super clara.

No parece muy bueno. Intentemos interpolar la cadena. No hace nada útil para nosotros. Bueno, esa es una función bastante útil. Así que básicamente está coincidiendo con cualquier patrón, como ese. Y se ha dado cuenta de que tengo una URL base allí, y entonces va a básicamente colocarlas con una variable de entorno. Así que si tienes una cadena que es un poco como URL base, la va a reemplazar con una variable de entorno.

De todos modos, el copiloto es bastante genial. Así que es bueno para nosotros averiguar lo que estás haciendo. Así que probablemente vamos a tener este token mágico. Probablemente sea algo privado. Va a ser algo que es solo realmente visible para nosotros en nuestro servidor. No queremos que esto llegue al cliente de ninguna manera. Así que vamos a decir que el token va a ser proceso y comienzo del token mágico. Creo que así es como lo llamé. Y vamos a tener quizás alguna configuración de tiempo de ejecución pública para ayudarnos, la información pública es, hola, leyendo mi fuente.

Y lo que encontrarás es que si, en nuestra app.view, volvemos a traer esa configuración de tiempo de ejecución, y la cargamos en el lado del servidor, en realidad vamos a tener un error. Te diré por qué tenemos un error. Encontrarás que si saco mis herramientas de desarrollo, hay un problema aquí. Lo explicaré en un momento. Pero primero voy a apagar mi JavaScript, y puedes ver qué HTML renderizado del servidor tenemos. Tenemos nuestro token secreto renderizado, y también tenemos toda la otra configuración de tiempo de ejecución, que Nuxt inserta en la configuración. Ahora, ese token no está disponible en el lado del cliente, así que aunque está en el HTML, porque he cometido el error tonto de simplemente ejecutarlo renderizando el token en el HTML, no va a poder coincidir en el lado del cliente porque el cliente no tiene acceso a ese token.

Si estuviéramos mirando el HTML, lo voy a pegar en VSCode para que puedas verlo un poco mejor. Si estás mirando el HTML, puedes ver que establecemos esta variable window.nuxt a varias cosas, incluyendo, puedes ver, la configuración. Así es como la pasamos del servidor al lado del cliente. Y no tiene el token. Así que cuando vuelvo a encender JavaScript, lo que sucede es que el HTML viene del servidor, no coincide con nada del lado del cliente, así que tenemos que reiniciar, empezar de nuevo. Este es uno de los mayores desafíos que la gente encuentra cuando pasan de construir solo aplicaciones del lado del cliente en Vue a construir algo que es isomórfico, que se renderiza tanto en el servidor como en el lado del cliente. Tienen que asegurarse de que el estado que renderiza el componente es exactamente el mismo en ambos lados donde obtienes problemas como este.

En este caso, realmente, realmente no queremos pasar el token al lado del cliente. Así que en su lugar, lo que probablemente quieras hacer es hacer algo con una cosa particular dentro de él en lugar de simplemente exportar todo. Queremos información pública, probablemente. Así que podemos decir, config.publicinfo. Y voilà. Todo funciona bien ahora. Pero es posible que quieras usar ese token en el lado del servidor. Y así puedes hacerlo. Así que podrías usarlo para hacer algún tipo de solicitud de búsqueda, por ejemplo. Particularmente, hoy, vamos a pegar eso en un middleware de API. Así que vamos a decir que vamos a crear un recurso. Así que vamos a llamar a nuestro recurso notas. Y vamos a listarlas todas en un archivo de índice. Así que vamos a devolver una lista de notas. Van a ser la una, título, nota uno. Aquí es donde gethebcopilot es perfecto. Así que tenemos algunas notas ahora. Y probablemente vamos a querer iterar sobre ellas.

¿Qué vamos a hacer con la configuración? En el lado del servidor, en el lado de Nitro, tenemos una importación un poco diferente. Así que ahora usamos la configuración de tiempo de ejecución, en realidad podemos importar la configuración directamente de algo llamado hash config. Que necesito escribir, eso se escribirá en un PR en los próximos días. Pero lo que tenemos aquí es, ahora tenemos un tipo Sí, puedes verlo en el console, eso es la configuración que tenemos. Y eso significa que puedes usarlo en tu, y tu aplicación Nitro, puedes tener acceso completo a esa configuración en lugar de intentar acceder a process.env. Y podrías decir, ¿por qué, Daniel, hacemos esto? ¿Por qué tienes que importarlo en lugar de simplemente acceder a la variable de entorno del proceso como normalmente lo harías? Y la respuesta es que el servidor Nitro no necesariamente se está ejecutando en un entorno Node. Podría estar ejecutándose en un entorno Node, pero también podría estar ejecutándose en un navegador o en un trabajador de CloudFlow, o podría estar ejecutándose en dno o algo más. Y tenemos que tener una forma de controlar eso. Así que en lugar de usar funciones o utilidades de Node que normalmente usarías, donde estás accediendo a un proceso directamente, es preferible si puedes usar una abstracción. Insertamos polyfills para cosas como el proceso. Si resulta que estás usando una dependencia que lo está usando, o tienes alguna otra llamada para usar objetos Node tú mismo. Pero es preferible si puedes importarlos de esta manera.

Hola Daniel. Lo siento. ¿Cómo difiere esta configuración de hash del normal.env? Hay algunas... Muy buena pregunta. De hecho, hacemos algunas interpolaciones, por ejemplo. Encontrarás que si tengo un token mágico aquí, Y luego hago algo como URL firmada igual a my API.com token igual a token mágico. Entonces lo que debería encontrar es que si yo fuera a usar... Que ahora deberíamos tener una cadena interpolada. Así que tenemos la URL firmada es...

Hemos referenciado una variable de entorno dentro de otra variable de entorno. Eso es algo que puedes hacer con la configuración en tiempo de ejecución pública. No puedes hacerlo solo accediendo a process.env. Este modelo, imagina que dijiste habilitar middleware. Si solo fueras a registrar el process.env de eso, va a ser una cadena igual a verdadero, lo cual siempre es una trampa, un arma de fuego para muchas personas porque si process.env.enableMiddleware. hacer X, Y, y Z. De hecho, podría estar configurado en falso, que también es verdadero, como una cadena. Mientras que, de hecho, si dijéramos algo como eso aquí. El copiloto me está ayudando con mucho cuidado queriendo probar si es igual a verdadero la cadena. Pero en este caso, solo voy a decir enableMiddleware. Y lo que va a pasar, pero ahora tenemos un valor booleano. Así que hay muchas cosas útiles que la configuración en tiempo de ejecución te permite hacer. No menos importante, y aquí está otra diferencia clave, podría hacer muy poca diferencia cuando se trata del servidor. Porque podemos, después de todo, hacer algo como... podemos acceder directamente al proces.env. Creo que podríamos afectar esto un poco con rollup. Vamos a confirmar. Solo voy a convertir ese valor en cadena. Y eso está causando claramente algún tipo de error. Así que claramente, no puedo convertir ese valor en cadena. Pero podría no ser tan diferente en el lado del servidor, pero es muy diferente en el lado del cliente. Así que normalmente en una aplicación Vue, no tienes acceso a process.inf. Tal vez lo haces cuando lo estás renderizando en el servidor. También podrías no tenerlo porque es un contexto de webpack o Vite. Y así runtime.config significa que podemos entregar una experiencia de configuración isomórfica igual entre el servidor y el lado del cliente. En ambos casos, tienes acceso a la configuración. Y recuerda en el lado del cliente, estamos analizando eso al cliente a través de este objeto window.nuxt. Y así es como obtiene todas las variables de entorno a las que queríamos tener acceso. Puedes tener más preguntas para seguir con eso. Vuelve a mí. Está bien. Gracias. Bryl. Sí, así que Nuxt está agregando capas de abstracción para ambos contextos, navegador y servidor, para la configuración. Y hay algunas cosas útiles en las que ni siquiera he entrado, que podríamos cubrir en algún momento.

Voy a cubrir otra capa de abstracción que creo que te parecerá realmente interesante. Al menos, a mí me parece realmente interesante. Y esta es realmente canalizada. Tenemos algo llamado almacenamiento. Es una importación especial que solo funciona en Nitro. Así que, solo en el middleware del servidor real, rutas API y puntos finales. Y lo que tenemos es solo una única exportación llamada almacenamiento. Y podemos hacer algunas cosas realmente interesantes allí.

Así que, voy a sacar esto. Así que, tengo un poco más de cosas aquí. Y. Así que, nuestro objeto de almacenamiento, podemos hacer varias cosas con él. Así que, ves que tiene cosas como obtener claves, obtener elementos, obtener meta montar, mover elementos, establecer meta, establecer elementos. Y lo que es, es como una capa de abstracción de database que te permite leer y escribir en cadena, a claves, que son cadenas, efectivamente. Y admite varios puntos finales diferentes, cosas como caché en memoria o acceso al sistema de archivos, o tenemos otros controladores también, como, por ejemplo, Redis.

Así que, pensé que podría ser interesante mostrarte cómo puedes configurarlo con Redis. Voy a crear un archivo de middleware, y simplemente lo llamaremos db. Ahora, el middleware es similar a una raíz API, excepto que no tiene ninguna coincidencia. No se ejecuta solo en ciertas raíces, se ejecuta en todas ellas. Así que, si fuera a crear un middleware aquí, y pasamos un objeto de solicitud, y simplemente voy a registrar la URL. Eso va a registrar esa URL cada vez que haga algo en absoluto. Así que, si fuera a abrir mi terminal ahora, y simplemente tiro quizás una URL que no existe, vamos a encontrar algún tipo de error, por alguna razón.

¿Qué está pasando aquí? Este error ha ocurrido más de una vez. Solo voy a tomar un pequeño desvío, porque claramente es algún tipo de problema. Está relacionado con el mapa de origen. Podría ser algo relacionado con el mapa de origen. Veamos si podemos... He hecho algo más estúpido en algún lugar. Claramente lo había hecho. Así que estamos llamando a una página inexistente aquí, testing. Está siendo renderizada por App.vue porque no tenemos ninguna configuración de enrutamiento a nivel de página. Y nuestro middleware se está ejecutando en esa raíz. Así que aquí es donde vamos a configurar nuestra database. Vamos a traer el almacenamiento. Y vamos a montar un controlador en él. Y va a montar algo que es, por cierto, esto utiliza una biblioteca llamada unstorage. Así que puedes usar esto en cualquier lugar, no solo en Nuxt. Así que vamos a montar en almacenamiento, podemos dar un prefijo, así que podríamos hacer algo como que vamos a montar solo en Redis, algo así. Porque esa sería nuestra clave que comienza con Redis, va a este controlador. Podríamos tener fs que sería si quisiéramos montar un controlador de sistema de archivos específicamente en el sistema de archivos. Pero en este caso, solo vamos a montarlo para que todo sea manejado por este controlador, así que solo vamos a pasar una cadena de longitud cero. Y vamos a crear un nuevo controlador. Daniel, ¿a qué te refieres con montar? De lo que estamos hablando es si tienes un... piensa en un sistema de archivos. Y si tienes experiencia en Linux, entonces eso hará una diferencia. Si no la tienes, entonces este puede ser un ejemplo no útil. Pero si tienes una especie de árbol anidado de directorios, así que tienes tu servidor y tienes tu servidor, carpeta API del servidor y tienes tu carpeta de notas API del servidor. Y luego tienes otra carpeta llamada Páginas. Y podría tener algo más de contenido. Cuando dices cuando montas algo en una carpeta, básicamente estás diciendo que este controlador va a manejar todas las solicitudes que van a esa carpeta.

Así que en Linux podrías montar una unidad en una carpeta. Y lo que significa es que entonces, aunque parezcan hermanos en el mismo directorio, las cosas que comienzan con servidor van a ser manejadas por esa unidad. Así que si estás en un entorno Linux o Unix, si fueras a ejecutar el comando mount, verías que, en este caso, parece que tengo un par de discos diferentes, y cada uno de ellos tiene algunas particiones en él. Y están montados en estos diferentes directorios. Así que si voy a volúmenes del sistema actualizar en realidad va a abrir esa partición. Los volúmenes del sistema preboot van a abrir esta partición, que es una completamente diferente. Una parte diferente de la unidad. Si voy a este volumen, va a abrir un disco completamente diferente. Pero está abstraído de manera que en mi computadora cuando veo estos directorios uno al lado del otro no tengo que preocuparme de dónde vienen. Solo tengo que preocuparme de escribir y leer contenido de ellos. Lo mismo es cierto con unstorage. Si tienes una clave que comienza con, si la monto, por ejemplo, en meta, entonces piensa en ella como una carpeta. Así que todo dentro de esa carpeta meta va a ser manejado por cualquier controlador que yo analice aquí. Todo lo demás será manejado por quizás un controlador diferente, el predeterminado, que está en memoria. Puede que no lo haya dejado muy claro. ¿Es eso útil? Sí, genial. Rutas virtuales. Exactamente. Ahora, mira, ahí tienes. Así que en este caso, vamos a crear un controlador de Redis y lo vamos a sacar de los controladores de unstorage. Y dije que teníamos un par de diferentes aquí.

Vamos a importar directamente el de Reader. Vamos a montar el controlador de Reader, creo. Elegir algunas opciones. Así que tenemos una base, que puede ser nada y luego una URL, que usaremos. Digamos... Usaremos nuestra configuración, así que va a ser config.reader'surl. Y configurémoslo. Eso solo se va a usar en el servidor, así que lo vamos a poner aquí. Solo lo voy a codificar por el momento. Probablemente necesitaremos configurar esto. Así que, solo voy a crear un archivo docker-compose. E importar un... Siempre tengo que recordarme la sintaxis de estas cosas. Todos lo hacen. Esto es... Un archivo docker-compose que construí para otra cosa. Veamos qué dice allí. OK. Es un archivo docker-compose de Laravel. No... No necesita ser casi tan complejo. Solo tienes que tener un servicio realmente. Lo llamaremos... Y usaremos VDIS más reciente. Y estoy bastante seguro de que solo necesitamos un mapeo de puerto. Así que es solo 6379. Eso debería ser todo, ¿verdad? ¿Me estoy olvidando de algo, alguien? Y quiero menos sangría. Así que si ejecuto Docker compose up... Parece que está funcionando, bien. Así que ahora lo que quiero ser capaz de hacer es realmente hacer algo de lectura y escritura a eso. ¿Necesitas hacer algún compromiso? Oh, probablemente, si te gustaría ver lo que ha pasado hasta ahora. Cerramos ese directorio, no se está utilizando. Así que esto está en progreso, ¿verdad? Así que probablemente ni siquiera va a funcionar. Y voy a comprometer mi archivo .env. Y no sé, GitHub probablemente me enviará un correo electrónico urgente diciendo, cuidado, cuidado, se ha comprometido un token mágico al archivo fuente. Pero hey, si ayuda a alguien, si estás siguiendo, y quieres ver el code, deberías poder verlo en Daniel Rowe Nitro masterclass. Solo prueba que existe. Parece estar allí. ¿Alguien más? Genial. Bueno, ¿dónde estamos ahora? Estamos creando este redistribuidor. Así que supongo que queremos probar si las cosas están funcionando. Estoy un poco nervioso por este extraño error que he estado obteniendo hasta ahora. Necesitamos arreglar eso sea lo que sea. Parece estar bien, no hay errores locos hasta ahora. Así que intentemos hacer algo con eso. Así que, ¿qué tal en esta carpeta de notas, si obtenemos una nota publicada, entonces la guardaremos en la database. Y si, no puedo soportar cosas que no están tipadas. Bueno, vamos a decir que nuestro método solo va a ser igual a este método, y luego tal vez vamos a hacer algún tipo de cambio en eso. Oh, esto es super agradable. Bueno, vamos a manejar la obtención, y luego tal vez una publicación, solo por ahora. En caso de obtener, entonces probablemente solo mostraremos todas las notas, y la publicación probablemente debería guardarla. Así que, solo devolveremos un array vacío. Así que lo que vamos a querer hacer, obviamente, es acceder al cuerpo para empezar. Así que vamos a usar algo llamado use body, que es proporcionado por H3, que también está proporcionando estos puntos de entrada. Y hay muchas otras funciones útiles también. Así que puedes usar cookies, puedes... Hay algunas que son específicas para crear pequeñas sub aplicaciones como use base, o puedes usar query. Pero en este caso, solo queremos el cuerpo. Así que lo que vamos a decir es, voy a sacar el cuerpo de la solicitud. Y en realidad... Bueno... Digamos... ¿Qué vamos a hacer? Así que si hemos publicado, entonces vamos a querer... Almacenamiento. Establecer elemento. Y tal vez quieras algún tipo de ID, ¿verdad? Así que vamos a decir que tenemos una interfaz de elemento. Tiene que tener una ID. Y tal vez algo de texto. Tal vez un título. Y entonces vamos a esperar que nuestro cuerpo vaya a...

No tienes que usar este controlador particular que he seleccionado para Redis. Así que si miras unstorage, verás que hay una sección de cómo escribir un controlador. Así que realmente puedes crear el tuyo propio. Con cualquier database con la que estés trabajando, puedes hacerlo. Hay otro genial que solo quiero mencionar. Tenemos un controlador HTTP, que básicamente te permite utilizar otros puntos finales como tu database. Así que realmente puedes, digamos, tratarlo como una database de reemplazo como todo lo demás, pero va a hacer una solicitud get y solicitudes post para devolver elementos y guardarlos. Eso significa que puedes usarlo para interactuar con tus PIs existentes. Así que todo lo que necesitas hacer en tu extremo es enfocarte en los patterns comunes de interacción con el almacenamiento. Y de nuevo, puedes tener algo como todo lo que comienza con notas, tal vez, va a ser la database del lector. Y todo lo que comienza con algo más va a ser un tipo de cosa diferente. Así que, eso sería una estrategia perfectamente razonable.

Antes de profundizar más, ¿alguien tiene alguna pregunta hasta ahora? OK, una básica. El hash para las importaciones, ¿cuál es la diferencia cuando tenías el hash storage y no hash antes del onStorage? Entonces, lo que estamos haciendo con el hash es que esto es una importación virtual. Entonces, no existe como un archivo de Node modules. Es solo algo que se proporciona por Nitro en sí. Entonces, cuando esto se transforma en nuestro servidor, así que si vamos a profundizar en Nitro aquí y ver lo que sucede, solo diré, la montura de almacenamiento importa. Vamos a buscar eso y encontrar el code que se convierte en, oh, ahí vamos. Entonces estamos montando almacenamiento, ¿verdad? Pero el almacenamiento es en realidad esto, es de algo llamado createStorage, que es solo algo que, de todos modos, está todo en línea en el archivo. Básicamente es una forma de rollup, proporcionando algo que es creado por Nitro en sí al code que tienes en ejecución. Esa es la entrada hash, y básicamente eso, nunca te encontrarás con eso en un paquete npm real. Siempre va a ser una importación subpar que has proporcionado para ti mismo, o un alias a él que has aliasado a alguna otra carpeta o paquete existente, o una importación virtual como esta. Lo mismo es cierto para la configuración, excepto que no la he tipado correctamente. Y mientras que unstorage es en realidad un paquete que puedes descargar de npm, así que si miro en mi archivo yarn.lock, hay solo un paquete de unstorage. Y si fuera a entrar en Node modules, está allí, así que son solo archivos en el disco. En términos de por qué usarías algo como unstorage o algo como unplugin, sí, definitivamente deberías, Wod, eso sería increíble. Así que unplugin es muy diferente, a pesar del hecho de que hay un un en él. De hecho, hay toda esta organización de Github llamada unjs, y el objetivo es lanzar cosas a la community que son geniales, en las que estamos trabajando como parte del equipo de Nuxt, porque no queremos que sea solo para Nuxt. No se trata solo de... Podríamos mantener todos estos dentro del repositorio, pero preferiríamos lanzarlos en una forma utilizable para que las personas puedan usarlos en otros proyectos y contribuir de manera más general y beneficiar al ecosystem de código abierto, así que tiene muchas cosas realmente interesantes que creemos que son interesantes y no existen en otro lugar. Gran parte del enfoque es sobre la compatibilidad, asegurándose de que las cosas funcionen en muchas situaciones diferentes, así que por ejemplo, Unplugin te permite escribir transformar code que podrías usar en Vite, pero tener el mismo code utilizable en webpack o en rollup estándar. Así que si básicamente estás diciendo, cada vez que encuentro este patrón, solo quiero reescribirlo a otra cosa, tal vez estés usando regexps, es un dolor tener que hacer algo para interactuar con el formato de plugin de webpack y también crear un formato de plugin de rollup. Así que Unplugin tiene como objetivo hacerlo realmente simple para hacer eso. Así que puedes simplemente escribir code como este y eso funciona en todas partes. Así que tienes tus exportaciones de Vite, Rollup y Webpack. Eso es obviamente muy útil para nosotros con Nuxt 3 porque soportamos tanto Vite como Webpack. Así que esa es la motivación para nosotros originalmente escribir el code. Pero el objetivo es que cuando tienes estos diferentes empaquetadores y ecosistemas de bundler, y debería decir que estamos muy contentos de extender esto a otros también, si tienes Pasel o algo más, por favor, deja un PRN.

Porque muchas de estas cosas son realmente simples. Y si podemos tener un code que funcione en todas partes, eso es mucho mejor. Los otros son como Uninv, que es quizás uno de los más geniales. Uninv tiene como objetivo crear un solo entorno que funcione con el navegador y el nodo y en otras situaciones. Así que contiene muchas cosas útiles y potencia mucho del trabajo genial que estamos haciendo con Nitro y Nuxt. Así que tenemos cosas como, voy a convertir esto en una vista tipo VS code. Tienes cosas realmente útiles como presets, así que tenemos un preset de nodo y sin nodo. Probablemente son los dos con los que trabajaríamos más. Y contienen paquetes de algunas de las otras cosas que hemos producido. Así que un entorno de nodo va a querer proporcionar APIs de navegador a nodo. Y un entorno sin nodo probablemente va a querer proporcionar APIs de nodo al navegador. Y puedes... Básicamente contienen alias, inyecciones y polyfills. Y esos pueden ser consumidos de la manera que quieras consumirlos. Obviamente, los consumimos en Nitro, pero otros servidores o puntos de entrada podrían hacer lo mismo, o puedes usar solo las piezas componentes.

Así que aquí están algunas de las piezas componentes que proporcionamos. Por ejemplo, si quisiéramos sacar... Solo expandiendo algunas de las opciones aquí. Así que una cosa que hacemos en un entorno sin nodo, verás que tenemos una serie de cosas que se refieren a un mock. De hecho, no están en este sin nodo... No, aquí estamos, la variable arrayed. Así que estamos simulando todos los módulos integrados de nodo, cosas como fs y path. No existen en un navegador. No puedes simplemente traerlos. Quiero decir, hay algunas cosas, como Browserify y otros tienen reemplazos que están destinados a reescribirlos. ¿Qué haces si te encuentras con un import fs? Y estás en un navegador, hemos creado este proxy, que es un proxy universal. Este proxy no dará error sin importar lo que le hagas. Intenta hacer un error. Funcionará como una función. Funcionará como un valor. Funcionará como un... Tiene todas las propiedades que podrías querer obtener de él. Devuelve cadenas. Puede ser una clase. Puede ser lo que quieras. Lo principal es que no dará error. Así que básicamente puedes importar FS en un entorno de navegador. Y hagas lo que hagas, no hará nada. Pero tampoco fallará. Así que para eso es este proxy. Y también tenemos pequeñas entradas, como no op y empty, a las que puedes hacer alias si necesitas. Y lo hacemos. Así que, por ejemplo, en Nodeless, verás que hacemos alias... e tag a no op. Así que simplemente no hará nada cuando lo llames. Hay utilidades bastante útiles. Hay algunas que son más útiles, que hacen más. Así que npm, tenemos una serie de paquetes de npm, que simulamos, no simulamos, sino que duplicamos la funcionalidad. Así que console.luf, por ejemplo, es un logger de console, pero hemos producido un paquete que básicamente lo convierte en solo la console nativa de JavaScript. Y básicamente eso significa para Nitro, ahorramos un paquete, literalmente, ahorramos el tamaño del paquete. Porque cualquier dependencia que el usuario esté usando, que use console.luf, cuando se despliegan en el entorno de Nitro, simplemente usarán el logger de console nativo, lo que significa que no tienes que empaquetar todo el conjunto de dependencias de console.luf. Y lo mismo es cierto para debug, que es otro paquete, que usa muchas dependencias, y eventos FS, node fetch, DB MIME, que es enorme, tiene montones y montones de data sobre tipos MIME, y así sucesivamente. Tenemos poly fill. De todos modos, esto es probablemente demasiada información, pero básicamente, echa un vistazo a algunos de los repositorios un.js que tenemos en GitHub. Existen porque llenan nichos que no están siendo llenados por otras cosas. En muchos casos, eso es porque necesitamos paquetes que funcionen en múltiples entornos, como H3 funciona en el navegador, no solo en el nodo. H3, por cierto, es fenomenalmente rápido, así que es más rápido que Fastify, o definitivamente Express, o Connect, o cualquiera de los otros marcos de servidor. Una de las razones es porque toda la funcionalidad está expuesta por utilidades que se pueden sacudir. Así que si no estás usando el análisis de cookies, no está incluido en el paquete, y lo mismo es cierto para cualquier otra cosa que proporcione. Lo siento, me he extendido mucho. ¿Eso responde a tu pregunta sobre Andreas?

Vale, genial. ¿Alguna otra pregunta? Daniel, ¿puedo hacerte una pregunta, pregunta general sobre MAX3, o estoy fuera de tema? Adelante. Soy nuevo en MAX3 y en Vue 3. Me preguntaba, ¿cuál es la herramienta de empaquetado predeterminada en MAX3 porque en estos días con Vue.js, he aprendido que está listo para Webpack y para Vits también, y me preguntaba cuál funciona por defecto? Así que por defecto, Nuxt es, y esto funciona por el bien, por cierto, porque quiero entrar en algunos aspectos de Nuxt 3 porque queremos hablar de cómo desplegamos. Un par de personas preguntaron al principio. El empaquetador predeterminado es Veet. Así que si tienes tu configuración de Nuxt, esto es más o menos de serie, va a estar usando Veet, y puedes ver eso en el code. Sí, ese era mi conjunto de errores en su día que el servidor Veet está siendo construido, y eso es lo que está renderizando cosas para ti. Si quieres usar Webpack, puedes poner Veet igual a false, o también puedes pasar objetos a Veet, y las opciones para configurarlo. Así que si volviera a ejecutar Yarn Dev, ahora lo va a hacer con Webpack, que sigue siendo fenomenalmente rápido, por cierto, comparado con Webpack 4, aunque es difícil competir con Veet propiamente dicho por la velocidad, pero eso sigue siendo bastante bueno.

Si fueras a construir tu proyecto Nuxt, verás que esto es normal, una especie de salida de Webpack. Y produce una especie de servidor normal y salida de Webpack del cliente, que luego se transforma en un servidor Nitro. Lo mismo es cierto con Veet true. Entonces, si fueras a construir un servidor Veet, también va a hacer lo mismo. Va a crear paquetes de servidor y cliente en la carpeta dist, para consumir esos para producir tu carpeta .output.

Permíteme entrar en un poco más de detalle allí. Entonces, Nitro, si no lo sabías, es un proceso de dos pasos, es un proceso de construcción de un servidor Nitro como el segundo paso de una aplicación normal de Nuxt. Entonces, el primer paso compila la aplicación de vista, que renderiza un componente. Este es un concepto de una página con componentes, todo el lado de vista de tu aplicación. Lo renderiza en un paquete, que es lo que vemos aquí en esta carpeta dist de Nuxt. Y el lado del servidor no es un servidor completo, solo contiene lo suficiente para renderizar a una cadena HTML los componentes de vista de tu aplicación. Y el cliente contiene los archivos JavaScript que un navegador necesita para hacer lo mismo, para renderizar e hidratar, ese mismo HTML. Luego, el proceso de construcción de Nitro toma esas entradas y crea, solo copia los requisitos del navegador a una carpeta pública donde pueden ser servidos al navegador, y luego produce un servidor. El servidor contendrá, en un entorno Node, los módulos Node que se requieren para ejecutarlo. Entonces verás que no son muchos módulos Node, particularmente en comparación con el número en mi carpeta de módulos Node. Entonces, si echas un vistazo a mi carpeta de módulos Node, es, veamos, 560 directorios. Mientras que si miras en la carpeta de módulos Node del servidor de salida, es 27. Entonces, eso es una gran, gran diferencia. Y en realidad rastreamos el uso para averiguar. Usamos Versil tiene una maravillosa biblioteca llamada NFT, Node File Trace. En realidad, descubrimos lo que estás usando. Y en realidad solo copiamos esos. Tenemos una especie de punto de entrada del servidor. Entonces, si alguna vez iniciaras ese servidor Node, vas a querer simplemente ejecutarlo como un nodo. Ese va a ser entonces el punto de entrada del servidor. Y luego tiene una serie de fragmentos. Tiene fragmentos correspondientes a todos los, solo el middleware puro del servidor y las rutas de la API que acabamos de crear hoy, por ejemplo. Entonces health sí es muy simple, solo devuelve ese estado. DB hace un poco más aquí. Entonces verás que, esa importación de hash storage se ha convertido en una entrada relativa para importar este almacenamiento virtual, que se comparte entre varios fragmentos diferentes. Y lo mismo es cierto para las notas, por ejemplo. Entonces verás nuestro code allí, e índice, realmente no estoy seguro de lo que hicimos, lo que pusimos allí. Oh, este es, la, la aplicación Vue. Punto de entrada. Entonces en tu aplicación, que es donde normalmente vamos a buscar nuestra aplicación Vue, tenemos un renderizador Vue, que esto solo empaqueta el renderizador Vue 3. Y verás, por ejemplo, en esta función de renderizado, hace muchas cosas. Esta es la renderización del manifiesto. Pero básicamente está agrupando muchas otras cosas, como todas las dependencias de Vue y así sucesivamente. Entonces, lo que sucede es que, cuando se golpea el punto de entrada, tenemos una pequeña cantidad de code que se ejecuta. Entonces, esta es una pantalla de carga o quizás una pantalla de error, que está en línea. Y hay otro. Y tenemos la creación del servidor y el registro de cada una de las diferentes rutas que hemos registrado. Todos estos son dinámicos, de modo que si se golpea una de estas rutas, se carga. Pero si no se golpea, no se carga. Entonces, si tenemos algo, cada solicitud cargará estos dos fragmentos de middleware particulares. Pero solo las solicitudes que coinciden con los nodos de la API para la health de la API renderizarán esos particulares. Y solo cargaremos la renderización de la aplicación View a String si no ha habido un acierto hasta ahora en el middleware. Entonces, puedo mostrarte cómo se ve un poco con algunas opciones de Nitro. Entonces podemos establecer una opción llamada Timing, que va a inyectar Timing middleware. Entonces, si estoy, solo voy a construir esto de nuevo ahora. Y ahora habrás visto que en realidad solo en términos de una ilusión al middleware de tiempo, que en realidad inyectará algo de tiempo de servidor para nosotros. Ahora lo he habilitado y de hecho, eso ya se ha actualizado por eso. Entonces ahora cuando golpeo, si cargo un servidor, y lo golpeo, verás que ahora tenemos algo de tiempo que nos ha dicho, me ha dicho cuánto tiempo ha tardado en cargar cada fragmento. Y también nos ha dicho qué fragmentos se han cargado. Entonces, si ves las opciones posibles aquí, entonces estos dos middleware abiertos se han cargado y existen en Nitrous static que se ha cargado aquí que se encarga de servir archivos estáticos, que se necesita con los nodos básicos sobre y la mayoría de los objetivos a los que desplegarás como y los cinco versal o cloud flair o Azure, aplicaciones web estáticas o cualquiera de estas cosas, tendrán su propio CDN que se encargará de eso. Y entonces esto no se agrupa, pero está golpeando nuestro servidor estático. Tenemos algunas optimizaciones geniales en eso, por cierto, porque todo se puede hacer con anticipación.

Oh, solo para responder a tu pregunta sobre VEAT y la verificación de tipo IDE, hay un paquete increíble producido por el autor de OLA, un chico llamado Johnson, que básicamente te permite verificar el tipo de tu aplicación VUE. Y básicamente utiliza el mismo mecanismo que tu IDE. Así que todo lo que tienes que hacer es ejecutar MPX VUE TSC, no y eso, y eso va a verificar el tipo de tu aplicación VUE, exactamente. En términos de, um, pero sí, en términos de dónde estoy aquí. Así que cargamos Nitrous Static. Cargamos DB. DB en sí depende del almacenamiento virtual y de la configuración. Así que carga ambos, pero luego las notas y health no, no coincidimos con esas en la raíz. Así que no los cargamos en absoluto. En cambio, simplemente entramos en la aplicación, que necesita renderizarse. Necesita incorporar un manifiesto de cliente. Hay algunas otras cosas que necesita hacer allí, que hace. Así que todo el proceso, si puedes ver estos, estamos hablando de sub, ¿eso son unos 10 milisegundos? Cuatro, ocho, ocho milisegundos para cargar el code. Básicamente para responder a esa solicitud. Y ese code no necesitará ser cargado de nuevo. Así que si hago otra solicitud. No lo sabemos. Ya está en memoria y podemos responder. Pero si fuera a hacer una solicitud que específicamente mira, digamos, ayuda, no va a cargar ese fragmento también. Así que es según sea necesario. Y se está separando en fragmentos. ¿Esto es, por cierto, útil para la gente? ¿Estás contento de obtener este tipo de vista de lo que Nitro hace con tu servidor? Okay, genial.

Entonces sí, ¿puedes lanzarlo en Heroku? Sí, puedes. El punto principal es que queremos deshacernos de. Nuxt, queremos deshacernos de las dependencias que podrías necesitar para ejecutarlo. Así que anteriormente, si construías una aplicación Nuxt, todavía tienes que tener Nuxt, o hay una distribución ligera llamada Nuxt Start, que es muy ligera, pero sigue siendo algo separado. Mientras que aquí, en realidad solo estás ejecutando código nativo de Node y sus módulos nativos. Utiliza ESM nativo para Node, que también tiene sus propios desafíos, porque tenemos que esperar a que el ecosystem se ponga al día. Pero significa que es totalmente independiente del entorno en el que se encuentra. Oh, de Nuxt. Así que Nuxt debería ser una dependencia en tiempo de construcción. Este proyecto no tiene dependencias en tiempo de ejecución, técnicamente. Lo que produce como salida contiene todas las dependencias que necesita para ejecutarse. Así que es súper, súper pequeño. Deberías poder tomar esa carpeta de salida, pegarla en otro lugar y ejecutarla, y debería funcionar. No necesita todo el entorno de andamiaje alrededor de él en el proyecto, lo que significa que estás hablando de un tamaño total de proyecto en este caso de 1.7 Meg, que incluye todas las dependencias del servidor, así como todo el code generado para el lado del cliente y todo el code de generación para el lado del servicio. Así que es increíblemente mínimo y realmente pequeño y se adapta muy bien en una función serverless o una Lambda o algo así. Y es aún más pequeño, si estás usando un CDN y no necesitas servir los archivos estáticos desde dentro de la Lambda. Tenemos una serie de objetivos de construcción. Déjame mostrarte cómo funcionan, porque también puedes escribir los tuyos.

Permíteme mostrarte cómo funcionan, porque también puedes escribir los tuyos. Antes de pasar a los objetivos de construcción, porque estás hablando de lo rápido que es, ¿cómo impacta eso con SEO? ¿Existe algún tipo de relación con eso? Sí, sí, hay una relación con eso. Quiero decir, SEO es un poco mágico. Así que habrá muchas personas que trazarán las líneas y harán la conexión en diferentes sentidos. Pero mi regla general es que los motores de búsqueda están tratando de conectar a los usuarios con buenas experiencias. Así que quieren que los usuarios obtengan lo que están buscando. Así es como piensas, he tenido éxito hoy, encontré lo que estaba buscando. Y por eso los motores de búsqueda tienden a depriorizar los sitios que tardan en cargar, porque tiende a significar desinterés. Un motor de búsqueda mide el compromiso determinado por cuánto tiempo te quedas en la página, si te quedas en absoluto, si interactúas, navegas más. Y si como usuario, estás cargando una página que tarda mucho tiempo, es mucho más probable que cierres esa pestaña y pases a la siguiente. Lo que significa que todos los data van a impulsar a los motores de búsqueda, ya sea que lo digan explícitamente o no para empezar, a depriorizar los sitios lentos. Y creo que en general, eso es un comentario justo. Aunque, supongo, si tienes un sitio lento que está más orientado a las necesidades del usuario, eso es un factor contrarrestante. Así que en general, quieres un sitio que sea lo más rápido posible. En términos de la métrica clave, es ese tiempo hasta el primer mordisco. También hay otras métricas que realmente importan, como el tiempo hasta la interactividad. Entonces, después de que todo llega a tu navegador, ¿cuánto tiempo va a tomar para ser completamente receptivo para ti como usuario? Y entonces, si tienes muchas bibliotecas del lado del cliente, eso va a marcar la diferencia también. En términos de Nitro, Nitro está optimizado para funcionar realmente bien en condiciones como serverless o representación en el borde, porque solo carga lo que se requiere. Entonces, si yo fuera a, solo voy a editar el code de mi aplicación aquí, ¿vale? Mi aplicación aquí, ¿vale? Entonces, vamos a hacer console.time.start, console.time.end.start. Solo quiero ver cuánto tiempo lleva cargar realmente el servidor. Entonces, nuestro arranque en frío, es de cinco milisegundos. Eso es lo que tardó en iniciar el servidor, ahora respondiendo a las solicitudes. Si quieres ver cuánto tiempo lleva decir, responder a la solicitud, podemos golpear decir, solo mira las cabeceras, porque he habilitado el middleware de temporización aquí. Así que tenemos una cabecera de temporización del servidor, que puedes inspeccionar y ver de manera más gráfica, bien en, digamos, Chrome o Firefox. Pero te dice exactamente cuánto tiempo lleva hacer que esto suceda. Entonces, básicamente son cuatro milisegundos para responder a esa solicitud. Entonces, obviamente, si empiezas a hacer solicitudes de API, ese va a ser tu principal tiempo gastado. Porque si estás solicitando o conectando a una database externa o algo así, obviamente va a llevar tiempo. Y particularmente, si lo haces en cascada, así que primero haces una solicitud y esperas una respuesta y luego haces otra solicitud, eso va a retrasar las cosas para ti. Pero de serie, estamos hablando, ¿qué, cinco milisegundos de inicio en cuatro milisegundos de respuesta a una solicitud? Y eso no era una raíz de API, eso era renderizar una aplicación Vue. No era una muy complicada. Si hubiera mirado solo la verificación de health, por ejemplo, son los mismos cuatro milisegundos. Pero tal vez simplemente no podemos ser mucho más rápidos que eso. De todos modos, es realmente rápido. Está destinado a funcionar muy bien en la representación en el borde, en funciones serverless donde tienes una alta prima en tiempo de inicio y arranque en frío. Si fueras, por ejemplo, a, lo que significa que puedes usarlo más. El arranque en frío. Por ejemplo, con Nuxt 2 iniciando sin Nitro, tarda más de un segundo en iniciar, lo que puede no parecer mucho, pero eso es 100 veces más que Nitro. Eso hace una gran diferencia cuando tienes que inicializar. Obviamente, tarda aún más en devolver la respuesta. Hace una gran diferencia. Normalmente la gente ni siquiera pensaría en tener una aplicación renderizada en el servidor. Podrías tener simplemente una estática en lugar de renderizarla en una función serverless, mientras que Nitro significa que puedes revisar esa suposición y pensar en servir resultados más dinámicos o más personalizados relevantes para el usuario en antes de que el tiempo pudiera haberlo descartado. Veo que hay una pregunta sobre el modo estático. Así que puedo contarte un poco sobre eso, pero no puedes probarlo ahora. Así que no podría hacer esto hoy porque en este momento solo construimos un servidor. Pero el plan es el, debería decir, mira que todavía podrías necesitar un calentador para mantener el, como depende de tu plataforma porque tienen su propio gasto general en términos de iniciar el, pero estoy completamente de acuerdo con lo que Toby acaba de decir, por cierto, es solo una parte de la cosa. En términos de la Lambda, el lado de Nitro es realmente rápido, pero también tienes que considerar el hecho de que si está en almacenamiento en frío, tiene que ser descargado al servidor y tiene que ser descomprimido y luego tiene que ser ejecutado. Así que también hay todo ese gasto general. Así que no es instantáneo. Cloudflow Workers afirma tener un arranque en frío de cero milisegundos debido al uso de aislantes V8. Así que hay, de todos modos, deberías probarlo y básicamente ver cómo funciona en tu entorno particular. Como ¿cuáles son los compromisos y cuál es la capacidad de respuesta? Pero un beneficio que obtienes con Nitro es que tenemos una función. Así que en lugar de una función diferente para cada raíz, tenemos la función única que puede renderizar cualquier raíz. Y creo que básicamente es el punto dulce porque lo que significa es, es mucho menos probable que tengas un arranque en frío. Porque por ejemplo, si tienes una verificación de health, eso va a calentar solo la función serverless de health. Si tienes un golpe de API, va a calentar solo esa función. Y si tienes otro en tu sitio principal, va a calentar solo la aplicación de vista. Mientras que si los renderizas todos con un solo punto de entrada, que carga dinámicamente lo que necesita, no tienes la desventaja de tener un punto de entrada monolítico enorme, pero sí tienes el beneficio de tener una función que es más probable que esté caliente. Quiero decir, si recibes cien solicitudes simultáneas, todavía vas a necesitar calentar cien funciones simultáneas. Así que no es como si pudiera manejar todo. Pero básicamente matemáticamente, si tienes cinco funciones versus una función, en algún lugar como cinco veces menos probable necesitar calentar una función. También tengo una pregunta sobre la generación incremental de sitios estáticos. Sí. Y sobre el estado actual, porque sé que esto es como una cosa de plataforma y una cosa de framework, porque por ejemplo, necesitamos alojar como 4 millones de páginas y básicamente es demasiado. Y esto también llega a la pregunta sobre la generación de sitios estáticos. Entonces la razón por la que no hemos lanzado Max 3 con generación de sitios estáticos de serie es que lo estamos abstrayendo en algo que estamos llamando la capa de caché. Así que el concepto es que para cada raíz o posible respuesta a una solicitud, es posible tener una estrategia diferente.

Y luego hacemos lo mismo. Esta llamada local que hicimos con Netlify. Pasamos las cabeceras de URL, método y cuerpo. Luego, de nuevo, la forma en que respondemos con una función de Azure es en lugar de devolver un objeto, simplemente establecemos la propiedad en el contexto. Establecemos Res para igualar el estado de las cabeceras y el cuerpo. Y luego Azure toma eso y hace magia con ello. Así es como se hace. Puedes escribir uno de esos básicamente. Puedes escribir un Preset que básicamente permita que... Básicamente, simplemente configurará las cosas para ti. Si yo fuera a cambiar a el código real del framework, en lugar de simplemente sacarlo de los módulos de Node... Así que aquí está el Azure. Hay dos cosas, un Preset y una Entrada. Un Preset básicamente configura las cosas y la Entrada es el pedazo de código que se agrupa. Así que este Preset de Azure aquí, esta es la configuración. Pasamos una ruta a la Entrada, que te mostré hace un momento. En este caso estamos diciendo que vamos a usar Node External para no tener que incluir todo en la construcción. Tenemos un directorio de servidor personalizado porque Azure lo espera. También puedes, todo esto está tipado por cierto para que puedas ver qué propiedades puedes pasar. Y luego puedes tener ganchos que se enganchan en diferentes partes del proceso de construcción de Nitro. Así que puedes interactuar con las cosas antes o después de la construcción, modificando la configuración. Y luego tenemos que escribir básicamente un archivo JSON raíz y varias cosas, muchos JSONs que Azure espera. Tenemos que crear esos en el lugar correcto y asegurarnos de que sean precisos y apunten a las cosas correctas. Así que todo es muy específico para Azure, no es una especie de, y lo mismo sería cierto si construyes tu propia integración con cualquier plataforma que quieras. La complicación es sólo cuán complicada es la plataforma. Básicamente sigues los docs, te aseguras de crear las cosas que necesitas crear y puedes publicar eso como un preset independiente si quieres. Y luego tiene un punto de entrada que es lo mismo que te mostré hace un momento pero con algunos comentarios y tipos más. Así que no dudes en hacer más preguntas si hubiera cosas útiles. Si fuéramos a construir aquí, este sitio para decir Azure, entonces tienes que hacer esto, tienes que pasarlo como una variable de entorno o pasarlo aquí como un preset porque de lo contrario solo va a producir la cosa normal de nodo. Así que he tenido ejemplos de problemas por personas simplemente construyendo Nitro y luego esperando que funcione en diferentes lugares. No lo hará porque no ha construido la cosa, los conectores para el entorno objetivo en el que necesita entrar. Así que aquí he establecido el preset. En la mayoría de los casos, por cierto, no necesitas hacer esto. Así que intentamos detectar el entorno. Así que con Nitro, en función de dónde estemos, intentamos detectar el... Tenemos esta función de detección de objetivo. Así que si no hay un preset explícito, si no hay una variable de entorno, entonces ejecutamos esta función de detección de objetivo. Podemos detectar si estamos en Netlify o si estamos en Versal o si estamos en Azure. Así que no necesitas establecer esos, eso es automático. Si está en ese entorno, lo sabrá. Pero entonces eso es lo que pasa. Si tenemos formas de identificar otros entornos, podemos añadirlo a la configuración cero porque a quién no le gusta la configuración cero? Pero en este caso, simplemente vamos a decir explícitamente que estamos construyendo para Azure porque queremos probarlo. De una manera tipo Azure. Ha hecho eso. Así que nuestra salida es un poco diferente aquí. Tenemos un archivo host.json que parece ser requerido. Hay una definición de función donde decimos cuál es el punto de entrada. Así que es una función llamada handle que es handle exportado. Tenemos los triggers. Básicamente solo lo configuramos para Azure. Pero es lo mismo. Así que todavía tiene el index.mjs. Simplemente está exportando un handle. Y el resto es solo la fontanería. Tenemos un comando aquí que podemos ejecutar que simplemente ejecutará el CLI de Azure Static Web Apps. En la medida de lo posible, queremos proporcionar esos para las personas para que simplemente sepas lo que necesitas ejecutar para probarlo. Así que puedes probar Firebase localmente, puedes probar Azure. Creo que Vercel y Netlify, no proporcionamos un comando para eso. Sí, pero ahí vamos. CLI de Azure Static Web Apps que por cierto, no existía cuando construimos por primera vez esta funcionalidad. Así que hemos vuelto hace unos días y añadido documentación para esto. Va a servir el contenido estático de esa carpeta pública y el servidor desde allí que es lo que queremos. Y si luego abrimos ese 7071, oh no, esa es la URL interna, lo siento, esa es la URL interna. La que se supone que debemos acceder es 4280. Así que eso acaba de renderizar la página para nosotros tal como lo haría en un contexto de Azure. Así que ha golpeado 4280, se ha dado cuenta entonces de que necesita cargar, para renderizar eso con esta función de servidor. Así que está ejecutando la función y luego vemos todos los tiempos que esperamos. Ha hecho eso y luego está devolviendo una respuesta. Así que es un ejemplo de cómo lo harías. Dave tiene una pregunta.

Hola Daniel, estoy seguro de que puedes recordar de la última vez si realmente me ayudaste en esto, pero una de las cosas que encuentro con NUXT es que creo que alguien mencionó en los comentarios como oh, genial, más magia. Siempre he encontrado bastante frustrante la magia en NUXT porque si funciona, es brillante. Si no funciona, tienes una especie de, es realmente difícil saber por dónde empezar y creo que cuando, la última vez que lanzamos en Azure. También lancé en FirstSell, que me pareció un poco más fácil, pero por ejemplo, Azure tiene este enorme panel de control y es realmente difícil saber a dónde ir. Así que me preguntaba cuáles son los planes del equipo para dar a la gente un poco más de asistencia en esta próxima versión? Entonces, el, bueno, básicamente tenemos documentación, que está en progreso porque es una beta, pero si identificas problemas con ella, básicamente los arreglaré. Así que, tenemos nuestros docs y tenemos, esa es nuestra sección de despliegue aquí. Así que si estás lanzando en Azure, espero que esto responda bastante a las preguntas. Si no es así, entonces definitivamente vale la pena plantear un problema porque si no es un error, es un problema con la documentación de todos modos. Así que, en términos de asistencia, supongo que la documentación es básicamente donde estamos ahora. En términos de decir, comando de despliegue de Nucsi, así que puedes simplemente ejecutar Nucsi despliegue y te pregunta lo que necesita saber y hace lo que necesita hacer. Eso es el tipo de cosa que nos encantaría construir. Así que simplemente esperaría y vería lo que viene. Pero nuestro objetivo es hacer las cosas más fáciles, más simples. Así que si eso es, y queremos especialmente hacer que la CLI sea realmente agradable, para que puedas hacer cosas geniales con ella como añadir una funcionalidad a tu aplicación tirando de un módulo y luego tenerlo autoconfigurado para ti, en lugar de simplemente esperar que la gente tenga que añadirlo y luego encontrar las cosas que necesitan para añadir a su configuración y hacer eso. Y ya, con suerte, puedes ver eso con algunas de las cosas de tipo, que las cosas deberían estar cada vez más ahí para ti automáticamente. No deberías necesitar conocer toda la funcionalidad y no deberías necesitar abrir los docs, deberías poder ser guiado de alguna manera mientras escribes. Pero si no te encuentras con eso, me molesta porque será algo que querré cambiar. Sí, está bien, gracias. Supongo que va a pasar un tiempo antes de que despliegue algo en la próxima versión. Pero sí, gracias. Vale la pena decir, por cierto, sobre eso. Bueno, exactamente, de hecho como Andrea acaba de decir, estamos totalmente en beta ahora mismo. Así que las cosas están cambiando, cada commit es un nuevo lanzamiento. Estamos arreglando errores, estamos causando nuevos, estamos arreglando esos. La tendencia es ascendente pero definitivamente no es algo para construir un sitio de producción ahora mismo a menos que tengas tiempo para explorar y disfrutar y estés dispuesto a arreglarlo si las cosas no funcionan. Esto no va a durar mucho tiempo. Así que estamos, creo, avanzando probablemente bastante rápido. Pero definitivamente espera a que sea un poco más estable antes de construir algo de producción en él. ¿Preguntas?

Vale. Vale. Muchas cosas que mirar. Realmente espero, por cierto, que cualquiera que, si tienes alguna pregunta o quieres explorar, profundizar un poco más, por favor, por favor hazlo. Así que tenemos un servidor de Discord. Únete a él. Es, te enviaré un enlace. Únete al servidor de Discord. Y puedes hacer preguntas y molestarme con notificaciones push. Obviamente, el identificador de Twitter de NUXT JS es una gran manera de encontrar lanzamientos y nuevas características. Pero igualmente, sólo para estar al tanto del repositorio del framework de NUXT. Ahí es donde se lanzan todas las cosas. Sí. Teefo pregunta, ¿cuánta magia hay en Nitro? La respuesta es que hay mucha magia en Nitro. Así que no sé exactamente a qué te refieres con eso. No sé cómo puedo responder a esa pregunta de la manera más útil. Así que creo que las cosas a las que señalaría como mágicas en Nitro son la búsqueda isomórfica porque eso te permite hacer las solicitudes locales. Señalaría las rutas de API de tipo, que básicamente te permiten saber el tipo de respuestas que vuelven. Me referiría a cosas como los activos y... Está yendo mal. Activos, configuración y almacenamiento. Así que he mencionado almacenamiento y configuración. Los activos es otro. Realmente te permite acceder al sistema de archivos efectivamente, sea lo que sea que parezca. Así que en un flujo de trabajo de Cloudflare, acceder al sistema de archivos es un poco diferente porque está en un almacenamiento de valor clave. Pero en tu punto final de API, puedes hacer algo como... Puedes importar cosas de los activos y tienes tipos similares de obtener claves, leer activos y comenzar activos. Creo que era como un acceso al sistema de archivos a tus activos. Déjame simplemente pegarlo en el middleware de DB y te mostraré lo que hace. Pegarlo en el middleware de DB y te mostraré lo que hace. Y vamos a...... Eso sería uno de esos errores de los que estábamos hablando. Pero básicamente, los activos te permiten acceder directamente al sistema de archivos. Probablemente debería documentarlo, para asegurarme de que esto está funcionando. ¿Hay otras preguntas? Así que puedes escribir TypeScript. Básicamente, TypeScript tal como lo escribes, no será comprobado por tipos. Tienes que hacer eso tú mismo, eso es algo aparte. Y la razón de eso es en gran parte el rendimiento porque la comprobación de tipos es fenomenalmente intensiva en recursos. Y solíamos encontrar problemas en Nuxt, dos, donde los servidores de la gente básicamente se congelaban y era TypeScript. Era el comprobador de TypeScript el que lo congelaba en lugar de incluso el web pack cuatro. Así que lo que quieres hacer es ejecutar ese comando npx UTSC nomt.

Eso va a comprobar los tipos de tu proyecto para ti. Recomendaría hacer eso como parte de tu paso de construcción y como para producción en lugar de ejecutarlo a medida que avanzas y confías en la autocompletación del IDE, pero también estamos abiertos a mejorar eso. Quizás ejecutándolo en un proceso separado o averiguando cómo hacerlo más eficiente. Pero puedes simplemente escribir TypeScript. Así que tu punto de entrada del servidor, ya sabes, como verás que mis, um, archivos de servidor son TypeScript y lo mismo es cierto. Um, tu aplicación puede ser TypeScript también. Todas tus cosas de vista y todo lo importado en tu, tu aplicación TypeScript simplemente se obtiene, um, básicamente los tipos se eliminan. Es la forma más rápida de hacer las cosas solo, solo lo que estás escribiendo. Vale. Creo que, um, probablemente hemos llegado al final de nuestra, um, masterclass. Um, estoy realmente contento de que la gente me moleste, um, más preguntas. Uh, modules compatible con NUTS 3, hay una, una discusión de GitHub, que se llama estado de soporte de modules. Um, es eso, um, eso básicamente va a mantener, te dará una especie de actualizaciones sobre todo. Muchas cosas están pendientes en este momento. Así que van a ser, creo que probablemente verás un progreso bastante rápido. Um, pero básicamente queremos asegurarnos de que tenemos las herramientas para que los autores de módulos construyan estas cosas. Um, en términos de la API de almacenamiento, aún no está documentada. Um, pero eso está conmigo. No dudes en crear un problema si quieres instarme, pero, um, esa es parte de lo que el propósito de este período beta es para crear mejor documentation. Um, pero si estás interesado en el mejor lugar para encontrarlo, por supuesto, está todo en el code fuente. Así que, um, si estás echando un vistazo y al siguiente framework, um, y quieres decir, ver de dónde vienen algunas de estas cosas, um, si, si fuera a crear almacenamiento aquí, verás uno, aquí es donde añadimos los tipos para ello. Aquí es donde creamos una exportación virtual, um, uh, export. Así que, ah, ese es el problema. Um, básicamente la definición de tipo, tipo está mal. Así que lo que deberíamos estar haciendo, por cierto, para el, um, para importar activos, deberíamos estar importando algo llamado activos, que luego tiene un, ahí vamos, eso debería funcionar. Así que si estuviéramos ejecutando eso, deberíamos poder ver las claves, que es solo un array vacío en este momento. Um, el, uh, pero puedes encontrar, puedes encontrar exactamente qué qué está pasando solo buscando. Um, y sí, esa es una gran manera de hacerlo. Um, y no dudes en poner tu propio PR. Si crees que has descubierto algo genial y crees que a otras personas les gustaría saberlo, um, estamos muy contentos de tener nuevos colaboradores y personas que están, um, dispuestas a ayudar de esa manera. Gracias, Daniel. El área de almacenamiento parecía muy poderosa. Así que, yo, yo, uh, solo, estaba buscando la documentation. Yo, realmente ayudaría. Así que estaba preguntando, uh, de todos modos, estaba mirando esta masterclass ahora y estaba, y estaba pensando, Oh, genial. Ya no necesito a mis colegas de back-end. Bueno, um, veamos, veamos qué pasa. Um, el, cuáles son los, Oh, um, esto es VS code comprobando los archivos de salida. no quiero que VS code tipo, tipo revise los archivos de la aplicación. Y probablemente querré excluir esos. Um, vale. Creo que eso es probablemente todo entonces, pero como decía, no dudes en molestarme, envíame un mensaje. Um, Me gusta mucho explicar las cosas geniales que creo que estoy haciendo. Y me gusta mucho cuando la gente me dice que no es tan genial como yo creo. Y que debería hacerlo de otra manera también. Eso, eso también es bueno. Así que, um, estoy sí, realmente, realmente queremos hacer las cosas agradables para la gente. Así que, um, es es, realmente aprecio lo que, cuando, cuando recibo, recibo comentarios, en términos del code, lo agradezco y lo empujaré, lo empujaré hacia arriba. No es que sea un code particularmente hermoso, pero al menos, um, es un recordatorio de algunas de las cosas de las que hablamos hoy. Vale. Ha sido un placer y estoy seguro, Oh, um, ¿cómo puedes enviarme un mensaje en discord? Um, soy Daniel row en Twitter. Soy Daniel C row en GitHub. Soy Daniel row. Um, mi dirección de correo electrónico es Daniel en row. Dev. Soy muy accesible y también no soy nada anónimo. Así que, um, de todos modos, no dudes en ponerte en contacto. Increíble. Muchas gracias. Gracias. Adiós. Adiós.