RedwoodJS: El marco de aplicación React Full-Stack de tus sueños

Sé lo que estás pensando. Quiero hacer una aplicación web. Así que voy a necesitar React. Voy a necesitar Prisma en el backend para hablar con una database. Voy a necesitar Apollo para hablar desde el frontend hasta el backend.

Voy a necesitar Jest para poder escribir algunas pruebas. Voy a necesitar Storybook para poder design code y probar mis componentes de forma aislada. Voy a necesitar Webpack para unir todo esto. Y voy a necesitar Babel para poder compilar, transpilar ES6 a ES5.

Esa es la aplicación web, pero voy a necesitar averiguar cómo desplegar esto. Tal vez podría ir a Netlify. Están muy metidos en Jamstack. Tal vez podría ir a Vercel. Tienen un logo de triángulo genial. ¿Qué tal render? Tal vez entonces podría usar containers y obtener solicitudes de larga duración y suscripciones de GraphQL. O tal vez necesito todo el poder de AWS. Aún no he decidido.

En cualquier caso, voy a necesitar algún tipo de authentication así que podría usar Auth0 para eso. No voy a escribir el mío. Tengo que ir más allá de eso, sin embargo. También necesito autorización. Así que voy a necesitar algunos controles de acceso basados en roles. ¿Y qué hay del registro? Voy a necesitar un registro realmente bueno enviado al proveedor de mi elección.

Voy a tener que dividir el código de esto para que el navegador no reciba demasiado code a la vez. Voy a necesitar etiquetas OG, para que esto se despliegue en Twitter y Facebook. Probablemente tenga que tener pre-renderizado para hacer eso. Y voy a necesitar accessibility desde el principio. Esto funciona en lectores de pantalla.

Bien. Hagamos esto. Eso no es realmente cómo funciona, ¿verdad? Es más como esto.

Bien. Google, mi viejo amigo, crea una aplicación react. Vale, ahí estás. ¿Qué es esto? Ahí vamos. Lanzamiento. CX. Crea una aplicación react. Bien. ¿Cómo voy a llamar a esto? ¿Gloobnox? Eso funciona. Bien, dejaremos que haga su cosa por un tiempo. Aprendamos a usar Prisma. Vale, Prisma, aquí vamos. No. No ese. No. Tampoco ese. ¡Aha! Te encontré. Sí. Aquí vamos.

Prisma docs. Inicio rápido. Bien. En esta página aprenderás cómo enviar consultas a, ok, genial. Bien. Esto va a llevarme el resto de mi vida. Pero no desesperes, porque hoy estoy aquí para hablarte sobre Redwood JS, el framework de aplicaciones React de pila completa de tus sueños.

Ahora, sé lo que te estás preguntando. ¿Quién es este tonto que me dice qué hacer? Bueno, soy Tom Preston Werner. Puedes encontrarme en línea, en MoJombo en Twitter y GitHub. En el pasado he creado empresas como GitHub y Chatterbug, el mejor lugar para aprender un idioma extranjero. También he sido muy activo en el código abierto. Creé Jekyll. Escribí el semver, la especificación de versionado semántico, TOML, el lenguaje de configuración utilizado por una variedad de paquetes, y Gravatar, los avatares que te siguen a todas partes.

Ahora, volviendo a esta pantalla, ¿recuerdas todas estas tecnologías? Estas tecnologías son increíbles, pero no necesariamente quieres pensar en todas ellas. De hecho, Apollo es genial. Pero realmente, cuando escribo una aplicación, quiero preocuparme por GraphQL y no realmente las complejidades de Apollo. Y realmente no quiero preocuparme por Webpack o Babel en absoluto. De hecho, quiero centrar mi atención en escribir JavaScript o TypeScript. Para eso estoy aquí. Soy un programador. Déjame escribir código. Eso es lo que hago.

Y así, una aplicación Redwood se va a dividir en dos partes. Muy simple. Un modelo muy simple para pensar. En el lado web, tienes tu aplicación React. Aquí es donde piensas en tus pruebas con Jest y tu storybook. Estos ocurren localmente pero conceptualmente son realmente parte del lado web de esto. Y luego, en el lado API, tienes una implementación de una API GraphQL que utiliza Prisma y un montón de JavaScript o TypeScript para crear tus servicios, tu lógica de negocio que va a hablar con tu base de datos y hacer lo que necesitas que haga. En medio tienes GraphQL que habla de un lado a otro. Y GraphQL es cómo haces consultas y también cómo especificas las consultas y mutaciones que van a suceder. Pero basta de charla, veamos algo de código. Aquí a la derecha tengo abierto GitHub.com slash Redwood JS slash ejemplo para hacer. Esta es una simple aplicación de tareas pendientes escrita en Redwood que pensé que te mostraría algunas cosas, y mostrar cómo funciona Redwood y cómo piensa sobre el mundo. Así que he clonado esto a mi máquina local. He ejecutado Yarn, puedes ver las instrucciones aquí. Y he inicializado la base de datos. Así que está todo configurado, listo para ir. Así que lo primero que voy a hacer es ejecutar Yarn Redwood dev para poner en marcha el servidor web. Esto va a poner en marcha ambos lados de los que hablé antes, tanto el lado web como el lado API, el front end y el back end, los enlaza y abre una nueva ventana del navegador con mi lista de tareas pendientes. Así que te mostraré cómo funciona. Puedo decir que necesito pedir leche, queso y huevos. Y puedo alternar estas cosas encendidas y apagadas. Esto está hablando con el back end a través de GraphQL. Puedes ver aquí en los registros, los posts al back end de GraphQL. Entonces, ¿cómo funciona eso? Bueno, en el editor de aquí, verás la carpeta web y la carpeta API. Esta es una estructura de monorepo. Así que cada una de estas son paquetes separados dentro de un solo repositorio Git. Así que comencemos por donde todo comienza, que es con las rutas.

