RedwoodJS: El marco de aplicaciones React de pila completa de tus sueños

Rate this content
Bookmark

¿Cansado de reconstruir tu marco web basado en React desde cero para cada nuevo proyecto? ¡Estás de suerte! RedwoodJS es un marco de aplicaciones web de pila completa (piensa en Rails pero para desarrolladores de JS/TS) basado en React, Apollo GraphQL y Prisma 2. Nosotros hacemos el trabajo de integración pesado para que no tengas que hacerlo. También integramos de manera excelente Jest y Storybook, y ofrecemos soluciones incorporadas para la obtención declarativa de datos, autenticación, pre-renderizado, registro, a11y y mucho más. Implementa en Netlify, Vercel o ve a la antigua en AWS o metal desnudo. En esta charla aprenderás sobre la arquitectura de RedwoodJS, verás las características principales en acción y te irás con una sensación de asombro y admiración en tu corazón.

43 min
14 May, 2021

Video Summary and Transcription

Redwood JS es un marco de aplicaciones React de pila completa que simplifica el desarrollo y las pruebas. Utiliza una estructura de directorios para organizar el código y proporciona una fácil obtención de datos con celdas. Redwood elimina el código repetitivo e integra Jest y Storybook. Admite el pre-renderizado y proporciona soluciones para la autenticación y la implementación. Redwood es un marco multiplataforma que permite construir aplicaciones web y móviles sin duplicar el trabajo.

Available in English

1. Construyendo una aplicación web con React, Prisma y más

Short description:

Para hacer una aplicación web, necesitaré React, Prisma, Apollo, Jest, Storybook, Webpack, Babel, autenticación (probablemente Auth0), autorización, registro, división de código, etiquetas OG, pre-renderización y accesibilidad. Comencemos con Create React App y luego aprendamos Prisma.

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 comunicarme con una base de datos. Voy a necesitar Apollo para comunicarme desde el frontend hasta el backend.

Voy a necesitar Jest para poder escribir algunas pruebas. Voy a necesitar Storybook para poder diseñar código 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.

Eso es la aplicación web, pero voy a necesitar averiguar cómo implementar esta cosa. Tal vez pueda ir a Netlify. Les gusta mucho Jamstack. Tal vez pueda ir a Vercel. Tienen un logotipo genial en forma de triángulo. ¿Qué tal render? Tal vez pueda usar containers y obtener solicitudes de larga duración y suscripciones a GraphQL. O tal vez necesite todo el poder de AWS. Aún no he decidido.

En cualquier caso, voy a necesitar algún tipo de autenticación para poder usar Auth0 para eso. No voy a escribir el mío propio. Pero tengo que ir más allá de eso. También necesito autorización. Así que voy a necesitar controles de acceso basados en roles. ¿Y qué pasa con el registro? Voy a necesitar un registro realmente bueno que se envíe al proveedor de mi elección.

Voy a tener que dividir el código de esta cosa para que el navegador no reciba demasiado código de una sola vez. Voy a necesitar etiquetas OG, para que esto se despliegue en Twitter y Facebook. Probablemente necesite pre-renderización para hacer eso. Y voy a necesitar accesibilidad desde el principio. Esta cosa funciona en lectores de pantalla.

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

Muy bien. Google, mi viejo amigo, crea una aplicación react. De acuerdo, ahí estás. ¿Qué es esto? Ahí vamos. Lanzar. CX. Crear una aplicación react. Muy bien. ¿Cómo debo llamar a esta cosa? Gloobnox? Eso funciona. Muy bien, dejemos que haga su trabajo por un tiempo. Aprendamos cómo usar Prisma. De acuerdo, Prisma, aquí vamos. No. No ese. No. Tampoco ese. ¡Ajá! Te encontré. Sí. Aquí vamos.

2. Introducción a Redwood JS y Estructura del Proyecto

Short description:

Estoy aquí para hablarles sobre Redwood JS, el framework de aplicaciones React de pila completa. Una aplicación Redwood se divide en dos partes: el lado web con React y el lado API con GraphQL y Prisma. Veamos algo de código. Tengo una aplicación de lista de tareas simple escrita en Redwood. He inicializado la base de datos y puesto en marcha el servidor web. Puedo agregar y alternar elementos en mi lista de tareas, todo a través de GraphQL. La estructura del proyecto incluye carpetas separadas para web y API dentro de un monorepo.

Documentación de Prisma. Inicio rápido. Muy bien. En esta página aprenderás cómo enviar consultas a, ok, genial. Muy 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 tus sueños.

Ahora, sé lo que estás pensando. ¿Quién es este payaso que me dice qué hacer? Bueno, soy Tom Preston Werner. Puedes encontrarme en línea, como 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 en realidad, cuando escribo una aplicación, quiero preocuparme por GraphQL y no tanto por las complejidades de Apollo. Y tampoco 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. Permíteme escribir código. Eso es lo que hago.

Entonces, una aplicación Redwood se divide 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. Estas cosas ocurren localmente, pero conceptualmente forman 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 necesites que haga. En el medio tienes GraphQL que se comunica de ida y vuelta. Y GraphQL es cómo haces consultas y también cómo especificas las consultas y mutaciones que van a ocurrir. Pero basta de charla, veamos algo de código. Aquí tengo abierto en la derecha GitHub.com/RedwoodJS/example/todo. Esta es una aplicación de lista de tareas simple escrita en Redwood que pensé en mostrarte algunas cosas y mostrar cómo funciona Redwood y cómo piensa en el mundo. Así que he clonado esto en mi máquina local. He ejecutado Yarn, puedes ver las instrucciones aquí. Y he inicializado la base de datos. Así que está todo listo, listo para empezar. 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 frontend y el backend, los vincula y abre una nueva ventana del navegador con mi lista de tareas. Así que te mostraré cómo funciona. Puedo decir que necesito comprar leche, queso y huevos. Y puedo alternar estas cosas. Esto se comunica con el backend a través de GraphQL. Puedes ver aquí en los registros, las publicaciones en el backend de GraphQL. ¿Cómo funciona eso? Bueno, en el editor aquí, verás la carpeta web y la carpeta API. Esta es una estructura de monorepo. Así que son paquetes separados dentro de un solo repositorio de Git. Así que empecemos por donde todo comienza, que son las rutas.

