1. Introducción a la construcción de aplicaciones Full Stack
Hola, Ámsterdam. Es realmente bueno estar aquí. ¿Está bien si nos divertimos un poco? Vamos a divertirnos. Mi nombre es David y vengo a hablar sobre la construcción de una aplicación Full Stack. A veces las cosas pueden salirse de control rápidamente al construir una aplicación Full Stack. Hay mucha complejidad dinámica al ensamblar todas las partes. El ecosistema de JS tiene tanto belleza como tensiones. Nuestro objetivo es lanzar características lo antes posible.
Hola, Ámsterdam. Gente de Internet, de todo el mundo. Es realmente bueno estar aquí. ¿Está bien si nos divertimos un poco? ¿Estaría bien eso? Muy bien. Quiero decir, parte de esto será un recorrido. Pero parte de esto, bueno, puede volverse un poco extraño. Pero nos vamos a divertir. Nuevamente, mi nombre es David y vengo a hablar sobre la construcción de una aplicación Full Stack. Si, oh, sí, ahí vamos. Oh, nos pasamos. Mi controlador. Mi controlador hizo clic. Esa es una pregunta que quiero hacerles. ¿Así que quieren construir una aplicación Full Stack? ¿Sí? Muy bien. Tengo buenas noticias. Pero por supuesto, siempre se empieza con las malas noticias. Y las malas noticias son que a veces las cosas pueden salirse un poco de control, ¿verdad? ¿Alguien, una pregunta para ustedes, alguien que haya construido una aplicación Full Stack, ¿quién diría levantando las manos que ha utilizado probablemente el 75% de esas herramientas o herramientas similares en su aplicación? ¿Levantando las manos? ¿Correcto? ¿Qué tal el 80, 90%? ¿Levantando las manos? Correcto. Tal vez tres de cada cuatro, pero eso es parte de la belleza del ecosistema en el que trabajamos. Y también es una de las tensiones del ecosistema en el que trabajamos. Entonces, ¿qué pasó antes de que este tren literalmente se descarrilara? Están lanzando características, ¿verdad? Solo quieren construir características lo más rápido posible, diseño, desarrollo, implementación, repetir. Y a veces no siempre va como quieres que vaya. Hay una forma en la que ensamblamos todas las partes que agrega mucha complejidad dinámica, ¿verdad? Y la complejidad a menudo significa salirse de los rieles. La belleza del ecosistema de JS es su diversidad, modularidad y tasa de innovación. La desgracia del ecosistema de JS es su diversidad, modularidad y tasa de innovación. ¿Verdad? Es poderoso, pero a veces sale mal por las mismas razones por las que sale bien. Muy bien. Entonces, nuevamente, nuestro objetivo, queremos lanzar características, queremos hacerlo con frecuencia.
2. Desafíos de Arquitectura y Proceso
Y a medida que nuestra aplicación crece, queremos lanzar características de manera continua. Necesitamos una arquitectura y un proceso que funcionen de manera eficiente en todo el stack. La configuración, la integración y las dependencias añaden sobrecarga. La separación de responsabilidades es importante, pero requiere integración y configuración al volver a unirlas.
Queremos lanzar características lo antes posible. Y a medida que nuestra aplicación, a medida que nuestro equipo crece, nuestro base de usuarios crece, queremos lanzar características de manera continua, frecuentemente. Diseño, desarrollo e implementación. Y no se trata solo de la tecnología. Entonces, de eso es de lo que quiero hablar hoy. Necesitamos tanto una arquitectura como un proceso que funcione en todo el stack de manera eficiente como sea posible. Entonces, ¿qué obstaculiza la arquitectura y el proceso? Oh, hizo algo de nuevo. Espera un segundo. Sabes, ya no confío en mi controlador. Uh-oh. ¿Acabo de revelar algo? Muy bien. ¿Qué obstaculiza? ¿Alguien ha trabajado con configuración antes? Vamos, levanten las manos. Sé que llegaremos allí, ¿verdad? Sí, configuración. Bueno, vamos, en
JavaScript todo lo que hacemos es configurar. Si no están levantando las manos, entonces están mintiendo. Soy un desarrollador de
frameworks, así que todo lo que hago es configurar, pero no sé si me gusta la configuración. Integración, configuración, dependencias, todo eso añade sobrecarga con el tiempo, porque también tienes que moverte rápido y mantener el ritmo con esas dependencias. A medida que ocurren cambios y roturas, tienes que mantener el ritmo con la configuración. Convenciones. Separación de responsabilidades. Ahora esto es realmente interesante. En el stack completo, te enseñan a separar responsabilidades, lo cual tienes que hacer. Esto puede ser a nivel de un punto de extremo específico. Tal vez estás creando una integración con una aplicación de terceros. Toda tu API, ¿verdad? Queremos separar responsabilidades. Queremos separar del front end, ¿verdad? Trabajando con
React, trabajando con estado, trabajando con datos. Si solo queremos hacer diseño y maquetación, queremos separar responsabilidades. ¿Qué sucede cuando necesitas volver a unir esas responsabilidades separadas nuevamente? ¿Qué estás haciendo? Vamos, eso fue... Entonces, ¿qué fue la sobrecarga? Estás haciendo integración y configuración, ¿verdad? Incluso cuando separas responsabilidades, luego
3. Diseño impulsado por flujo de trabajo Full Stack
El clicker me falló hoy. Seguridad. ¿Tu API es segura? Flujo de trabajo Full Stack impulsado por diseño. Un flujo de trabajo para personas a las que les gusta lanzar características. Te mostraré cómo tener un flujo de trabajo Full Stack desde el inicio hasta la escala. Comenzando con un proyecto independiente, crearemos componentes, aislamiento de diseño y trabajaremos con datos. Construiremos una API y una interfaz de usuario para CRUD y la haremos segura. Todo en esta presentación.
tenemos que volver y hacer integración y configuración en ellos, ¿verdad? Ok, siguiente. Clicker. El clicker me falló hoy. Seguridad. ¿Tu API es segura? ¿De verdad? ¿Porque tú lo hiciste? ¿También escribiste las pruebas de
CI, verdad? Bueno, malas noticias. Vamos a las buenas noticias. Diseño impulsado por flujo de trabajo Full Stack. Sí, lo inventamos un poco. Pero es un flujo de trabajo para personas a las que les gusta lanzar características. Y te mostraré cómo puedes tener un flujo de trabajo Full Stack de principio a fin que incluye ese proceso de arquitectura del que hablé, que te permite lanzar de manera eficiente desde el inicio de tu proyecto hasta la escala. Entonces, esto es lo que significa. Quiero comenzar con un proyecto independiente. Y vamos a tener un archivo que será
HTML y
CSS. Y vamos a hacer un recorrido. Me lleva unos 25 minutos y sabía que eso no funcionaría. Así que vamos a ver algunas grabaciones y hacer un poco al final. Quiero mostrar esto. Vamos a comenzar con un archivo
HTML,
CSS, JSX. Vamos a crear un componente. Vamos a diseñ
ar un aislamiento y hacer el diseño. Y luego este acoplamiento. Necesitamos trabajar con datos porque los datos son lo que necesitamos acoplar. Pero la falta de poder simular datos específicamente para fetch y estado es a menudo donde se rompe el acoplamiento. ¿Verdad? Así que vamos a trabajar en esa etapa de simular datos. Y luego vamos a construir toda nuestra API para CRUD. Vamos a construir toda nuestra interfaz de usuario para CRUD. Y luego la haremos segura. Y voy a hacer todo eso. ¿Cuánto tiempo tengo, Ellie?
4. Soluciones Full Stack impulsadas por diseño
Y eso es lo que llamamos Full Stack impulsado por diseño. Entonces, ¿cómo resuelve el Full Stack impulsado por diseño esos cuatro desafíos que les mostré? Sobrecarga. Vamos a manejar la sobrecarga. Quiero mostrarles e introducirles una innovación en Redwood llamada Redwood Cells. Y por último, les mostraré cómo se ve ser seguro por defecto, su frontend y backend. Y nuevamente, esto es con Redwood. Ahí es donde trabajo. Soy cofundador de Redwood. Es un proyecto de código abierto, así que, ya saben, trabajo, pero hay otras formas de hacer esto en otros sistemas.
No importa. No respondas a eso. Pero lo haremos en esta presentación. Y eso es lo que llamamos Full Stack impulsado por diseño. ¿Suena bien? ¿Lo ven ahora? ¡Eso es bueno! Tal vez esté un poco somnoliento. Así que todos ustedes me están ayudando. Sigan así. Entonces, ¿cómo resuelve el Full Stack impulsado por diseño esos cuatro desafíos que les mostré? Sobrecarga. Vamos a tener configuración endian, configuración cero, listo para usar. Vamos a tener generadores de código y generadores de configuración, para que puedan comenzar sin tener que pensar en, espera, ¿qué complemento necesito para
Storybook otra vez? Espera, ¿cómo simulo realmente datos en
Storybook? Pero luego, ¿qué le digo a mis desarrolladores de
backend al respecto? Así que vamos a manejar la sobrecarga.
¿Convenciones? Cierto. Quiero mostrarles e introducirles una innovation en Redwood llamada Redwood Cells. Y Redwood Cells son una forma de manejar datos, estado y fetch. Y quiero mostrarles la separación de preocupaciones y cómo usamos datos como acoplamiento, luego, una vez que tenemos la estructura de datos definida, pasar a Crud e integrar el frontend y el backend. Y por último, les mostraré cómo se ve ser seguro por defecto, su frontend y backend. Y nuevamente, esto es con Redwood. Ahí es donde trabajo. Soy cofundador de Redwood. Es un proyecto de código abierto, así que, ya saben, trabajo, pero hay otras formas de hacer esto en otros sistemas. Y solo quiero mostrarles, para sus stacks, algunas ideas y conceptos que pueden aplicar. Así que tengan paciencia conmigo por un segundo. Una analogía. Bien. Digamos que quieres aprovechar todo el poder en el universo para construir tu aplicación Full Stack, podrías intentar buscar el guantelete del infinito, ¿verdad? Porque qué más... Lo sé. Esto va a ponerse, tengan paciencia, va a ponerse un poco extraño, ¿verdad? Queremos agarrar el guantelete del infinito para poder aprovechar todo el poder del ecosistema de JavaScript que quiere desviarnos de nuestro camino, para poder hacer nuestra aplicación Full Stack. Así que cada uno de estos pasos diferentes, pueden imaginar, ¿no es hermoso? Saben, si convierten Keynote en un videojuego, es mucho más divertido hacer diapositivas. Cada uno de ellos es una gema del infinito. Nuestra misión es ir y agarrar la gema del infinito para poder obtener el guantelete del infinito antes, ¿ese es el Titán Loco mismo? Thanos también está tratando de obtener el guantelete del infinito porque toda buena historia tiene un villano, así que la nuestra también tiene un villano, y es Thanos. Queremos lanzar características, y ¿recuerdan a Thanos? Él quería hacer exactamente lo contrario. ¿De acuerdo? Así que esa es nuestra misión. Pero, ¿cómo vencemos a Thanos? Todos hemos visto la película, tuvo mucho éxito en taquilla. ¿Cómo vencemos a Thanos?
5. Construyendo una aplicación dinámica con Redwood.js
Vamos a construir una aplicación dinámica y simbolizar a los Vengadores. Comenzaremos con un archivo JSX de HTML y CSS utilizando Tailwind. Luego, crearemos una página web dinámica con una interfaz de usuario CRUD y una API. Redwood.js es una aplicación de pila completa, totalmente integrada y con todas las funciones que incluye GraphQL y React.
¡Sí! Creo que sé quién fue. ¿Verdad? Con un equipo. De acuerdo, aquí es donde vamos. Necesitamos a los Vengadores. Y lo que vamos a hacer es construir una aplicación dinámica y vamos a simbolizar a los Vengadores. ¿Ven? Es divertido, ¿verdad? Nos vamos a divertir mucho aquí. De acuerdo, porque lo que realmente quiero mostrarles es un montón de código. Pero lo que haremos es comenzar con el archivo JSX allí, y todo lo que es es
HTML y
CSS. Por cierto, vamos a usar Tailwind y vamos a construir una página dinámica para reunir a los Vengadores y a todos los miembros del equipo allí. ¿Suena bien? De acuerdo. Veamos cómo va esto. De acuerdo, comencemos con un pequeño
video rápido. Pero este es el archivo con el que comenzaremos. Tiene algunos datos en él que vamos a usar y solo quiero mostrarles que es
HTML y
CSS. Y luego a dónde queremos llegar, esta será la página web dinámica con la que terminaremos, ¿de acuerdo? Aquí está la interfaz de usuario CRUD. Viene con una API. Si se dieron cuenta, Vision estaba ausente. Ese tipo. Por cierto, WandaVision estuvo genial. En fin, pueden agregar a Vision y ahora tenemos una aplicación CRUD completa, ¿verdad? Eso es lo que vamos a hacer. De acuerdo. Redwood.js. Un poco rápido sobre Redwood. Creado por un tipo llamado Tom Preston Warner. Fue cofundador de GitHub. Construyó una de las aplicaciones Rails más grandes que existen. También construyó en Jekyll. Y hace cuatro años, se iniciaron conversaciones sobre lo que podría ser Redwood. Ahora, Redwood.js es una aplicación de pila completa, totalmente integrada y con todas las funciones que decimos que va de un proyecto secundario a una startup lo más rápido posible. E incluye algunas de sus herramientas favoritas.
6. Creando una aplicación Redwood con Storybook y Yarn
Estamos en la conferencia de React. Prisma. Storybook y vamos a usar Tailwind. Infinity Stone 1. Overhead. ¿Qué tan rápido podemos pasar de la instalación a la codificación de funciones? Vamos a crear una nueva aplicación Redwood. Se inicia en, ya sé. Yarn, paquetes, instalación. Acabamos de iniciar Storybook. Código de pila completa, Storybook se inicia, todos los complementos ya están listos para ti. Una nota rápida sobre el código base del proyecto Redwood. Tienes espacios de trabajo de Yarn. Dos proyectos principales, tu API y tu web. Una API adecuada, como los servicios de Rails para tu lógica empresarial.
¿verdad? Entonces, reconocerás
GraphQL.
React. Estamos en la conferencia de
React.
Prisma.
Storybook y vamos a usar Tailwind. De acuerdo. Esas son nuestras herramientas. Infinity Stone 1. ¿Ves? Ya es más divertido, ¿verdad? Infinity Stone 1. Overhead. ¿Qué tan rápido podemos pasar de la instalación a la codificación de funciones? Y todo lo que quería mostrarte es que no estaba haciendo trampa, ¿de acuerdo? Bueno, podría haber estado haciendo trampa porque podría haber editado los videos, pero no necesitas saber eso. De acuerdo. Así que vamos a crear una nueva aplicación Redwood. Se inicia en, ya sé.
Yarn, paquetes, instalación. De acuerdo. Así que aceleré todo eso. Vamos a
CD en el directorio. Oh, lo siento. Y luego inmediatamente no iniciamos nuestro servidor de desarrollo local. Esto es realmente importante. Acabamos de iniciar
Storybook. ¿De acuerdo? Código de pila completa, iniciado
Storybook,
Storybook se inicia, todos los complementos ya están listos para ti. Aún no hay historias porque ni siquiera hemos comenzado a codificar. La accesibilidad está activada.
Storybook está listo para comenzar. Así que ese fue nuestro primer paso, instalar, ejecutar el proceso de
Storybook. Una nota rápida sobre el código base del proyecto Redwood. Tienes espacios de trabajo de
Yarn. Por lo tanto, hay dos proyectos principales allí, tu API y tu web. Lo llamamos una API adecuada. Si estás familiarizado con Rails,
7. Creating a Page with Storybook and Tailwind
También tenemos funciones para listas de servidores o para usar Fastify para implementar. La web es una aplicación React. Lo primero que debemos hacer es preparar nuestra página. Usamos un generador para crear la página. Te darás cuenta de Storybook, que te permite diseñar dentro de él utilizando código. Viene con tres archivos generados: archivo JSX principal, archivo de historia y una prueba. A medida que realices cambios en tu CSS, verás inmediatamente esos cambios dentro de Storybook. Storybook es una herramienta maravillosa para el desarrollo de UI.
se sentirá y se verá mucho como los servicios de Rails para tu lógica empresarial. También tenemos funciones para listas de servidores o para usar
Fastify para implementar,
GraphQL para los SDL. Y te darás cuenta de que Jest viene preconfigurado. Y la web es una aplicación
React. Nos adentraremos un poco más en eso. Pero eso es la base de código. No tengo más tiempo para profundizar en ello ahora de lo que vamos a ver. Lo primero que debemos hacer es preparar nuestra página. Y nuevamente, estamos capturando la primera piedra aquí. Quiero mostrarte qué hacemos con el código base. Entonces, este es un generador para crear la página. ¿No generas el equipo de la página, verdad? Tienes que empezar con la página del equipo. Eso está hecho. Te darás cuenta de
Storybook, el proceso se está ejecutando y de inmediato
Storybook, ahora estás viendo esa página. Solo tenemos un poco de
data de plantilla que aparece y ¿no sería bueno si con un solo comando pudieras configurar Tailwind? ¿Y funcionó con
Storybook? Y así, de inmediato estás diseñando dentro de
Storybook utilizando el código que vas a utilizar. Observa que se generaron tres archivos. Esto va muy rápido, lo sé. Y esos tres archivos son tu archivo JSX principal, tu archivo de historia y una prueba. Así que viene con una prueba por defecto. Y todo lo que estoy haciendo aquí es copiar y pegar. Queremos trabajar dentro de nuestro nuevo componente de página. Así que estoy copiando y pegando ese código de inicio que tenía. Y ahora tienes tu página creada dentro de
Storybook, no maquetada. Y a medida que haces cambios en tu
CSS, en este caso, solo quiero reproducirlo ahí. A medida que haces cambios en tu
CSS, verás inmediatamente esos cambios dentro de
Storybook. ¿Alguien ha usado
Storybook antes? Sí. ¿Les encanta? Vamos. Nos encanta.
Storybook es maravilloso.
8. Introducing Redwood Cells and Handling State
Recomiendo echar un vistazo a Storybook. A continuación, simplifiquemos las cosas difíciles e introduzcamos las celdas de Redwood. Estas celdas manejan el estado de React, GraphQL, cliente-servidor, solicitudes de búsqueda y puntos finales. En la arquitectura de componentes, tenemos una página, un componente de miembro del equipo para diseño y estilo, y una celda de Redwood que maneja los datos y pasa props al componente de miembro del equipo. Generemos la celda de Redwood para los miembros del equipo, que incluye manejar el estado: vacío, error, carga y éxito.
Y si no lo has usado, probablemente sea por la configuración y la integración. Realmente te recomiendo que lo pruebes.
Storybook es una herramienta increíble. Muy bien. A continuación, convenciones. Entonces, ¿cómo podemos simplificar las cosas difíciles y obtener la Gema del Infinito Número 2? Quiero presentarte las celdas de Redwood. Y las celdas de Redwood se encargarán de todas las cosas difíciles sobre el estado de
React.
GraphQL, cliente-servidor, porque nos gusta hablar de
GraphQL, pero no sé si nos gusta
GraphQL. Y también solicitudes de búsqueda y puntos finales. Esta es la arquitectura de componentes que voy a desarrollar. Comencé con una página. Así que ya tengo la página. A continuación tendré un componente de miembro del equipo. Y lo usaré predominantemente solo para el diseño y el estilo de un miembro del equipo. El componente de la página, básicamente, puedes pensar en él como un envoltorio. Lo siento, diseño. De la forma en que lo estoy haciendo aquí. Pero ahora hay un componente intermedio. Y ese es la celda de Redwood. Y lo que usaré eso, el trabajo que esa celda va a hacer... Esa es una buena metáfora, ¿verdad? ¿Sería una analogía o una metáfora? A veces me confundo con eso. De todos modos. El trabajo que la celda va a hacer es que va a manejar los datos y pasar las props al componente de miembro del equipo. Y eso es todo. Te mostraré ese código aquí en un segundo. Pero primero, empecemos. Y por supuesto hay un generador para eso. Quiero mostrarte cómo generar la celda de Redwood para los miembros del equipo. Y de inmediato, ves esta historia, pero hay cuatro subhistorias allí.
9. La estructura y los beneficios de las celdas de Redwood
¿No es interesante? La celda de miembros del equipo en Redwood es efectivamente un componente de orden superior que maneja consultas y estados. Ayuda a simplificar tareas complejas aprovechando convenciones.
Y eso es manejar el estado. Vacío, error, carga y éxito. ¿No es interesante? ¿De dónde sacamos eso? Y si miras la celda de miembros del equipo, tenemos varias cosas dentro de este componente. Tenemos una consulta. Tenemos todos nuestros estados. Carga, vacío, error y éxito. También tenemos otros dos archivos que se generaron allí, las historias y las pruebas. Pero, ¿alguien sabe a qué nos recuerda esto? Esto es una celda de Redwood. La estructura de una celda de Redwood. ¿Esto le recuerda algo a alguien en el habla de
React? Es efectivamente un componente de orden superior. No técnicamente. Dije efectivamente, porque nos corrigieron. Pero puedes pensar en ello como un componente de orden superior. Así que tiene la consulta para
GraphQL. Estamos usando el cliente
Apollo. Tienes cuatro estados dentro de un solo componente. Y, de nuevo, esta gema del infinito, ves, la analogía está funcionando realmente bien. Esta gema del infinito nos está ayudando con las convenciones. Y nos permite aprovechar las convenciones para que
10. Cascading Code and Passing Props
Te mostraré cómo el código se cascada desde el componente de página hasta la celda de miembro del equipo. Se utilizan consultas GraphQL para pasar props a la celda. Se crea un mock para Storybook.
podemos simplificar muchas cosas que son realmente difíciles y complejas. Hablé un poco sobre la celda. Pero, nuevamente, notarás en la parte superior que hay una consulta, una consulta
GraphQL. Haremos más trabajo en eso. Y luego tenemos, efectivamente, cuatro componentes, el de carga, vacío, error y éxito. Muy bien. En el próximo
video, quiero mostrarte, hay mucho código moviéndose. Pero recuerda ese diagrama que te mostré, la arquitectura, la jerarquía que quiero crear? Página, celda y luego un miembro del equipo dentro de ella. Te lo explicaré. Pero todo lo que estoy haciendo es mover el código hacia abajo en la jerarquía. Así que estoy cascando el código. Para que cada componente pueda hacer su trabajo individualmente. Aquí vamos. Primero vamos a empezar, el componente de página es donde está el código. Y comienzo importando la celda de miembro del equipo que he creado. Así que voy hacia abajo. Ya no necesito estos
data aquí. ¿Verdad? Eso nunca fue más que para iniciar el proceso. Y aquí, en lugar de mi lista desordenada, es donde la celda de miembro del equipo va a hacer el trabajo. Y ahora, estoy en la celda de miembro del equipo. En esa lista desordenada que acabo de copiar, ahora la estoy pegando. ¿Verdad? Solo estoy trabajando hacia abajo en la jerarquía. Y también... como... conozco las consultas
GraphQL. Da miedo. Pero solo son props. Piensa en props. ¿Qué props necesito? Y los estoy poniendo en mi consulta justo aquí. A continuación, viene un mock. Y este es un mock para
11. Mock Files and Creating the Team Member Component
Estamos utilizando mockServiceWorkers con Storybook para mostrar el estado de éxito con datos simulados. Puedes ver instantáneamente tus componentes con datos simulados en diferentes estados. Hay un archivo de historia de celda y un archivo simulado de celda. El archivo de historia obtiene sus datos de algún lugar. Necesitamos un componente más, el miembro del equipo. La celda se encargará de los datos, mientras que el nuevo componente se enfocará en el diseño utilizando HTML y CSS.
storybook. ¿Verdad? Entonces, si nunca has visto un archivo simulado antes... por cierto, estamos utilizando mockServiceWorkers para esto. Va con
Storybook. ¿Verdad? Es lo que
Storybook está utilizando para mostrar el estado de éxito con datos simulados. ¿No es genial? Y lo que no puedes ver... simplemente no pude hacerlo lado a lado mientras codificaba. Pero estás trabajando en
Storybook e instantáneamente estás viendo tus componentes con datos simulados en cada uno de los estados... lo siento, datos simulados en cada uno de los estados de inmediato. Así que eso es bastante divertido. Una cosa que quiero mostrarte muy rápidamente, hay un archivo de historia de celda y un archivo simulado de celda. No hay magia ahí. Es solo una importación. ¿De acuerdo? ¿Tiene sentido en cierto modo? El archivo de historia está obteniendo sus datos de algún lugar. De acuerdo. A continuación, tenemos... había un componente más que necesitábamos. ¿Recuerdas? Miembro del equipo. Sí, recuerdas. En realidad estabas prestando atención. Eso es bueno. Miembro del equipo. Y... quiero que la celda haga el trabajo de los datos. Porque eso es consulta y estado para mí. Entonces, eso es obtener y estado. Quiero mover todo lo demás a un nuevo componente que llamo mi miembro del equipo. Y ahí es donde puedo pensar en mi diseño para los miembros del equipo. Así que eso será
HTML y
CSS. Nuevamente, solo moviendo código.
12. Importando el Componente Miembro del Equipo y Usando Mocks
Pero es mucho más eficiente. Ahora estamos importando el componente miembro del equipo en la celda de miembros del equipo. Por último, ese mock que creé para mi celda, puedo usar ese mismo archivo mock para el componente miembro del equipo porque quiero verlo en Storybook. Tengo todos mis componentes mostrando historias dentro de un Storybook. Es algo hermoso y realmente divertido y mágico de usar.
Es extraño no estar escribiendo esto. Pero es mucho más eficiente. Y no llegas a descubrir qué malo soy escribiendo a máquina. Muy bien, aquí estamos. Ahora estamos importando el componente miembro del equipo en la celda de miembros del equipo, en plural para ayudarnos a recordar que está iterando. Limpiando nuestras props. Y aquí dentro del miembro del equipo, este es el componente. Y ahora aquí es donde estará todo el
HTML para el diseño. Y necesito asegurarme de pasar el miembro. En realidad, me alegra no estar haciendo esto en vivo ahora mismo. No hubiera salido bien. No te hubiera impresionado. Muy bien. Por último, ese mock que creé para mi celda, puedo usar ese mismo archivo mock para el componente miembro del equipo porque quiero verlo en
storybook, ¿verdad? En una celda, pasaremos las props hacia abajo a un miembro del equipo, así que en este caso, puedo manejarlo a nivel de mock. Y luego inmediatamente, y nuevamente, es más impresionante si lo ves a pantalla completa. Tengo todos mis componentes mostrando historias dentro de un
storybook, ¿verdad? Los
data se pasan al nivel de la página. Puedo ver los mocks para la celda y el miembro. Todo está ahí, simplemente está.
13. Acoplando Frontend y Backend con Datos Falsos
De acuerdo. Hasta ahora tenemos dos piedras. Vamos a acoplar el desarrollo del frontend y el backend utilizando datos falsos y estado. Crearemos un modelo en nuestro esquema de datos utilizando la misma estructura que la consulta de la celda de miembro del equipo. Con el servidor de desarrollo de Redwood, podemos pasar rápidamente del desarrollo local a trabajar en todo el stack. La alineación entre el frontend y el backend es crucial, y la logramos con celdas y datos falsos.
es algo hermoso y realmente divertido y mágico de usar. De acuerdo. Hasta ahora tenemos dos piedras. Siguiendo un poco. ¿Está bien? ¿Alguien ha visto algo así antes con
storybook? Sí, no pensé que quisiéramos que esto fuera. Esta fue una visión que teníamos para el uso de
storybook. Así que sé que es una visión de
storybook. Nos encanta trabajar con el equipo de
storybook que también tenían. De acuerdo, dos piedras abajo, nos queda una piedra aquí. La tercera piedra del infinito, separación de concurrencia, en realidad tenemos dos. ¿Cómo podemos acoplar el desarrollo del
frontend y
backend utilizando datos falsos en estado? Y cómo vamos a hacer eso es tomando esa consulta de la celda de miembro del equipo. Ya tenemos nuestra estructura de datos. Y ahora en nuestro modelo de datos o en nuestro esquema de datos, vamos a crear un modelo utilizando esa misma estructura. Estamos utilizando
prisma. No te preocupes mucho por los atributos. Pero tienes el mismo modelo de datos, ID, nombre, imagen, URL. Y déjame mostrarte lo rápido que podemos avanzar una vez que iniciamos el servidor de desarrollo de Redwood. Ahora estamos en desarrollo local. ¿De acuerdo? Ya no estamos trabajando en
storybook porque vamos a trabajar en todo. Y esta es esa pieza de acoplamiento. Por lo general, en el
frontend o trabajarías todo lo que necesitas para la interfaz de usuario del
frontend. Y luego tienes que averiguar cómo se verá eso en el
backend o si eres un desarrollador de
backend, comenzarás en el
backend y pensarás en las tablas y modelos que podrías necesitar. Y luego puedes intentar avanzar en el
frontend. Es como construir un túnel debajo de una montaña. Si te equivocas, te equivocas por millas. Así que tratar de unir esas dos cosas, realmente quieres tener alineación. Y eso es lo que estamos usando, celdas y datos falsos.
14. Optimizando el Flujo de Trabajo para Equipos de Alto Rendimiento
Lo que sucedió allí es que con el comando Prisma Migrate, ahora tenemos una base de datos local SQLite con el mismo esquema y tabla que se necesita para el código del frontend. Quiero hablar sobre Thanos y la importancia de que los equipos de alto rendimiento construyan productos de alto rendimiento. Necesitamos optimizar el proceso para que las personas afecten el conjunto.
estado para hacer. Lo que sucedió allí es que con el comando
Prisma Migrate, ahora tenemos una base de datos local SQLite con el mismo esquema y tabla que se necesita para el código del
frontend. Esto será rápido. Esto es de lo que realmente quería hablarles. Quiero hablar sobre Thanos. Hay un enfoque maravilloso en el rendimiento de las herramientas. Y con razón. El rendimiento web, el rendimiento web. Eso es importante. Necesitamos hacer eso. Pero Thanos, estoy hablando de Thanos a un grupo de adultos. Thanos, ¿cómo vences a Thanos, de nuevo? Con un equipo. Los Vengadores. Así que, si quieres vencer a Thanos, eso es lo que tienes que hacer. Necesitas un equipo. Me encanta esto. Fue genial. Es un poco ridículo. Los equipos de alto rendimiento construyen productos de alto rendimiento. Hay una gran cantidad de investigaciones que hablan de esto, ¿verdad? Podemos centrarnos en la tecnología, y necesitamos hacerlo, pero también necesitamos afectar el conjunto, y necesitamos optimizar el proceso para las personas con el fin de afectar el conjunto, ¿de acuerdo? Entonces, déjenme mostrarles cómo se ve eso en este escenario cuando optimizas un flujo de trabajo para las personas con las que estaremos trabajando en la aplicación.
15. Creando una Aplicación Full Stack con Demo CRUD
En un solo comando, ejecutamos scaffold para la interfaz de usuario y la API, creando una aplicación full stack. Los archivos generados incluyen archivos SDL y de servicio para la lógica, así como diferentes celdas para el manejo de datos. Mostramos la interfaz de administración con una demostración rápida de CRUD, comenzando con una página de equipo vacía y agregando un miembro del equipo. Hacemos una transición perfecta desde el front end al back end. Por último, hablamos sobre la importancia de la seguridad.
cómo podría verse eso. Entonces, en un solo comando, vamos a ejecutar scaffold para la interfaz de usuario, y esto creará todo lo que necesitamos en la API, todos nuestros endpoints basados en ese modelo de
data que tenemos, y esto creará todo lo que necesitamos en la interfaz de usuario para poder ejecutar CRUD. Y en este punto, ahora tenemos una aplicación full stack. Se generaron muchos archivos, pero nuevamente, son los archivos SDL, son los archivos de servicio donde se lleva a cabo nuestra lógica, y en el front end, son las diferentes celdas las que hacen el trabajo de
data por nosotros para que podamos hacer CRUD. Y muy rápidamente, esta es la interfaz de administración real, una demostración rápida de CRUD. Verás que no hay nada en la página del equipo. Aún no hemos creado ningún miembro del equipo. Ahora estamos dentro de una aplicación dinámica. Aparentemente, Falcon es a quien elegí para comenzar. ¿Verdad? Y boom, tenemos a Falcon. Si volvemos atrás, editar miembros del equipo, podemos editar eso. Eso es bastante genial, ¿verdad? Muy bien. Pasamos del front end al back end en un solo flujo. Ah, por cierto, estado vacío, ¿verdad? Está ahí para ti. Y un poco... sí, un poco, pero si lo hiciera demasiado simple, entonces tu mente no se sorprendería pero debería sorprenderse solo un poco. Solo un poco. Muy bien. Hay una última piedra del infinito y lo haré muy rápido. ¿Cuál fue la última piedra del infinito que necesitábamos? Me salté eso muy rápido, ¿verdad? Seguridad. Entonces, ¿cómo podemos hacer seguridad que prometí que sería nuestro bono? Oh, hombre. Spoiler. Y lo mostraré muy rápidamente. Pero primero, ¿lo logramos? Pantalla principal. No funcionará si mis pantallas no funcionan. ¿Estoy en línea? No. Es mi cosa, no va a funcionar. Lo sé. Sabes, es una pena cuando el gran final no sale como quieres. Pero eso es
16. Redwood Autenticación y Flujo de Trabajo
Redwood tiene autenticación por defecto y en un solo comando. Los archivos SDL tienen directivas que los hacen seguros por defecto. Puedes cambiar fácilmente un archivo SDL de autenticado a omitir para crear una API pública. Agregar 'private' a una ruta en el archivo de rutas la oculta y redirige a la página de inicio. Estas características fueron diseñadas para crear un flujo de trabajo amigable para el usuario.
muy bien. Voy a saltar esa parte y volver a mis diapositivas. Redwood tiene autenticación por defecto y en un solo comando, y te explicaré esto muy rápidamente. Cuando configuras la autenticación de Redwood, esos archivos SDL que te mostré, tienen directivas en ellos y todos son seguros por defecto. Entonces, esa página pública que viste, para los miembros del equipo, ya no sería accesible, aunque la página en sí misma lo sería, pero tu endpoint sería seguro por defecto y luego con un cambio de directiva en un archivo SDL, lo cambiarías de autenticado a omitir. Tendrías una API pública. Y luego, dentro de nuestro archivo de rutas, si agregas 'private' a cualquier ruta, esa ruta se vuelve oculta. Puedes redirigirlos a la página de inicio. Y nuevamente, ¿por qué hicimos esas cosas con Redwood? Hicimos esas cosas porque queríamos construir un flujo de trabajo para
17. Final Remarks and Redwood Community
Si estás interesado en Redwood, la mejor manera de aprender Redwood es hacer el tutorial de Redwood y unirte a nuestra comunidad de más de 400 colaboradores. Sígueme en Twitter para obtener más información. Gracias por tu generosidad.
personas. Muy bien, tengo una diapositiva final. ¿Podemos mostrarla de nuevo por casualidad? Quería esto, también estaba emocionado por esto. ¿Va a aparecer? No. De acuerdo. Tenía a Tony Stark al final. Tienes que terminar una presentación con Tony Stark si vas a hablar de Thanos, ¿verdad? De acuerdo, las diapositivas no están apareciendo. De acuerdo, lo entiendo. Vamos. ¿En serio? De acuerdo. Gracias. Han sido muy amables. Esa no es la forma en que quería terminar. Si estás interesado en Redwood, la mejor manera de aprender Redwood es hacer el tutorial de Redwood, y la mejor manera de tener éxito con el tutorial es unirte a nuestra comunidad. Tenemos una maravillosa comunidad de colaboradores, más de 400, y amamos a nuestros colaboradores. Tenemos una dinámica de ayuda en nuestros foros y en nuestro Discord, y por último, prometo que pondré esta demo en línea y podrás echarle un vistazo allí. Sígueme en Twitter si quieres obtener más información. Gracias. Han sido muy generosos. Gracias, David. Recuerden, David, nadie se mueve. Estaremos en el stand de los oradores afuera donde tal vez él haga la demostración para ustedes. Ese es su tiempo, no mi tiempo. De acuerdo, David, ¿qué hay de la renderización del lado del servidor con Redwood y
TypeScript? Sí. ¿Qué hay de la renderización del lado del servidor y
TypeScript? Me refería a la presentación y lo omití. Recuerden salir en silencio como muestra de respeto para que todos podamos escuchar. Gracias. No, está genial. Sí, completamente tipado. Me olvidé de mencionarlo cuando comenzamos el proyecto.
18. JavaScript Project and Redwood Features
Acabo de comenzar con un proyecto de JavaScript porque hace que las demostraciones sean un poco más fáciles cuando estás trabajando con código. No hacemos renderizado del lado del servidor en este momento. ¿Puede Redwood generar contratos de TypeScript basados en la API simulada? Redwood admite otros marcos además de React. Es un proyecto de código abierto. La importancia de la comunidad y el equipo en mi vida.
pero puedes pasar
TypeScript. Acabo de comenzar con un proyecto de
JavaScript porque hace que las demostraciones sean un poco más fáciles cuando estás trabajando con código. El renderizado del lado del servidor significa muchas cosas hoy en día con el lenguaje de marketing. No hacemos renderizado del lado del servidor en este momento. Hacemos una pre-renderización, que es básicamente una generación de sitio estático. Pronto tendremos pre-renderización dinámica y... no me debes mucho, pero verás un renderizado del lado del servidor antes de que termine el año.
¿Es una promesa o una amenaza? Será genial. Muy bien. ¿Puede Redwood generar contratos de TypeScript basados en la API simulada? Probablemente, Orda. No es un problema que quieras, porque necesitarías admitir algunos formularios de RLs. Sí, eso es Orda, el chico de TypeScript. Entonces, lo que dijo Orda, y esto es útil, esa es probablemente la pregunta correcta. Pero en el contexto de Redwood, eso no es algo que necesitarías. Genial. ¿Admite otros marcos además de React? Esa es una pregunta fantástica. Redwood, debido a los espacios de trabajo que mencioné, puedes ejecutar Redwood como una API independiente, ¿y por qué usaríamos GraphQL si no tuviéramos la intención de que sea multi-cliente? Porque hoy en día, ¿qué productos no son multi-cliente? Quiero decir, hay muchos sitios geniales que se quedan ahí, pero nuestra intención es que sea multi-cliente desde el principio. Así que sí, hay muchas startups geniales en este momento que están usando la API de Redwood con Next, ejecutando multi-cliente a través de Electron, CLI, utilizando diferentes sitios web en los que están implementados. Así que sí, esa es la respuesta. ¿Y es gratis, o cómo se monetiza? Sí, Redwood es un proyecto de código abierto. Está patrocinado, pero es código abierto. Si no lo mencioné al principio, fue mi error. Código abierto y será código abierto. Antes de dejarlos ir, creo que tenías algo que compartir. Sí, lo tengo. Gracias, Ellie, por el tiempo. Los últimos años han sido un poco locos para todos, y lo que quería dejar en claro es lo importante que es la comunidad y el equipo en mi vida. Hay un buen amigo aquí que nunca antes había conocido, y... Lo siento, ha sido una semana larga. Toby, solo quería saludarte, porque nada de esto lo hice solo. Fue hecho con una maravillosa comunidad de personas, y es una lástima que sea el único que está aquí contándote sobre ello. Así que quería decir Toby, ven aquí arriba. Solo quería conocerte por primera vez. Hola, hombre. Ese es un gran abrazo. Gracias, amigo. Me equivoqué al final. Es un placer conocerte. Es realmente bueno conocerte. Eso fue todo. Gracias nuevamente a David por unirse a nosotros, y a Toby.