Entonces, en el archivo de rutas aquí, puedes ver que tenemos un enrutador. Y dentro de él, tenemos una ruta para la página de inicio y una ruta para una página no encontrada. Esto es esencialmente el 404. Entonces, esta es nuestra página de inicio. Y en Redwood, tenemos otro directorio para las páginas. Es muy fácil encontrar cosas, muy organizado, la estructura del directorio.

Entonces, esta es la página de inicio. Esta aplicación está utilizando componentes de estilo, que verás aquí. Y es simplemente React estándar. Entonces, esto debería parecer muy familiar si conoces React. Entonces aquí tenemos un contenedor, tenemos el título, la lista de tareas pendientes, y luego tenemos una celda de lista de tareas pendientes.

Ahora, Redwood tiene un concepto realmente especial llamado celdas, y las celdas son una forma de declarativamente hacer tu obtención de data GraphQL. Entonces, vamos a ver eso. To-doListCell está en componentes de origen, to-doListCell. Entonces, componentes de origen, to-doListCell. Y aquí está el archivo. Y cómo funciona esto es que simplemente exportas un cierto conjunto de variables desde aquí, constantes, incluyendo la consulta. Entonces comienzas con tu consulta GraphQL, simplemente la escribes aquí como una consulta GraphQL o podrías tener una mutación aquí también, que puedes ver aquí. Y luego tienes diferentes estados y simplemente exportas estos estados como componentes. Tienes un estado de carga y un estado de éxito. También puedes definir un estado de fallo y un estado vacío. Aquí, simplemente he hecho una carga. Dice muy simplemente cargando. Y un estado de éxito. Y lo que esto hace es realmente simplificar y centrarte en lo que estás construyendo. Entonces, en esta instancia, cuando esta consulta se completa, cualquiera que sea el nombre de la consulta, la consulta GraphQL que estás haciendo, en este caso, tareas pendientes, eso se enviará como una variable, como un parámetro al componente de éxito. Y luego dentro de eso, puedes hacer tu trabajo. Entonces, esto está haciendo una actualización optimista de la que no tienes que preocuparte demasiado para Apollo. Pero aquí, puedes ver que simplemente está tomando las tareas pendientes y mapeándolas y creando elementos de tareas pendientes que representan cada uno de estos elementos aquí. Y eso es lo que son las celdas. Entonces, realmente, es solo una forma sencilla de pensar en tu obtención de data, por lo que no tienes que hacer mucha lógica condicional. Realmente organiza el code alrededor de eso.

Ahora, cuando llegas al back end, al lado de GraphQL, veamos cómo se ve eso. Entonces, aquí está la consulta de tareas pendientes. Voy a mirar en el lado de la API aquí. Voy a mirar en la fuente, GraphQL, y tareas pendientes. Ahora estos los llamamos servicios. Entonces, divides tu aplicación Redwood en diferentes servicios. Esta aplicación es muy simple. Solo tiene un servicio, este servicio de tareas pendientes. Una aplicación más grande, podrías dividirla en diferentes servicios para las diferentes responsabilidades que tiene tu aplicación. Entonces aquí vemos un archivo SDL que se define en un archivo JavaScript. Y aquí está el SDL. Entonces, si has escrito GraphQL antes, entonces esto debería parecer muy familiar. Esto es SDL estándar directamente de la caja, el lenguaje de definición de esquema. Y aquí estamos definiendo un objeto de tareas pendientes y consultas y mutaciones. Y lo bueno es que cada servicio puede tener uno de estos archivos, y todos pueden ser separados, y Redwood hará el trabajo duro de unirlos y presentarlos al mundo. Entonces, busquemos lo que estábamos hablando. Las tareas pendientes van a devolver una matriz de elementos de tareas pendientes, que se definen aquí. Y cuando normalmente estás escribiendo Apollo, tienes que pensar en escribir tus resolutores, y hay una forma específica de hacer eso, y todos terminan en el mismo archivo, y puede parecer muy desordenado.