3. Redwood Routes, Pages, and Cells

Short description:

En el archivo de rutas, tenemos un enrutador con rutas para la página de inicio y una página no encontrada. Redwood utiliza una estructura de directorios que facilita encontrar las cosas. La página de inicio es un componente React estándar que utiliza componentes de estilo. El concepto de celdas de Redwood simplifica la obtención de datos de GraphQL exportando variables y estados como componentes. Las celdas organizan el código en torno a la obtención de datos y eliminan la necesidad de lógica condicional. En el backend, Redwood divide la aplicación en servicios. Cada servicio tiene su propio archivo SDL que define el esquema, las consultas y las mutaciones. Redwood une estos archivos para presentar una API de GraphQL unificada.

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 básicamente el 404. Así que esta es nuestra página de inicio. Y en Redwood, tenemos otro directorio para las páginas. Es muy fácil encontrar las cosas, muy organizado, la estructura de directorios.

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

Ahora, Redwood tiene un concepto realmente especial llamado celdas, y las celdas son una forma de obtener tus datos de GraphQL de manera declarativa. Así que veamos eso. To-doListCell está en la carpeta componentes, to-doListCell. Así que componentes de origen, to-doListCell. Y aquí está el archivo. Y cómo funciona esto es simplemente exportas un conjunto de variables desde aquí, constantes, incluyendo la consulta. Así que comienzas con tu consulta de GraphQL, simplemente la escribes aquí como una consulta de GraphQL o también podrías tener una mutación aquí, 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 error y un estado vacío. Aquí, simplemente he hecho un estado de carga. Simplemente dice `cargando`. Y un estado de éxito. Y lo que hace esto es realmente simplificar y centrarte en lo que estás construyendo. Así que en este caso, cuando esta consulta se completa, cualquiera que sea el nombre de la consulta, la consulta de GraphQL que estás haciendo, en este caso, to-dos, se enviará como una variable, como un parámetro en el componente de éxito. Y luego dentro de eso, puedes hacer tu trabajo. Así que esto está haciendo una actualización optimista de la que no tienes que preocuparte demasiado para Apollo. Pero aquí mismo, puedes ver que simplemente toma los to-dos y los mapea y crea elementos de lista de tareas que representan cada uno de estos elementos aquí. Y eso es lo que son las celdas. Así que realmente es una forma sencilla de pensar en la obtención de tus datos, para que no tengas que hacer mucha lógica condicional. Realmente organiza el código en torno a eso.

Ahora, cuando llegas al backend, al lado de GraphQL, veamos cómo se ve eso. Así que aquí está la consulta to-dos. Voy a buscar en el lado de la API aquí. Voy a buscar en origen, GraphQL, y to-dos. Ahora a esto lo llamamos servicios. Así que divides tu aplicación Redwood en diferentes servicios. Esta aplicación es muy sencilla. Solo tiene un servicio, este servicio de to-dos. En una aplicación más grande, podrías dividirla en diferentes servicios para las diferentes responsabilidades que tiene tu aplicación. Así que aquí vemos un archivo SDL que está definido en un archivo JavaScript. Y aquí está el SDL. Así que si has escrito GraphQL antes, esto debería ser muy familiar. Esto es SDL estándar, el lenguaje de definición de esquemas. Y aquí estamos definiendo un objeto de tarea y consultas y mutaciones. Y lo bueno es que cada servicio puede tener uno de estos archivos, y todos pueden ser separados, y Redwood se encargará de unirlos y presentarlos al mundo. Así que busquemos lo que estábamos hablando. To dos va a devolver una matriz de elementos de lista de tareas, 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 hacerlo, y todos terminan en el mismo archivo, y puede parecer muy desordenado.

4. Redwood Implementation and Testing

Short description:

En Redwood, hemos eliminado el código repetitivo al hacer coincidir las cosas por su nombre. El directorio de servicios contiene la implementación y el resolvedor para las consultas de GraphQL. Utilizamos Prisma para las operaciones de base de datos, como encontrar muchos registros. Redwood incluye un entorno de pruebas de GraphQL para facilitar la exploración y el testing. El código necesario para la comunicación entre el frontend y el backend es mínimo.

Se siente como mucho código repetitivo. Así que hemos eliminado todo eso en Redwood y hemos decidido hacer coincidir las cosas por su nombre. Por lo tanto, si entras en el directorio de servicios y miras los servicios, to-do's, to-dos.js, lo que verás aquí es una constante, to-dos, que tiene el mismo nombre que la consulta GraphQL y se exporta. Redwood es lo suficientemente inteligente como para hacer coincidir eso y decir que esta es la implementación. Este es el resolvedor para esa llamada GraphQL. Y en él, vamos a utilizar Prisma, que simplemente importamos aquí. DB representa la base de datos de Prisma. Y ahora podemos hacer cualquier llamada a Prisma en eso. En este caso, simplemente estamos haciendo un find many. Así que una forma realmente divertida de explorar eso, como ya debes estar acostumbrado, es con un entorno de pruebas de GraphQL, y Redwood, por supuesto, viene con uno de esos, y estará 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 la ejecutamos, 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 la comunicación entre el frontend y el backend.

5. Implementando la página de conteo

Short description:

Vamos a implementar una página de conteo que muestre el número de tareas pendientes. Redwood nos permite generar esta página fácilmente. Crea los archivos necesarios, como la ruta, la página de conteo, el archivo de historias y la prueba. Podemos ver la página generada en /conteo y cualquier cambio realizado se reflejará de inmediato en el sitio web.