Parece que hay mucho código repetitivo. Así que hemos eliminado todo eso en Redwood y dijimos, bueno, simplemente emparejemos las cosas por nombre. Y entonces, si entras en este directorio de servicios y miras los servicios, to-do's, to-dos.js, lo que verás aquí es una constante, to-dos, este es el mismo nombre que la consulta GraphQL que se exporta, y Redwood es lo suficientemente inteligente para emparejar eso y decir, esta es la implementación. Este es el resolutor para esa llamada de GraphQL. Y en él, vamos a usar Prisma, que simplemente importamos aquí. DB representa la base de datos de Prisma. Y ahora podemos hacer cualquiera de nuestras llamadas de Prisma en eso. En este caso, simplemente estamos haciendo una búsqueda de muchos. Así que una forma realmente divertida de explorar eso como ya puedes estar acostumbrado es con un entorno de pruebas de GraphQL, y Redwood, por supuesto, viene con uno de esos, y eso va a ser en localhost 8911. Y podemos probar esto. Así que ya tengo cargada la misma consulta que encontramos en las celdas de la lista de tareas, solo la consulta de la lista de tareas ID, cuerpo, estado. Y si ejecutamos eso, entonces podemos ver que obtenemos exactamente lo que esperamos, leche, queso, huevos, y todo está como debería estar. Y realmente, ese es todo el código que se necesita para hacer el front end al back end.

Muy bien, eso es genial. Dices, ¿qué tal hacer esto desde cero? Tenerlo todo ahí ahora es una cosa, pero ¿qué pasa si queremos hacer algo desde cero? Bueno, vamos a intentarlo. Voy a cerrar todo esto. Y voy a cambiar aquí. ¿Y qué deberíamos implementar? Creo que sería divertido tener una página que simplemente me mostrara el recuento de tareas pendientes. Tal vez algo más necesita eso por alguna razón. Es algo sencillo de implementar. Así que tenemos la capacidad de generar ciertas cosas en Redwood. Así que voy a ejecutar Redwood, lo siento, Yarn, Redwood generar o simplemente G para abreviar, página, y la voy a llamar la página de cuenta. Voy a ejecutar eso. Y lo que voy a ver aquí ahora en mi archivo de rutas es una nueva ruta que ha sido generada slash count, toma eso de lo que he escrito aquí. Y ha creado una página de cuenta para mí. Así que vamos a ver esa página de cuenta. También está creando un archivo de historias para storybook. Esto está integrado de serie. Y una prueba. Esta es la prueba justa. Así que estamos integrando maravillosamente todos estos diferentes elementos. Ahora mismo podemos ir a ver esto en slash count. Y aquí vamos. Esto es solo las páginas generadas es lo que parece. Si hacemos cualquier cambio aquí, entonces se reflejarán inmediatamente en el sitio web. Así que puedes ir y venir muy, muy simplemente y hacer esto.

Muy bien, muy bien. Ahora necesitamos obtener algunos data del back end. Así que cambiemos al lado de la API ahora. Y vamos a modificar nuestro archivo SDL para crear una nueva consulta GraphQL. Y la vamos a llamar recuento de tareas pendientes. Y siempre va a devolver un entero. Tengo una extensión de Redwood instalada en VS Code aquí. Y hace algunas cosas agradables. Así que aquí verás que puede decirme que este servicio en realidad no está implementado. No tengo una implementación para esta consulta específica. Y así es simplemente una forma muy agradable. Como hacemos algunas cosas automáticamente por ti, también queremos ayudarte a ver cuándo algunas de esas cosas automáticas no van a funcionar correctamente.

Así que esto no está implementado. Bueno, vamos a implementarlo. Eso está en los servicios to do's JS, vamos a crear algo llamado recuento de tareas pendientes. Lo haremos justo aquí. Exportar const recuento de tareas pendientes. Eso va a ser una función. Y simplemente va a ser db.to do.count. Bueno, veamos si eso funcionó. Deberíamos poder ejecutarlo y ver si funcionó. Y aquí vamos. Muy bien, ahí vamos. Mira, añadí dos líneas de code y creé toda mi infraestructura GraphQL necesaria para que el back end funcione. Así que ahí vamos. En una nueva consulta GraphQL, definida, lista para devolver algunos data y ser consumida por el front end en esta página de recuento.

Bueno, vamos a necesitar una celda. Estamos obteniendo data. Así que necesitamos una celda. Así que vamos a crear una celda. Yarn, Redwood, generar, celda, todos.count. Dejaremos que eso se ejecute. Y vamos a encontrar esto en componentes, todos.count, celda justo aquí. Ahora ha generado esto y ha adivinado lo que voy a escribir como una consulta GraphQL, pero está un poco equivocado. Hagámoslo correcto. Va a ser simplemente todos.count. Así. El estado de carga está bien. El estado vacío, esto es de lo que estaba hablando antes. Todos estos están predefinidos. Simplemente cambiamos estos como nos guste un estado de error. Y el estado de éxito simplemente va a hacer por defecto un JSON stringify en lo que sea que salga de aquí, que simplemente va a ser un entero. Y eso está bien por ahora. Nos gusta eso. Y ahora vamos a usar esto en la página de recuento. Así que veamos aquí. ¿Por qué no decimos que todos.count va a ser la celda todos.count. Y luego necesitamos importar esto. Ya no estamos usando eso. Así que importamos todos.count cell desde source components, todos.count cell.

Y si volvemos aquí antes de guardar esto, entonces ahí vamos. Y eso es realmente todo. Hicimos todo eso en un par de minutos. Podría, si no estuviera hablando tanto, haberlo hecho mucho más rápido, pero eso es de principio a fin, todo el camino en el lado de React, hasta GraphQL, todo el camino hasta el lado posterior, Prisma, hasta la base de datos, todo con solo unas pocas líneas de código, unos pocos comandos generadores, y eso es realmente lo fácil que Redwood intenta hacer todo lo que haces.

Ahora mencioné antes que también tenemos integración con Storybook, así que me gustaría mostrar eso rápidamente. Para poner en marcha el servidor de storybook, voy a ejecutar yarn Redwood storybook. Y eso tardará unos segundos en arrancar. Y cuando termine, lanzará esta página, y verás aquí que tenemos las historias de storybook para las cosas que he generado. Tenemos la página de recuento, que se está generando, y mira esto. Realmente tiene algunos datos para el recuento que está volviendo, pero eso es interesante. 42, ¿de dónde salió eso? ¿Y por qué dice ID ahí? Eso es un poco raro.

Bueno, la razón de que eso esté sucediendo es que lo está sacando de aquí. Así que la página de recuento es esa página completa, se está sacando de esta celda de recuento. Y una de las cosas que hacemos por ti, si estabas prestando atención aquí cuando creamos esto, y entré en este directorio, es que verás este archivo de simulación. Y este archivo de simulación va a hacer que sea realmente fácil para ti ver tus celdas en storybook, porque simular tu obtención de datos en storybook es uno de los verdaderos desafíos para hacer que storybook funcione realmente bien con tu aplicación. De nuevo, Redwood intenta hacerlo realmente fácil para ti. Y entonces, tenemos el concepto de simular tu obtención de datos. Y en este caso, hemos dicho, creemos que todos los recuentos van a devolver un objeto con un ID. Puede que recuerdes que eso fue lo que supusimos que ibas a hacer. Pero es muy fácil entrar aquí y simplemente decir, Oh, en realidad solo está devolviendo un número. Y guardar eso. Y ahora, verás que el estado de éxito de esto se actualiza. Y de hecho, la página en sí se actualizará. Así que, todos estos componentes pueden usar estas simulaciones, las celdas. Y eso significa que cuando tienes una página o tienes una celda o un componente que tiene una celda en él, cada vez que tienes uno de esos, si lo usas en tu storybook, está bien. Simplemente va a sacar estos datos simulados y los va a incluir. Así que, sigue siendo muy fácil visualizar tus componentes y trabajar con ellos sin la molestia de tratar de pensar en cómo vas a conseguir que esos datos se simulen ahí. Y de nuevo, ahora puedes trabajar muy fácilmente en los estados de carga de estas cosas. Así que, la celda de recuento de todos tiene estos varios estados. Puede que quiera que mi estado de carga simplemente diga, solo espera. Puedo guardar eso. Y ahora, en lugar de tratar de estar en mi aplicación y hacer clic en actualizar y ser como, oh, ¿qué hizo, qué, se ve bien? Oh, lo veo. Está ahí por como, ya sabes, cien milisegundos o algo así, incluso menos. Eso es un poco molesto. Y puedo ir a mi inspector y puedo hacer que mi página sea realmente lenta. Y eso es molesto. Pero por eso tenemos storybook. Ahora, puedo entrar aquí y puedo mirarlo todo el tiempo que quiera. Y puedo hacer que funcione. ¿O el estado vacío, cómo se ve eso? ¿Qué pasa cuando recibo un error? Si quiero hacer que ocurra un error en mi aplicación, tengo que entrar en mi implementación, probablemente, y añadir algún tipo de error de sintaxis para que vaya a lanzar algún tipo de error. Ahora no te metas con eso. Por eso tenemos storybook y Redwood se trata de hacer que todo el proceso de desarrollo de aplicaciones, de principio a fin, sea lo más suave posible con la menor cantidad de trabajo, la menor cantidad de código repetitivo que podamos hacer por ti. Hemos pasado tantas horas reduciendo el código repetitivo y haciendo integraciones de estos productos. Integrando Jest, integrando storybook, eliminando Webpack. Notarás que aquí, realmente no ves Webpack en absoluto. No ves Babel en absoluto. Por supuesto, tenemos algunos archivos de configuración para ti en caso de que necesites profundizar en ellos, pero realmente nunca tienes que tocarlos. Si solo estás haciendo cosas normales, esto ya no es parte de tu trabajo. Deja que el marco de trabajo haga el trabajo pesado por ti para que puedas concentrarte en tu lógica de negocio. Bueno, ¿qué más puede hacer Redwood por ti? Bueno, me gustaría mostrarte algo que lanzamos recientemente.