Muy bien, eso es genial. Dices, ¿qué tal hacer esto desde cero? Tenerlo todo ahí ahora mismo 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 muestre el número de tareas pendientes. Tal vez algo más lo necesite por alguna razón. Es algo simple de implementar. Así que tenemos la capacidad de generar ciertas cosas en Redwood. Así que voy a ejecutar Redwood, perdón, Yarn, Redwood generate o simplemente G para abreviar, página, y lo llamaré página de conteo. Voy a ejecutar eso. Y lo que veré aquí ahora en mi archivo de rutas es que se ha generado una nueva ruta slash conteo, toma eso de lo que he escrito aquí. Y ha creado una página de conteo para mí. Así que vamos a ver esa página de conteo. También está creando un archivo de historias para storybook. Esto está integrado de serie. Y una prueba. Esta es solo la prueba. Así que estamos integrando perfectamente todos estos elementos diferentes. Ahora mismo podemos ir a ver esto en slash conteo. Y aquí vamos. Esto es solo la página generada, es así como se ve. Si realizamos cambios aquí, se reflejarán de inmediato en el sitio web. Así que puedes ir y venir de manera muy, muy sencilla y hacer esto.

6. Implementando la obtención de datos y creando una Celda

Short description:

Ahora cambiemos al lado de la API y modifiquemos el archivo SDL para crear una nueva consulta GraphQL llamada 'conteo de tareas pendientes'. Lo implementaremos en el archivo de servicios to-do's JS. Después de agregar dos líneas de código, la infraestructura de GraphQL está lista para que el front-end consuma los datos en la página de conteo. Para obtener los datos, crearemos una celda usando el comando 'yarn Redwood generate cell'. Corregiremos la consulta GraphQL generada y definiremos los estados de carga, vacío, error y éxito. Finalmente, utilizaremos la celda en la página de conteo importándola.

De acuerdo, muy bien. Ahora necesitamos obtener algunos datos del back-end. Así que cambiemos al lado de la API ahora. Vamos a modificar nuestro archivo SDL para crear una nueva consulta GraphQL. La llamaremos 'conteo de tareas pendientes' y siempre devolverá un número entero. Tengo instalada una extensión de Redwood en VS Code que hace algunas cosas interesantes. Aquí puedes ver que me indica que este servicio no está implementado. No tengo una implementación para esta consulta específica. Esto es muy útil, ya que hacemos algunas cosas automáticamente por ti, también queremos ayudarte a ver cuando algunas de esas cosas automáticas no funcionen correctamente.

Entonces esto no está implementado. Bueno, vamos a implementarlo. Esto está en el archivo de servicios to-do's JS, vamos a crear algo llamado 'conteo de tareas pendientes'. Lo haremos aquí mismo. Exporta 'const to-dos count'. Será una función y simplemente será 'db.to-do.count'. Muy bien, veamos si funcionó. Deberíamos poder ejecutarlo y ver si funcionó. Y aquí vamos. ¡Muy bien, ahí lo tenemos! Añadí dos líneas de código y creé toda la infraestructura de GraphQL necesaria para que el back-end funcione. Así que ahí lo tenemos, una nueva consulta GraphQL definida, lista para devolver algunos datos y ser consumida por el front-end en esta página de conteo.

Bueno, vamos a necesitar una celda. Estamos obteniendo datos, así que necesitamos una celda. Así que creemos una celda. 'Yarn Redwood generate cell todos.count'. Dejemos que se ejecute. Y vamos a encontrar esto en 'components/todos.count/cell' aquí mismo. Ahora se ha generado esto y ha adivinado lo que voy a escribir como consulta GraphQL, pero está un poco equivocado. Vamos a corregirlo. Simplemente será 'todos.count'. Así. El estado de carga está bien. El estado vacío, esto es de lo que hablaba antes. Estos están predefinidos. Solo los cambiamos como queramos, y el estado de error será un estado de fallo por defecto. El estado de éxito simplemente hará una conversión a JSON de lo que salga de aquí, que será solo un número entero. Y eso está bien por ahora. Nos gusta eso. Y ahora vamos a usar esto en la página de conteo. 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 lo estamos usando. Así que importa 'todos.count cell' de 'source/components/todos.count cell'.

7. Desarrollo de Redwood y Integración de Storybook

Short description:

Redwood facilita el desarrollo de una aplicación de pila completa de principio a fin, con solo unas pocas líneas de código y comandos de generador. También proporciona integración con Storybook, lo que permite visualizar y probar fácilmente los componentes. Redwood simplifica la simulación de obtención de datos en Storybook, lo que facilita el trabajo con celdas y la visualización de componentes sin preocuparse por la simulación de datos. Redwood elimina el código repetitivo, integra Jest y Storybook, y elimina la necesidad de configurar manualmente Webpack y Babel. Deja que el framework se encargue de las tareas pesadas para que puedas centrarte en tu lógica empresarial.

Y si volvemos aquí antes de guardar esto, ahí vamos. Y eso es realmente todo. Hicimos todo eso en un par de minutos. Si no estuviera hablando tanto, podría haberlo hecho mucho más rápido, pero eso es de principio a fin, desde el lado de React hasta GraphQL, hasta el lado del servidor, Prisma, la base de datos, todo con solo unas pocas líneas de código, unos pocos comandos de generador, y así de fácil intenta hacer Redwood 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 ejecutar el servidor de Storybook, voy a ejecutar 'yarn Redwood storybook'. Eso tomará unos segundos en iniciarse. Y cuando termine, se abrirá esta página y verás aquí tenemos las historias de Storybook para las cosas que he generado. Tenemos la página de conteo, que se está generando, y mira esto. En realidad tiene algunos datos para el conteo que está regresando, pero eso es interesante. 42, ¿de dónde vino eso? Y ¿por qué dice ID ahí? Eso es un poco extraño.