Eso es pre-render, la capacidad de tomar cualquiera de tus páginas y especificar que se construyan en tiempo de construcción, que se rendericen en tiempo de construcción y luego se envíen estáticamente. ¿Cómo va a funcionar eso? Bueno, digamos que tienes una página de inicio, algún tipo de página de marketing que realmente no tiene mucho contenido dinámico y sólo quieres renderizarla en tiempo de construcción y hacerla disponible. Así que hagamos eso. Creemos una página que sea realmente estática. Así que puedo ejecutar Yarn redwoodgeneratepage, simplemente la llamaré splash, y obtendremos esa página de inicio y vamos a ir a ella aquí para que podamos verla. Y vamos a encontrarla, fuente web, páginas, página de inicio, y aquí vamos a hacer esto vamos a hacer esto bastante simple. Vamos a ir con este contenido pero lo que quiero mostrarte es cómo va a funcionar la hidratación cuando hagamos esto y lo fácil que lo hacemos también. Hagamos esto un botón en su lugar y dale un on click que simplemente va a ser una función que ejecuta una alerta, hola. Y simplemente lo llamaremos splash porque así es como ya se llama. Y veremos ahora que tenemos un errand para deshacernos de ese tipo. OK, así que ahora cuando presiono esto, dice hola. OK, eso es lo esperado. Todo esto es dinámico. Si apagas JavaScript en este modo, esta es la aplicación de una sola página totalmente dinámica. Puedo apagarlo. Tengo un pequeño botón de apagado de JavaScript justo aquí. Voy a hacer clic en él y verás que ya no hay más página, obviamente, porque React está montando todo el asunto. Todo el HTML proviene de JavaScript y de React y eso no es siempre lo que queremos por razones de SEO, por razones de performance. Hay muchas razones por las que podríamos querer generar estas cosas en tiempo de construcción. Así que lo volvemos a encender y lo verás. ¿Cómo haces eso en Redwood? ¿Cómo le digo a Redwood que tome esta página y la pre-renderice en tiempo de construcción? Bueno, déjame mostrarte. Podrías esperar que sea fácil y estarías en lo correcto. De hecho, es tan fácil como una palabra. Todo lo que hago es ir a mi archivo de rutas. Encuentro la ruta que quiero pre-renderizar y simplemente añado pre-render a ella y eso es todo. Acabo de hacerlo, estoy listo. Eso es lo único que necesito hacer. Te preguntas, hmm. ¿Puede ser realmente cierto? ¿Puede ser tan fácil? Bueno, vamos a intentarlo. ¿Puede ser tan fácil? Bueno, vamos a averiguarlo. Así que, uh, tengo esto, uh, especificado ahora. Y lo que eso significa es que durante la construcción, va a prestar atención a eso y construirá un archivo estático para eso. Um, y entonces te voy a mostrar cómo ejecutar una construcción y luego puedes inspeccionarla. Y en Redwood, simplemente ejecutas red yarn, Redwood build, y eso va a, um, hacer todos los pasos necesarios para, para desplegar esto realmente. Esto es realmente lo que sucede durante el proceso de despliegue. Va a través del sitio web. Va al lado de la API. Um, y luego tiene un paso de pre-renderizado. Y durante el paso de pre-renderizado, va a buscar cualquier ruta que haya sido especificada para ser pre-renderizada y las va a renderizar. Así que vamos a ver el directorio web disc. Ahí es donde, esto, el sitio web de esto termina. Y puedes ver que está el índice, está el favicon. Están las cosas normales están los archivos estáticos. Aquí es donde vive el JavaScript. Aquí es donde vive el CSS. Todo está dividido en webpack, ¿verdad? Hicimos todo eso por ti. Toda la división de code y todo sucede a través de ese mecanismo. Y luego tenemos una página splash dot HTML, y podemos ver que este es el texto que vemos aquí. Mi ruta por defecto es etcétera. Y aquí está el enlace a mí con el botón splash.

Pero mira esto, botón, botón splash, ¿verdad? No hay JavaScript. En esta página, porque es estática, no va a haber JavaScript. La expectativa es que no hay JavaScript en este punto. Pero lo que queremos ser capaces de hacer es hidratar esa página después de que el HTML se haya cargado y tengas el contenido en tu navegador y luego superponer sobre él usando la hidratación de React, la funcionalidad.