Bueno, la razón por la que eso está sucediendo es que lo está obteniendo de aquí. Entonces, la página de conteo está obteniendo todo de esta celda de conteo. Y una de las cosas que hacemos por ti, si estabas prestando atención aquí cuando creamos esto y entré en este directorio, verás este archivo de simulación. Este archivo de simulación hará que sea muy fácil ver tus celdas en Storybook, porque simular la obtención de datos en Storybook es uno de los verdaderos desafíos para que Storybook funcione realmente bien con tu aplicación. Nuevamente, Redwood intenta hacerlo muy fácil para ti. Y así, tenemos el concepto de simular la obtención de datos. Y en este caso, simplemente hemos dicho que creemos que 'todos.count' va a devolver un objeto con un ID. Puede que recuerdes que eso fue lo que adivinamos que ibas a hacer. Pero es muy fácil entrar aquí y decir, Oh, en realidad solo devuelve 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á. Entonces, todos estos componentes pueden usar estas simulaciones, las celdas. Y eso significa que cuando tienes una página o tienes una celda o componente que tiene una celda en él, cada vez que tengas uno de esos, si lo usas en tu Storybook, está bien. Simplemente va a tomar estos datos simulados y los incluirá. Así que todavía es muy fácil visualizar tus componentes y trabajar con ellos sin la molestia de tener que pensar en cómo simular esos datos. Y nuevamente, ahora puedes trabajar fácilmente en los estados de carga de estas cosas. La celda 'todos.count' tiene varios estados. Tal vez quiera que mi estado de carga simplemente diga, solo espera. Puedo guardar eso. Y ahora, en lugar de intentar estar en mi aplicación y hacer clic en actualizar y preguntarme, oh, ¿se ve bien? Oh, lo veo. Está ahí por, ya sabes, cien milisegundos o algo así, incluso menos. Eso es un poco molesto. Puedo ir a mi inspector y hacer que mi página sea realmente lenta. Eso es molesto. Pero por eso tenemos Storybook. Ahora puedo entrar aquí y mirarlo todo el tiempo que quiera. Y puedo hacer que funcione. ¿O qué aspecto tiene el estado vacío? ¿Qué sucede cuando ocurre un error? Si quiero que ocurra un error en mi aplicación, tengo que ir a mi implementación, probablemente, y agregar algún tipo de error de sintaxis para que arroje algún tipo de error. No juegues con eso. Por eso tenemos Storybook y Redwood se trata de hacer todo el proceso de desarrollo de la aplicación de principio a fin lo más fluido posible con la menor cantidad de trabajo, la menor cantidad de código repetitivo que podemos hacer para ti. Hemos pasado tantas horas reduciendo el código repetitivo y haciendo integraciones de estos productos. Integrando Jest, integrando Storybook, eliminando Webpack. Te darás cuenta de que aquí realmente no ves Webpack en absoluto. No ves a Babel en absoluto. Por supuesto, tenemos algunos archivos de configuración por si necesitas 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 framework haga el trabajo pesado por ti para que puedas centrarte en tu lógica empresarial. Bueno, ¿qué más puede hacer Redwood por ti? Bueno, me gustaría mostrarte algo que lanzamos recientemente.

8. Pre-renderización de páginas en Redwood

Short description:

La pre-renderización te permite construir y renderizar páginas en tiempo de compilación, enviándolas estáticamente. En Redwood, es tan fácil como agregar 'pre-render' a la ruta en el archivo de rutas. Durante el proceso de compilación, Redwood generará archivos estáticos para las rutas pre-renderizadas. Para ejecutar una compilación en Redwood, utiliza el comando 'yarn Redwood build'. Las páginas pre-renderizadas estarán disponibles en el directorio 'web dist', junto con los archivos JavaScript y CSS.

Eso es la pre-renderización, la capacidad de tomar cualquiera de tus páginas y especificar que se construyan en tiempo de compilación, que se rendericen en tiempo de compilación y luego se envíen estáticamente. ¿Cómo va a funcionar eso? Bueno, digamos que tienes una página de presentación, algún tipo de página de marketing que realmente no tiene mucho contenido dinámico y solo quieres renderizarla en tiempo de compilación y hacerla disponible. Así que hagámoslo. Creemos una página que sea realmente estática. Puedo ejecutar 'yarn redwood generate page', simplemente la llamaré 'splash', y obtendremos esa página de presentación y vayamos a ella aquí para que podamos verla. Y encontremosla, 'web source', 'pages', 'splash page', y aquí vamos a hacer esto bastante simple. Vamos a usar este contenido, pero lo que quiero mostrarte es cómo 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 'onclick' que simplemente será una función que muestre una alerta, hola. Y lo llamaremos 'splash' porque eso es lo que ya se llama. Y veremos que ahora tenemos un error para deshacernos de ese chico. OK, ahora cuando presiono esto, dice hola. OK, eso es lo esperado. Todo esto es dinámico. Si desactivas JavaScript en este modo, esta es la aplicación de página única completamente dinámica. Puedo desactivarlo. Tengo un pequeño botón para desactivar JavaScript aquí. Voy a hacer clic en él y verás que ya no hay página, obviamente, porque React está montando todo. Todo el HTML proviene de JavaScript y React y eso no siempre es lo que queremos por razones de SEO, por razones de rendimiento. Hay muchas razones por las que podríamos querer generar estas cosas en tiempo de compilación. Así que lo volvemos a activar 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 compilación? Bueno, déjame mostrarte. Podrías esperar que sea fácil y tendrías razón. De hecho, es fácil en una palabra. Todo lo que hago es ir a mi archivo de rutas. Encuentro la ruta que quiero pre-renderizar y simplemente le agrego 'pre-render' y eso es todo. Eso es lo único que necesito hacer. Estás pensando, hmm. ¿Puede ser verdad? ¿Puede ser tan fácil? Bueno, vamos a probarlo. ¿Puede ser tan fácil? Bueno, vamos a averiguarlo. Así que, uh, ahora lo tengo especificado. Y lo que eso significa es que durante la compilación, prestará atención a eso y generará un archivo estático para eso. Y te mostraré cómo ejecutar una compilación y luego puedes inspeccionarlo. En Redwood, simplemente ejecutas 'yarn Redwood build' y eso hará todos los pasos necesarios para implementarlo realmente. Esto es realmente lo que sucede durante el proceso de implementación. Recorre el sitio web. Va al lado de la API. Y luego tiene un paso de pre-renderización. Y durante el paso de pre-renderización, buscará cualquier ruta que se haya especificado para ser pre-renderizada y las renderizará. Así que veamos el directorio 'web dist'. Ahí es donde termina el sitio web. Y puedes ver que está el índice, está el favicon. Hay cosas normales, hay archivos estáticos. Aquí es donde vive JavaScript. Aquí es donde vive CSS. Todo está fragmentado con Webpack, ¿verdad? Hicimos todo eso por ti. Todo el código se divide y todo sucede a través de ese mecanismo. Y luego tenemos una página 'splash.html', y podemos ver que este es el texto que vemos aquí. Mi ruta predeterminada es etcétera. Y aquí está el enlace a mí con el botón 'splash'.

9. Hidratación de páginas estáticas y beneficios de Redwood

Short description:

Para crear una página pre-renderizada estáticamente que aún pueda ser dinámica, puedes hidratar la página después de que se cargue el HTML utilizando la hidratación de React. Redwood proporciona soluciones para varios aspectos, incluidos los proveedores de autenticación de la aplicación y los objetivos de implementación. Únete a la comunidad de Redwood y disfruta de los beneficios de un framework que simplifica la integración y facilita tu vida.

Pero mira esto, botón, botón de presentación, ¿verdad? No hay JavaScript en esta página, porque es estática, no habrá JavaScript en este punto. Pero lo que queremos hacer es hidratar esa página después de que se cargue el HTML y tengas el contenido en tu navegador, y luego agregar la funcionalidad utilizando la hidratación de React.

Veamos si podemos hacer que funcione. Bueno, puedo mostrarte cómo funciona yendo al directorio 'web dist'. Simplemente ejecutaré 'serve', que es un servidor web. Lo iniciará, copiará la URL en mi portapapeles y me llevará a mi aplicación. Como era de esperar, la página de inicio no funciona porque es una aplicación completa y no hay backend. El error aquí es que no puedo encontrar mi GraphQL. Eso es lo que esperamos. Pero, ¿qué pasa si vamos a la página de presentación? Ah, tenemos nuestro contenido. De hecho, tenemos nuestro contenido. Y ahora quiero mostrarte que es real desactivando JavaScript. Acabo de hacer eso. JavaScript está desactivado actualmente. Entonces, cuando presiono este botón, no sucede nada porque no hay JavaScript en esta página. Pero, ¿qué pasa si vuelvo a activar JavaScript? Verás que se recargó. Lo demostraré. Y ahora boom, sigue siendo dinámico porque cargó el HTML y luego cargó React y lo superpuso. Y eso es algo hermoso. Así es como puedes obtener una página pre-renderizada estáticamente que aún puede ser dinámica, pero obtienes todos los beneficios de SEO porque esto es lo que Google está obteniendo aquí. Google lo verá. Entonces, 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 pantalla ridícula que ensamblé antes, Redwood tiene una solución para cada una de estas cosas. Todo en la aplicación, desde proveedores de autenticación como Auth0 hasta Netlify y muchos otros, una variedad de objetivos de implementación, incluidos Netlify, Vercel y Render, y la capacidad de implementar tu API en AWS. Tenemos mucho más en proceso para facilitarte la vida. El objetivo principal de Redwood es hacer la integración hermosa por ti para que puedas concentrarte en tu producto y en lo que hace que tu negocio sea valioso. 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 hoy. Espero que te unas a nuestra comunidad y encuentres esto realmente útil. Completamente de código abierto, con licencia MIT, gratis para que lo uses. Hacemos esto para intentar facilitarte la vida. Gracias por ver.

QnA

Infraestructura de aplicaciones web y Redwood vs BlitzJS

Short description:

La infraestructura virtualizada es la más votada para las aplicaciones web, seguida por Contenedor y JAMstack. Redwood está diseñado para ser un framework de aplicaciones web de pila completa para varias infraestructuras. Ofrece flexibilidad y fácil implementación, sin bloqueo de proveedores. Abordemos algunas preguntas. La principal diferencia entre Redwood y BlitzJS es que Redwood tiene su propia solución de enrutamiento y ofrece más flexibilidad, mientras que BlitzJS se basa en Next y proporciona una base sólida. Ambos frameworks tienen como objetivo ser frameworks de aplicaciones web de pila completa en JavaScript/TypeScript.

Entonces, estás preguntando a todos, ¿en qué tipo de infraestructura implementas tus aplicaciones web? Y parece que la virtualización ganó. Es la más votada. Y después de eso, le sigue el Contenedor, que es render, begin, fargate, Cloud Run. Y en tercer lugar está JAMstack. Debo admitir que en mi opinión, estoy usando la virtualización. Simplemente porque puedo tener acceso a la máquina virtual. Pero ¿cuáles son tus pensamientos sobre esas votaciones? Creo que esto es realmente interesante también porque no hay un claro ganador. No hay uno que realmente domine al resto. Y eso es muy interesante.