Así que veamos si podemos hacer que funcione. Bueno, puedo mostrarte cómo funciona esto yendo al directorio web dist. Y simplemente voy a ejecutar serve, que es solo un servidor web. Va a poner eso en marcha. Va a copiar la URL en mi portapapeles. Y me va a enviar a mi aplicación. Y, como era de esperar, la página de inicio no funciona porque es una aplicación completa y no hay back end. Y el error aquí es que no puedo encontrar mi GraphQL. OK, eso lo esperábamos. ¿Pero qué pasa si vamos a la página splash? Ah, tenemos nuestro contenido. De hecho, tenemos nuestro contenido. Y ahora quiero mostrarte que es real apagando JavaScript. Así que acabo de hacer eso. JavaScript está actualmente apagado. Así que cuando presiono este botón, no pasa nada porque no hay JavaScript en esta página. ¿Pero qué pasa si vuelvo a encender JavaScript? Verás que se recargó. Te demostraré que se recargó. Y ahora boom, sigue siendo dinámico porque cargó el HTML y luego cargó react y lo superpuso. Y eso es una cosa hermosa. Así es como puedes obtener una página pre-renderizada generada estáticamente que aún puede ser dinámica, pero obtienes todos los beneficios del SEO porque esto es lo que Google está obteniendo aquí. Google va a ver esto. Así que si tienes preocupaciones de SEO en las páginas de marketing, entonces quieres pre-renderizar eso. Es una palabra, una palabra en tu archivo de anuncios.

Recuerda esta ridícula pantalla que monté antes, Redwood tiene una solución para cada una de estas cosas. Todo lo que está en la aplicación proveedores de authentication desde Auth0 hasta Netlify. A muchos otros, un montón de objetivos de despliegue, incluyendo Netlify y Vercell y render y la capacidad de desplegar tu lado API a AWS. Tenemos mucho más en marcha para hacerte la vida fácil. El punto principal de Redwood es que hacemos la hermosa integración por ti para que puedas concentrarte en tu producto y en lo que hace valioso a tu negocio. Si quieres algunas pegatinas, puedes conseguirlas en el sitio web. Te las enviaremos gratis a cualquier parte del mundo. Estoy muy contento de que te hayas unido a mí hoy. Y espero que te unas a nuestra community y encuentres esto realmente útil. Completamente de código abierto, licencia MIT, gratis para que lo uses. Hacemos esto para intentar hacerte la vida más fácil. Gracias por ver.

Entonces, estás preguntando a todos, ¿qué tipo de infraestructura utilizas para desplegar tus web apps? Y parece que Virtualizado ganó. Es el más votado. Y después de eso, le sigue Contenedor, que es render, begin, fargate, Cloud Run. Y en tercer lugar está JAMstack. Tengo que admitir que en mi opinión, estoy usando Virtualizado. Simplemente porque puedo tener acceso a la máquina virtual. Pero, ¿qué piensas sobre esos votos? Creo que esto es realmente interesante también porque no hay un claro ganador. No hay uno que realmente domine super a los demás. Y creo que eso es super interesante.

Entonces, un hecho interesante sobre Redwood, cuando comencé a trabajar en él, realmente se imaginó que sería un marco de aplicación web de pila completa para el Jamstack. Pero a medida que hemos estado trabajando en él, hemos descubierto que exactamente estos resultados son algo así como el caso de cómo la gente está pensando y operando. Y así necesitamos ajustar nuestra página de inicio y nuestro marketing ahora. Pero realmente, el objetivo es apuntar a todos estos por igual y seguirte a donde quieras ir. Y dependiendo de tu aplicación y cuáles son tus casos de uso, podrías elegir diferentes por diferentes razones. Como podrías elegir ir a Netlify por la facilidad de despliegue. Y es tan simple. Pero podrías necesitar más control. Podrías necesitar ciertas cosas alrededor de un enfoque contenerizado o simplemente virtualizar directamente en easy to para que tengas control total. Y Redwood está feliz viviendo en todos ellos. No hay bloqueo de proveedor. No somos específicos a ningún proveedor dado. Y tratamos de hacerlo realmente fácil y tener despliegues incorporados para muchos de estos. Donde simplemente dices Redwood, yarn Redwood deploy, le das un objetivo y haremos la mayor parte del resto por ti. Tendrás que tomar algunas decisiones, pero tratamos de hacer que Redwood sea fácil.