Un dato interesante sobre Redwood, cuando comencé a trabajar en él, realmente se concibió como un framework de aplicaciones web de pila completa para JAMstack. Pero a medida que hemos estado trabajando en él, hemos descubierto que estos resultados son un reflejo de cómo las personas piensan y operan. Y por eso necesitamos ajustar nuestra página de inicio y nuestra estrategia de marketing ahora. Pero realmente, el objetivo es apuntar a todos ellos por igual y seguirte a donde quieras ir. Y dependiendo de tu aplicación y tus casos de uso, es posible que elijas diferentes opciones por diferentes razones. Por ejemplo, puedes optar por Netlify por la facilidad de implementación. Y es tan simple. Pero es posible que necesites más control. Es posible que necesites ciertas cosas en torno a un enfoque de contenedorización o simplemente virtualizar directamente para tener un control total. Y Redwood se adapta a todos ellos. No hay bloqueo de proveedores. No estamos específicamente vinculados a ningún proveedor en particular. Y tratamos de hacerlo realmente fácil y tener implementaciones integradas para muchos de ellos. 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 intentamos que Redwood sea fácil.

Oh, genial. Si vamos a hablar más de dos minutos, tener esta diapositiva, oh, creo que se distribuirá de manera equitativa en los primeros tres lugares. 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. Él dice, ¿cuál es la diferencia principal entre Redwood y BlitzJS? Sí, esa es una excelente pregunta. Creo que Redwood y Blitz viven en un espacio similar, ambos intentamos ser frameworks de aplicaciones web de pila completa que se basan en JavaScript/TypeScript. Creo que una de las grandes diferencias que verás es que Blitz se basa en Next. Han utilizado eso como punto de partida para construir la funcionalidad adicional, mientras que Redwood no se ha construido sobre algo tan sofisticado como Next. Por ejemplo, hacemos nuestro propio enrutamiento. 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 encantó de Rails. Y eso fue algo importante para mí, la simplicidad de la capa de enrutamiento y cómo eso te permitía rastrear tu código de manera trivial. También nos brinda mucha más flexibilidad en 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. Entonces, supongo que nuestras elecciones sobre cuál fue nuestro punto de partida base son un poco diferentes. Y eso se expresa de diferentes formas. En ciertos aspectos, es realmente beneficioso para Blitz tener una base tan sólida en la que trabajar y obtener todas las cosas que Next ya tiene de serie, que hemos tenido que pensar en construir desde cero. Pero para mí, realmente me gusta eso. Me gusta tener una pizarra más en blanco para trabajar. No me gusta que algunas de estas elecciones me limiten. Otra cosa importante es que usamos una capa de GraphQL de manera muy específica para comunicarnos desde el frontend hasta el backend. Y sé que mucha gente se preguntaba sobre eso.

Redwood como un Framework Multiplataforma

Short description:

Redwood es un framework multiplataforma que te permite construir aplicaciones web y móviles sin duplicar el trabajo. Proporciona una abstracción entre el frontend y el backend utilizando GraphQL, que es eficiente y ampliamente compatible. Con Redwood, puedes agregar fácilmente nuevos clientes, como una interfaz de línea de comandos, sin trabajo adicional. La flexibilidad de GraphQL te permite construir una API de GraphQL que sirve a múltiples clientes. Redwood y Next.js tienen enfoques diferentes, por lo que vale la pena explorar ambos para encontrar el mejor ajuste para tu caso de uso.

Y una de las razones más importantes por las que hacemos esto es porque hemos concebido Redwood como un framework multiplataforma para que se convierta en algo más que un framework de aplicaciones web. Se convierte en un framework multiplataforma. A menudo, cuando comienzas a trabajar en un nuevo producto, comenzarás con una aplicación web que es bastante normal, que tendrás una. Y nos encanta React para eso en el frontend. Y luego, más adelante, decidirás: oh, necesito una aplicación móvil. Y en ese momento, lo que suele suceder con frameworks como Rails o si estuvieras usando Blitz, esto puede suceder. Luego dices: OK, necesito que mi cliente se comunique con mi backend. Así que supongo que reimplementaré algún tipo de API para que mi aplicación móvil pueda comunicarse con mi backend. Y ahora estás duplicando el trabajo que ya has hecho antes. Entonces, lo que dijimos es: comencemos con la suposición de que serás multiplataforma o eventualmente querrás ser multiplataforma y creemos la abstracción entre el frontend y el backend y usemos un protocolo que sea realmente eficiente, muy conocido. Hay clientes para todo con lo que alguna vez quieras interactuar, para que cuando decidas 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 backend. Y por lo tanto, 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 aún tienes control total sobre eso. Estás construyendo la API de GraphQL tú mismo. Por lo tanto, tienes la flexibilidad de GraphQL en sus mejores partes, pero también la flexibilidad de usarlo en múltiples clientes. Esa es realmente la esencia de por qué elegimos GraphQL para eso. Esas son dos de las grandes diferencias. Y, por supuesto, hay muchas más. Simplemente nuestro enfoque en muchas cosas es ligeramente diferente. Es simplemente 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.

Redwood JS y SSR

Short description:

Redwood JS maneja SSR proporcionando soporte de pre-renderizado, lo que permite el almacenamiento en caché y la entrega de contenido generado. El pre-renderizado es una de las muchas características que entran en la categoría de Redwood a escala, que se centra en el almacenamiento en caché y el rendimiento a gran escala. El objetivo es permitir la generación estática de páginas de marketing que se puedan rehidratar para la interactividad. El enfoque de Redwood para SSR puede diferir de Next.js, pero tiene como objetivo resolver los desafíos de implementación y escalabilidad a los que se enfrentan los desarrolladores de aplicaciones web.

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