Oh, genial. Si vamos a hablar más de dos minutos teniendo esta diapositiva, oh, creo que va a estar distribuido equitativamente para los primeros tres lugares. Entonces, sí, es bastante obvio. Parece que veo tres, veo dos o como visualizado uno. Pero como dijiste, está cambiando según tus necesidades, ¿verdad? Sí, veamos. ¿Cuáles son las preguntas? Déjame tomar un par de ellas de las que teníamos teníamos muchas preguntas para ti, eso es seguro. La primera viene de Dermo Hamad. Está diciendo, ¿cuál es la diferencia, la principal diferencia entre Redwood y BlitzJS? Sí, esa es una excelente pregunta. Creo que Redwood y Blitz ambos viven en un espacio similar, ambos estamos tratando de ser marcos de aplicación web de pila completa que están en la cima de JavaScript typescript. Creo que una de las grandes diferencias que verás es que Blitz se basa en Next. Han utilizado eso como un punto de partida para construir la funcionalidad adicional de donde Redwood no hemos construido realmente en algo que sea tan sofisticado como Next. Así que, por ejemplo, hacemos nuestros propios enrutamientos. Tenemos una solución de enrutamiento personalizada que te permite poner todas tus rutas en un solo archivo. Algunas de estas cosas están inspiradas en lo que realmente me encantaba de rails. Y eso fue un gran punto para mí, fue la simplicidad de la capa de enrutamiento y cómo eso te permitía rastrear tu code trivialmente. Y también nos da mucha más flexibilidad en torno a cómo queremos abordar la situación en general. Creo que Blitz ha sentido esto un poco. Han tenido que bifurcar Next para hacer algunas de las cosas que quieren hacer. Así que supongo que nuestras elecciones de cuál era nuestro punto de construcción base es un poco diferente. Y eso se expresa de diferentes maneras. De alguna manera, es realmente beneficioso para Blitz tener una base tan sólida para trabajar y obtienes todas las cosas que Next ya tiene de serie, que hemos tenido que pensar realmente en construir desde cero. Pero a mí, realmente me gusta eso. Me gusta tener una pizarra más en blanco para trabajar. No me gusta estar limitado por algunas de estas elecciones. Otra gran cosa es que usamos una capa de GraphQL muy específicamente para hablar desde el front end hasta el back end. Y sé que mucha gente se preguntaba sobre eso.

Y una de las razones más grandes por las que hacemos eso es porque hemos imaginado a Redwood como un marco multi-cliente, de modo que se convierte en algo más que solo un marco de aplicación web. Se convierte en un marco multi-cliente. Entonces, a menudo cuando comienzas a trabajar en un nuevo producto, vas a empezar con una aplicación web, eso es bastante normal. Y nos encanta React para eso en el front end. Y luego, decidirás, oh, necesito una aplicación móvil. Y en ese punto, lo que usualmente sucede con marcos como Rails o si estabas usando Blitz, esto puede suceder. Entonces dices, OK, bueno, necesito que mi cliente hable con mi back end. Así que ahora supongo que reimplementaré algún tipo de API para que pueda hablar desde mi aplicación móvil a mi back end. Y ahora estás duplicando trabajo que ya has hecho antes. Y entonces lo que dijimos es, comencemos con la suposición de que vas a ser multi-cliente o eventualmente querrás ser multi-cliente y crea la abstracción entre el front y el back end y usa un protocolo que es realmente eficiente, muy conocido. Hay clientes para todo lo que quieras interfaz con de modo que cuando decidas que quieres hacer una interfaz de línea de comandos para tu proyecto, ¿adivina qué? Tu aplicación ya es solo una API de GraphQL en el back end. Y entonces no hay trabajo adicional que hacer. Ya está completamente diseñado desde el principio para servir a un cliente que termina siendo algo abstracto. Pero todavía tienes control total sobre eso. Estás construyendo la API de GraphQL tú mismo. Así que tienes tanto la flexibilidad de GraphQL en sus mejores partes, pero también la flexibilidad para usarlo en múltiples clientes. Esa es realmente la esencia de por qué elegimos GraphQL para eso. Así que esas son dos de las grandes diferencias. Y, por supuesto, hay muchas. Nuestro enfoque para muchas cosas es ligeramente diferente. Es solo diferente. Ambos pensamos de manera diferente sobre las cosas. Y te animo a explorar ambos para ver cuál podría servir mejor a tu caso de uso.

Es, sí, es realmente fantástico. Quiero decir, tomaste inspiration de Ruby on Rails, que también tiene generadores, tu Redwood JS también tiene generadores. Tienes servicios como la capa que se comunica con cosas y el backend. Es fantástico.