Tengo una pregunta. Dado que también tocas la parte de Next.js, la pregunta de Vlad F es cómo maneja Redwood el SSR. Dado que Next.js maneja el SSR, ¿cómo maneja Redwood JS el SSR? Sí, creo que Next realmente se ha convertido en un verdadero ganador en esta área. Así que es una pregunta muy relevante. Estas son preguntas que hemos tenido que reimaginar desde la perspectiva de Redwood, pensando en lo que realmente intentamos hacer es pensar desde los principios fundamentales. ¿Qué necesitas como desarrollador de aplicaciones? Y estamos empezando a pensar realmente en estos problemas desde cuál es el problema que tienes y cómo puede Redwood resolverlos por ti de la manera más elegante posible? En la charla, mostré nuestro soporte de pre-renderizado. Entonces, esa es una parte de lo que SSR puede hacer por ti. Tienes este problema en el que necesitas tener contenido generado que no quieres generar en tiempo de compilación, pero te gustaría tenerlo almacenado en caché y entregado. Y puedes hacer eso por diversas razones. Una de esas razones puede ser porque necesitas tener etiquetas OG y soporte para eso. Y aquí es donde entra el pre-renderizado. El pre-renderizado es solo la primera de muchas características que entran en una categoría que llamamos Redwood a escala. Porque todas estas cosas, si las piensas, todas estas estrategias, cosas como SSR realmente se tratan de almacenamiento en caché. Se trata realmente del rendimiento a gran escala. Y eso casi siempre se reduce a alguna forma de almacenamiento en caché. Y cuando 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 las personas con frecuencia? Necesitan la capacidad de generar estáticamente páginas de marketing, porque no hay razón para hacerlas de forma dinámica. Pero también sería bueno si se pudieran rehidratar para que cualquier pequeña interactividad en la página siga funcionando. Y eso es lo que hace el pre-renderizado. 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 parezca más a SSR o viste que Netlify hoy acaba de lanzar su solución para esto que mantiene la atomicidad en torno a las implementaciones y puede hacer que sea mucho más fácil de entender. Así que aprovecharemos esas cosas en estas diferentes plataformas y las haremos realmente fáciles de usar, con suerte con la menor cantidad de trabajo posible mientras tanto. Entonces, nuestros enfoques serán diferentes, creo que Next. Se verán un poco diferentes. Pero estarán dirigidos específicamente a resolver los problemas que tienen los desarrolladores de aplicaciones web en la implementación y escalabilidad de la parte del desarrollo de aplicaciones.

Soporte de TypeScript en Redwood

Short description:

Redwood tiene soporte de TypeScript, pero aún no está completamente implementado. La solución actual es usar la bandera 'no-JavaScript' al generar una plantilla de TypeScript. Sin embargo, Redwood 1.0 tendrá soporte completo de TypeScript.

Genial. Imagine Wagons se pregunta acerca de TypeScript. Sí, tenemos soporte de TypeScript, por lo que puedes indicarle a Redwood que te genere una plantilla de TypeScript en lugar de una plantilla de JavaScript. Aún no está completamente terminado. Puedes hacerlo. Puedes obtener una versión de TypeScript. Y es gracioso, para hacerlo ahora mismo, todavía estamos trabajando en la interfaz para esto. Para hacerlo ahora mismo, en realidad pasas una bandera '--no-JavaScript', lo cual puede parecer un poco extraño. Pero es porque la plantilla ya está en TypeScript. Y la compilamos a JavaScript para la versión de JavaScript. Pero aún no tenemos tipado completo de TypeScript en toda la aplicación. Pero lo resolveremos. La versión 1.0 se lanzará con soporte completo de TypeScript de la manera que esperas. Hablando de la versión 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 es más trabajo del que esperaba. Ya esperaba que fuera mucho, pero en realidad es mucho más de lo que anticipé. Nos ha llevado un poco más de tiempo de lo que esperábamos, pero es porque realmente creemos firmemente que necesitas un conjunto específico de características para considerarse 1.0 en un marco de aplicación de pila completa en estos días. Y queremos asegurarnos de que todo esté ahí y que puedas confiar en ello y que no haya sorpresas y que no vayamos a romper muchas cosas después. Por lo tanto, esperamos hacer una versión candidata para la versión 1.0 en los próximos meses. Creo que eso es totalmente realista. Estamos realmente en el último conjunto de características que necesitamos resolver. Hay algunas cosas relacionadas con la seguridad de la API de GraphQL de una manera realmente fácil en la que estamos trabajando en este momento, soporte completo de TypeScript de extremo a extremo y algunas otras cosas. Pero realmente, hemos resuelto la mayoría de las cosas importantes que queríamos tener ahí. Así que espero una RC1 en los próximos meses y luego probablemente llegará la versión 1.0 a mediados de año. Tomará unos meses pasar por las versiones candidatas y asegurarnos de que sea realmente estable. Habrá errores que se corregirán a medida que más personas comiencen a usarlo y probarlo en diferentes entornos y cosas. Así que probablemente pasen otros cinco o seis meses antes de que haya una versión 1.0 lanzada en este punto. Pero es bastante estable. Y si revisas nuestras notas de lanzamiento, dedicamos una gran cantidad de esfuerzo a nuestras notas de lanzamiento, asegurándonos de que sepas exactamente qué debes hacer para actualizar. Y puedes ver cómo hemos estado haciendo eso. Y es muy fácil seguir el camino de actualización. Así que puedes comenzar ahora mismo. Es bastante sólido en la mayoría de los aspectos. Y ten en cuenta que tendrás un camino de actualización realmente fluido hasta llegar a la versión 1.0. Genial. Muchas gracias, Tom. Gracias por compartir todo sobre Redwood.js. Ha sido un placer tenerte aquí. Nuevamente, muchas gracias por tomarte el 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 recibirme. Lo aprecio.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
JSNation 2022JSNation 2022
28 min
Full Stack Documentation
Top Content
Interactive web-based tutorials have become a staple of front end frameworks, and it's easy to see why — developers love being able to try out new tools without the hassle of installing packages or cloning repos.But in the age of full stack meta-frameworks like Next, Remix and SvelteKit, these tutorials only go so far. In this talk, we'll look at how we on the Svelte team are using cutting edge web technology to rethink how we teach each other the tools of our trade.
GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
From GraphQL Zero to GraphQL Hero with RedwoodJS
Top Content
We all love GraphQL, but it can be daunting to get a server up and running and keep your code organized, maintainable, and testable over the long term. No more! Come watch as I go from an empty directory to a fully fledged GraphQL API in minutes flat. Plus, see how easy it is to use and create directives to clean up your code even more. You're gonna love GraphQL even more once you make things Redwood Easy!
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Top Content
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.
JSNation 2023JSNation 2023
28 min
SolidJS: Why All the Suspense?
Solid caught the eye of the frontend community by re-popularizing reactive programming with its compelling use of Signals to render without re-renders. We've seen them adopted in the past year in everything from Preact to Angular. Signals offer a powerful set of primitives that ensure that your UI is in sync with your state independent of components. A universal language for the frontend user interface.
But what about Async? How do we manage to orchestrate data loading and mutation, server rendering, and streaming? Ryan Carniato, creator of SolidJS, takes a look at a different primitive. One that is often misunderstood but is as powerful in its use. Join him as he shows what all the Suspense is about.

Workshops on related topic

JSNation 2023JSNation 2023
174 min
Developing Dynamic Blogs with SvelteKit & Storyblok: A Hands-on Workshop
Featured WorkshopFree
This SvelteKit workshop explores the integration of 3rd party services, such as Storyblok, in a SvelteKit project. Participants will learn how to create a SvelteKit project, leverage Svelte components, and connect to external APIs. The workshop covers important concepts including SSR, CSR, static site generation, and deploying the application using adapters. By the end of the workshop, attendees will have a solid understanding of building SvelteKit applications with API integrations and be prepared for deployment.
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.
React Summit 2023React Summit 2023
106 min
Back to the Roots With Remix
Featured Workshop
The modern web would be different without rich client-side applications supported by powerful frameworks: React, Angular, Vue, Lit, and many others. These frameworks rely on client-side JavaScript, which is their core. However, there are other approaches to rendering. One of them (quite old, by the way) is server-side rendering entirely without JavaScript. Let's find out if this is a good idea and how Remix can help us with it?
Prerequisites- Good understanding of JavaScript or TypeScript- It would help to have experience with React, Redux, Node.js and writing FrontEnd and BackEnd applications- Preinstall Node.js, npm- We prefer to use VSCode, but also cloud IDEs such as codesandbox (other IDEs are also ok)
GraphQL Galaxy 2021GraphQL Galaxy 2021
161 min
Full Stack GraphQL In The Cloud With Neo4j Aura, Next.js, & Vercel
WorkshopFree
In this workshop we will build and deploy a full stack GraphQL application using Next.js, Neo4j, and Vercel. Using a knowledge graph of news articles we will first build a GraphQL API using Next.js API routes and the Neo4j GraphQL Library. Next, we focus on the front-end, exploring how to use GraphQL for data fetching with a Next.js application. Lastly, we explore how to add personalization and content recommendation in our GraphQL API to serve relevant articles to our users, then deploy our application to the cloud using Vercel and Neo4j Aura.

Table of contents:
- Next.js overview and getting started with Next.js
- API Routes with Next.js & building a GraphQL API
- Using the Neo4j GraphQL Library
- Working with Apollo Client and GraphQL data fetching in Next.js
- Deploying with Vercel and Neo4j Aura
Vue.js London Live 2021Vue.js London Live 2021
116 min
Building full-stack GraphQL applications with Hasura and Vue 3
Workshop
The frontend ecosystem moves at a breakneck pace. This workshop is intended to equip participants with an understanding of the state of the Vue 3 + GraphQL ecosystem, exploring that ecosystem – hands on, and through the lens of full-stack application development.

Table of contents
- Participants will use Hasura to build out a realtime GraphQL API backed Postgres. Together we'll walk through consuming it from a frontend and making the front-end reactive, subscribed to data changes.
- Additionally, we will look at commonly-used tools in the Vue GraphQL stack (such as Apollo Client and Urql), discuss some lesser-known alternatives, and touch on problems frequently encountered when starting out.
- Multiple patterns for managing stateful data and their tradeoffs will be outlined during the workshop, and a basic implementation for each pattern discussed will be shown.
Workshop level

NOTE: No prior experience with GraphQL is necessary, but may be helpful to aid understanding. The fundamentals will be covered.
React Day Berlin 2022React Day Berlin 2022
161 min
Crash Course into the Jamstack with Next.js & Storyblok
WorkshopFree
You might have read already about Jamstack. You probably already used Next.js, and recently you may be hearing a lot about the headless CMSs. This quick course will put all the pieces together and show you why Storyblok, combined with Next.js, is the best combo for your next project. Stop by and try it yourself!
- In-depth Jamstack knowledge. How it changed from old times to the modern world. Learn how Jamstack was created by comparing Static Sites and Dynamic Sites.- How Next.js serves content, and how content is served with Static Site Generation (SSG).- Atomic design methodology, and how this is applied to the content management system.- Hands-on project experience by building a Jamstack project with Next.js and Storyblok.
Prerequisites- Any Text . Visual Studio Code recommended- Node.js LTS- NPM or Yarn- GitHub account- Vercel account- Familiarity with JavaScript, React, and Git. Having worked with Next.js before is a plus
What's included1. Introduction and overview of the workshop2. Introduction to Jamstack3. Introduction to Atomic Design4. Overview of Headless CMS5. Introduction to Storyblok6. Next.js app creation7. Storyblok space creation8. Next.js and Storyblok connection9. Custom components creation10.First-page creation11. Introduction to Visual 12. Dynamic pages addition13. Blog section creation14. Deployment on Vercel