Tengo una pregunta. Ya que también tocaste la parte de Next.js, la pregunta de Vlad F es ¿cómo maneja Redwood el SSR? Ya que Next.js maneja SSR, ¿cómo maneja Redwood JS el SSR? Sí, creo que Next se ha hecho un verdadero ganador en esta área. Así que pregunta súper relevante. Estas son preguntas que hemos tenido que reimaginar desde una perspectiva de Redwood, pensando en lo que realmente tratamos de hacer es pensar desde los primeros principios. ¿Qué necesitas como desarrollador de aplicaciones? Y así es como empezamos a pensar realmente en estos problemas desde cuál es el problema que tienes y cómo puede Redwood resolverlos para ti de la manera más elegante posible? En la charla, mostré nuestro soporte de pre-renderizado. Así que eso es una parte de lo que SSR podría hacer por ti. Tienes este problema donde necesitas tener contenido generado que no quieres generar en tiempo de construcción, pero te gustaría tenerlo almacenado en caché y servido. Y podrías hacer eso por varias razones. Una de esas razones podría ser porque necesitas tener etiquetas OG y soporte para eso. Y así es donde pre-renderiza. El pre-renderizado es solo la primera de muchas características que caen en una categoría que llamamos Redwood a scale. Porque todas estas cosas, si piensas en ellas, todas estas estrategias, cosas como SSR son realmente sobre almacenamiento en caché. Realmente son sobre performance a scale. Y eso casi siempre se reduce a alguna forma de almacenamiento en caché. Y así es como pensamos en el almacenamiento en caché en Redwood, el pre-renderizado es la primera implementación que hemos comenzado en ese camino, donde decimos, ¿qué necesitan a menudo las personas? Necesitan la capacidad de generar estáticamente páginas de marketing, porque no hay razón para hacerlas dinámicamente. Pero también sería bueno si pudieran ser rehidratadas para que cualquier pequeño bit de interactividad en la página siga funcionando. Y eso es lo que es pre-renderizar. Y como viste, fue una sola palabra para habilitar eso en múltiples plataformas de implementación diferentes. Y eso es realmente lo que queremos hacer con el resto. Así que eventualmente tendremos soluciones para algo que se parece un poco más a SSR o viste hoy que Netlify acaba de salir con su solución para esto que mantiene la atomicidad alrededor de las implementaciones y puede hacerlo mucho más fácil de razonar. Así que aprovecharemos esas cosas en estas diferentes plataformas y las haremos realmente fáciles de interactuar con ellas con la esperanza de hacer el menor trabajo posible mientras tanto. Así que nuestros enfoques serán diferentes creo que Next. Se verán un poco diferentes. Pero van a estar realmente específicamente dirigidos a resolver problemas que los desarrolladores de aplicaciones web tienen en la implementación y la parte de scaling del desarrollo de aplicaciones.

Genial. Imagine Wagons se pregunta ¿qué pasa con TypeScript? Sí, tenemos soporte para TypeScript por lo que puedes decirle a Redwood que te genere una plantilla de TypeScript en lugar de una plantilla de JavaScript. No está del todo terminado. Podrías hacerlo bien, quiero decir, puedes hacerlo. Puedes tener una versión de TypeScript. Y es gracioso que para hacer eso ahora, todavía estamos trabajando en la interfaz para esto. Para hacerlo ahora, en realidad pasas una bandera de guión guión no guión JavaScript, lo que podría parecer un poco extraño. Pero es porque la plantilla en realidad ya está en TypeScript. Y la compilamos a JavaScript para la versión de JavaScript. Pero aún no tenemos una tipificación completa de TypeScript en toda la aplicación. Y vamos a suavizar eso. 1.0 se lanzará con soporte completo para TypeScript de la manera que esperas. Hablando de 1.0, Redwood aún no ha lanzado la versión 1.0. ¿Cuándo sucederá eso? Estamos cerca. Resulta que construir un marco de aplicación web framework es más trabajo del que esperaba. Ya esperaba que fuera mucho, pero en realidad es mucho más de lo que incluso anticipé. Así que nos ha llevado un poco más de tiempo del que esperábamos, pero es porque realmente creemos firmemente que necesitas un cierto conjunto de características para ser considerado 1.0 para un marco de aplicación de pila completa framework en estos días. Y queremos asegurarnos de que todo esté allí y que puedas confiar en ello y confiar en ello y que no habrá sorpresas y no vamos a romper un montón de cosas después. Y por lo tanto, esperamos hacer un candidato a la liberación para 1.0 en los próximos meses. Creo que eso es totalmente realista. Realmente estamos en el último conjunto de características que necesitamos trabajar. Hay algunas cosas alrededor de asegurar la API de GraphQL de una manera realmente fácil en la que estamos trabajando ahora, soporte completo de TypeScript de principio a fin y un par de otras cosas. Pero realmente, hemos eliminado la mayoría de las cosas grandes que queríamos allí. Así que esperaría un RC1 en los próximos meses y luego un 1.0 probablemente vendrá a mediados de año. Tomará unos meses pasar por los RCs y asegurarse de que es realmente estable. Hay errores que corregir a medida que más personas comienzan a usarlo y lo prueban en diferentes entornos y cosas. Así que probablemente serán otros cinco, seis meses antes de que se lance un 1.0 en este punto. Pero es bastante estable. Y si revisas nuestras notas de lanzamiento, dedicamos un gran esfuerzo a nuestras notas de lanzamiento, asegurándonos de que sabes exactamente lo que necesitas hacer para actualizar. Y puedes mirar atrás y ver cómo hemos estado haciendo eso. Y es muy fácil seguir la ruta de actualización. Así que puedes empezar ahora mismo. Es bastante sólido en la mayoría de los aspectos. Y sabes que tendrás una ruta de actualización realmente suave en el camino hacia 1.0. Genial. Muchas gracias, Tom. Gracias por compartir todo sobre Redwood.js. Ha sido un placer tenerte aquí. De nuevo, muchas gracias por tomarte tu tiempo. Fue una gran sesión de preguntas y respuestas, pero también una gran charla. Gracias. Y adiós. Adiós. Gracias. Muchas gracias por invitarme. Lo aprecio.