Smashing Podcast Episodio 25 con Anthony Campolo: ¿Qué es RedwoodJS?

Estamos hablando de RedwoodJS. ¿Qué significa exactamente ser un marco Jamstack de pila completa? Hablé con el campeón comunitario Anthony Campolo para averiguarlo.

Mostrar notas

• RedwoodJS
• Antonio en Twitter
• Serie de artículos de Anthony Un primer vistazo a RedwoodJS

Actualización semanal

• “Una introducción a la ejecución de Lighthouse mediante programación”
  escrito por Katy Bowman
• “Animación de componentes React con GreenSock”
  escrito por Bendición Krofegha
• “Diseñando para llamar la atención”
  escrito por Víctor Yocco
• “Uso avanzado de GraphQL en sitios web de Gatsby”
  escrito por Aleem Isiaka
• “Comparación de métodos de estilo en Next.js”
  escrito por Adebiyi Adedotun

Transcripción

Drew McLellan: Es un estudiante de Lambda School, estudia desarrollo web de pila completa, además de ser colaborador de RedwoodJS. Algo así como un campeón de la comunidad, recientemente escribió una serie de artículos de 12 partes llamada A First Look at RedwoodJS que ayuda a explicar los orígenes y las motivaciones de Redwood, junto con muchos de los diferentes conceptos que presenta el marco. Entonces, sabemos que es un experto en RedwoodJS, pero ¿sabías que nunca ha visto un perro? Mis grandes amigos, denle la bienvenida a Anthony Campolo.

Drew: Hola, Antonio. ¿Cómo estás?

Antonio Campolo: Hola. Estoy destrozando, muchas gracias por tenerme.

Drew: Quería hablarles hoy, y probablemente sea obvio por la introducción, sobre RedwoodJS. Para aquellos que no han oído hablar de RedwoodJS antes, a un alto nivel, ¿qué es?

Anthony: Creo que hay un par de formas de describirlo dependiendo de dónde vengan las personas, pero la definición canónica es que es un marco sin servidor de pila completa para Jamstack. Por lo tanto, combina el desarrollo web de pila completa con cosas de tipo AWS Lambda sin servidor y Jamstack, que es una gran cosa en estos días.

Drew: Entonces, ¿es un marco de trabajo de pila completa que intenta reunir muchas de las ideas en torno a un ecosistema de desarrollo de Jamstack? ¿Está bien?

Anthony: Sí, está ampliando los límites de lo que puede ser una aplicación Jamstack, por lo que al llamarla pila completa, Jamstack, se trata de cómo vamos más allá de la interfaz para tener el mismo tipo de paradigma de implementación de simplemente ser empujado, obtener todo su código desplegado. ¿Cómo conseguimos eso pero también con nuestro back-end, y lo tenemos todo conectado?

Drew: Ahora, antes de profundizar demasiado en esto, creo que es bastante interesante escuchar que es de un equipo bastante experimentado, ¿no es así? La gente detrás de Redwood, no son pollos de primavera. No quiere decir que sean viejos, pero han estado a la vuelta de la esquina, ¿no es así, en términos de desarrollo web?

Anthony: Están sazonados. Sí, de hecho, dediqué bastante tiempo a escribir sobre la historia del marco y las ideas que lo llevaron a él, y Tom Preston-Werner es el creador, por lo que también se le conoce como el creador de Jekyll, que es un generador de sitios estáticos realmente influyente. También hizo TOML, el lenguaje de archivos de configuración. Y originalmente era el CEO de GitHub. Entonces, su trabajo con las páginas de Jekyll y GitHub y ese tipo de cosas creo que realmente lo llevó a lo que ahora consideramos Jamstack. Mucha gente diría, “Oh, el Jamstack es nuevo. Han estado haciendo esto desde siempre”. Así es como hemos estado hablando sobre cómo es una extensión de estas ideas más antiguas, las generaciones de sitios estáticos, pero con GraphQL y sin servidor y estas ideas de cómo usar el código de pegamento y las API para hacer que su aplicación funcione.

Drew: Entonces, ¿es definitivamente de personas que están muy integradas en esa comunidad? Quiero decir, el CEO de GitHub, realmente no te integras más en el tipo de comunidad de código abierto que eso. Entonces, Redwood es un marco de trabajo de pila completa y supongo que eso significa que tiene el código de Redwood ejecutándose en el front-end y en el back-end. ¿Está bien?

Anthony: Sí, esto es lo primero que me gusta explicarle a la gente cuando les muestro un proyecto de Redwood, es que es un monorepo. Entonces, tiene su front-end y su back-end en el mismo repositorio, y luego cada uno de ellos vive en sus propias carpetas. Tiene una carpeta web, que es su interfaz, y es bastante similar a lo que obtendría de una aplicación Create React. Luego, tiene la carpeta API, que es su back-end, y aquí es donde todas sus funciones se colocan esencialmente en un gran controlador GraphQL que se implementa en AWS Lambda a través de Netlify.

Drew: De acuerdo, comenzando desde el principio, como mencionas, se basa en React. ¿Es eso React más un montón de código Redwood, o es simplemente React? ¿Cuál es el saldo allí?

Antonio: Son muchas cosas. Definitivamente es solo React en el sentido de que no está trayendo muchas bibliotecas de administración de estado, ni siquiera está trayendo un enrutador en realidad. Tienen su propio enrutador que escribieron y usan muchas cosas de GraphQL. Entonces, cuando la gente habla de React y GraphQL y amigos, eso es un poco de lo que está pasando aquí, es que te brinda muchas integraciones predeterminadas para que React se comunique con tu GraphQL. Porque ahora tenemos muchas convenciones sobre cómo usar React, pero la obtención de datos sigue siendo una gran molestia.

Drew: Entonces, React está configurado con un montón de otras herramientas que funcionan muy bien con React para brindarle un ecosistema funcional para realizar este estilo particular de tarea. ¿Es esa una descripción justa?

Anthony: Sí, no, sí, esa es una gran manera de decirlo. La forma en que Tom lo expresó es que existen todas estas soluciones de la mejor clase que existen, y herramientas y tecnología realmente sofisticadas que podemos usar, pero es muy difícil aprovecharlas porque tiene un costo inicial tan alto y tiene que aprenderlas. , teniendo que averiguar cómo integrarlos. Entonces, pusieron el lema como: "Hacemos la configuración de su paquete web por usted".

Drew: Creo que es un problema común que escuchas de muchas personas cuando intentan comenzar en el marco de desarrollo moderno con aplicaciones de JavaScript del lado del cliente y configurar el paquete web, configurar todas las cosas diferentes, los procesos de compilación, el construir pasos. Puede ser todo un campo minado, ¿no es cierto?, lograr que todo funcione y funcione. Y es un largo camino antes de llegar a "¡Hola, mundo!". Entonces, ¿Redwood nos está dando todo eso preconfigurado?

Anthony: Sí, es en gran medida una convención sobre la idea del tipo de configuración, porque tienes... Tom fue, como si construyera GitHub con Ruby on Rails y Rob, uno de los otros colaboradores principales, ha sido un desarrollador de Rails desde siempre. Tienen muchas ideas con las que se alinean filosóficamente en términos de Rails, pero quieren tomar esas convenciones sobre las ideas de configuración, las ideas del marco de trabajo completo e implementarlas con toda la tecnología moderna que tenemos ahora.

Drew: Entonces, mencionaste que Redwood te da un enrutador o un enrutador, como decimos en este lado del charco, ¿viene con cosas como componentes predeterminados y ese tipo de cosas en React, o simplemente estás implementar todo eso usted mismo?

Anthony: Sí, el enrutador es muy sofisticado. Hace la mayoría de las cosas que obtendría solo del enrutador React, tiene ideas diferentes en términos de cómo deben implementarse, porque Next también tiene su propio enrutador, y todavía no está del todo resuelto cómo lo hacemos. quiere que nuestro enrutamiento de aplicaciones de una sola página funcione. Debido a Suspense, tienes muchas preguntas de este tipo sobre dónde entrarán las cosas asincrónicas. Tenemos con Redwood, esta idea de una celda, y esto es lo que realmente obtiene sus datos para usted.

Drew: Entonces, ¿tal vez podríamos profundizar un poco en eso? ¿Qué es una célula en términos de Redwood?

Anthony: Sí, entonces una celda es una forma predeterminada de escribir una consulta de GraphQL y luego hacer que su página diga básicamente si está recuperando los datos, si está recibiendo un error, si está en un estado de carga, o si… Hay un estado más, lo olvidé. Pero sí, entonces le brinda los diferentes estados en los que básicamente puede estar en función de si está obteniendo sus datos o no. Está configurado con Apollo debajo de las sábanas. Entonces, si está usando Redwood, está usando Apollo como su cliente GraphQL, pero nunca tiene que pensar en eso. Nunca tienes que escribir ningún Apollo o siquiera pensar en ello, todo está integrado. Te permite simplemente escribir consultas GraphQL, que era realmente el sueño de por qué la gente quería GraphQL, es que era este lenguaje de consulta realmente simple que los desarrolladores front-end podría utilizar. Pero entonces, tenías que descubrir cómo configurar un servidor GraphQL, tenías que descubrir todas estas otras cosas y cómo se conecta todo eso. Por lo tanto, hace toda la integración de GraphQL por usted para que pueda escribir GraphQL, no tiene que pensar en cómo implementar GraphQL.

Drew: Entonces, supongo que uno de los trabajos clásicos de un marco es tomar todo el código de la placa de caldera que podrías escribir e implementarlo para ti, y ordenar el camino detrás de escena para que nunca tengas que mirar esa placa de caldera. nunca más, y puede simplemente escribir el código que es único para su circunstancia. Supongo que eso es lo que está pasando con una celda, ¿verdad? No hay nada revolucionario aquí, es algo en lo que podría configurar un componente React para tener todos estos estados diferentes y podría conectar a Apollo y podría hacer todo esto usted mismo, pero eso en realidad es mucho trabajo y es un patrón común. Por lo tanto, Redwood se ha ordenado en un patrón agradable y reutilizable que puede comenzar a usar sin tener que pensar en ello. ¿Es eso una buena descripción?

Anthony: Sí, se les ocurrió el nombre, pero definitivamente reconocen que esta era una práctica que veían con frecuencia y que vieron a muchas personas codificarlas ellos mismos, y decidieron que querían una forma declarativa de obtener sus datos. Entonces, es por eso que tiene esta configuración, porque le permite tener sus diferentes estados y no tiene que hacer lógica si/entonces para averiguar, necesita hacer esto si esto sucede. Por lo tanto, se trata de tener una sola forma de declarar todos los diferentes estados en los que podrían estar sus datos mientras los carga.

Drew: Es una de las características de React, ¿no es así? React no trata de darte una arquitectura para tu proyecto, te permite decidir cómo vas a estructurar las cosas. Eso, por supuesto, tiene pros y contras. Pero, parece que Redwood está imponiendo algo de esa estructura para que no tengas que pensar en ello y para que pueda poner la plomería por ti y retomar donde React lo dejó en términos de darte ese tipo de estructura.

Anthony: Sí, y creo que es realmente interesante que hayamos visto múltiples intentos diferentes de esta solución a este problema, porque me refiero a que ha habido gente que lo ha estado diciendo siempre: "¿Por qué no hay un Rails para ¿JavaScript o Rails para React? Hay una gran entrevista de Full Stack Radio entre Michael Chan y Adam Wathan llamada React is Not a Rails competitor. Este es uno de los diferentes marcos.

Anthony: Los otros son BlitzJS, que ha recibido una cantidad decente de comentarios, y luego Bison es una especie de nuevo y prometedor. Todos tienen una pila similar, pero usan piezas diferentes. Tendrás la consulta React en lugar de Apollo, o tendrás Chakra en lugar de Tailwind. Las personas que juntan todas estas piezas en sus montones, todos estos montones están luchando, es una competencia muy amistosa. En realidad, eso es algo que realmente aprecio, es que en realidad todos colaboramos entre los marcos también. No hay animosidad allí.

Drew: Entonces, hemos mencionado Apollo y GraphQL, Redwood usa GraphQL bastante como una de las piezas centrales, ¿no es así, del marco? Probablemente podamos dedicar un episodio de podcast completo solo a GraphQL, pero para aquellos que no están familiarizados, ¿qué pieza está haciendo GraphQL aquí, qué problema está resolviendo en este contexto?

Anthony: Sí, esta es una gran pregunta. Cuando les digo a las personas lo que deben saber para tener un buen comienzo con Redwood, diría que deberían haber usado la aplicación Create React, solo si crearon una aplicación Create React y la implementaron en Netlify o Vercel, eso te dará un buen comienzo. Entonces, conoce al menos un poco de GraphQL porque es muy central. Por lo tanto, GraphQL es cómo su front-end le hablará a su back-end. Dicen que es un lenguaje de consulta para API, la idea es que está destinado a ser una alternativa a los métodos RESTful API, y que en lugar de hacer eso RESTful, está enviando consultas que especifican exactamente la estructura de datos jerárquica que desea recibir. la base de datos. Por lo tanto, se requiere un poco más de tiempo de inicio para que su servidor GraphQL se comunique con las dos piezas. Luego, una vez que lo tiene allí, los desarrolladores front-end tienen la capacidad de obtener datos de una manera mucho más flexible. No necesita todos estos puntos finales de API diferentes que sus muchachos de back-end necesitan seguir creando.

Drew: Entonces, si hay cambios en los requisitos en el front-end, presumiblemente puede modificar su consulta de GraphQL y no necesita la ayuda de alguien que trabaje en el back-end para hacer ese cambio por usted.

Anthony: Quiero decir, el verdadero sueño es que puedas agregarle un cliente móvil, que sería tan flexible en última instancia que se vuelve, puedes tener múltiples clientes, todos hablando con tu única API. Su API GraphQL se convierte en su fuente de verdad, ahí es donde se centraliza toda su lógica. Luego, puede construir todas estas capas de vista diferentes en la parte superior.

Drew: Entonces, tenemos GraphQL allí que nos da la capacidad de consultar algún tipo de back-end. En Redwood, ¿cuál es la parte trasera?

antonio: si Hay un par de formas diferentes de crear su back-end. Esta es la forma en que saldrá de la caja con el tutorial, que es usar la base de datos Postgres implementada en Heroku, muy fácil, muy simple. Luego, su aplicación Redwood le habla con Prisma. No sé si estás familiarizado con Prisma, pero es como un O/RM. Dicen específicamente que no es un O/RM, es un generador de consultas, que es un nivel un poco más bajo. Pero, por el simple hecho de explicárselo a la gente, Prisma es lo que te permite hablar con tu base de datos. Hace tus migraciones y configura tus tablas. Hace todas las cosas de SQL para que no tengas que escribir SQL. Para mí, eso suena como un O/RM. Sin embargo, no necesariamente necesita usar Prisma para usar Redwood.

Anthony: De hecho, construí una aplicación de prueba de concepto donde usamos FaunaDB en su lugar. FaunaDB, tienen su propia API GraphQL, por lo que puede enviar la API GraphQL directamente a Fauna y luego hacer las mutaciones de su base de datos de esa manera. Pierde mucha de la funcionalidad de la CLI de Prisma, pero Prisma realmente es un factor de conveniencia para trabajar muy fácilmente con su base de datos relacional. Pero realmente, cualquier cosa que se te ocurra, podrías descubrir cómo conectarlo con Redwood es lo que descubrí solo porque está construido alrededor de GraphQL y el objetivo es poder hablar con todas estas piezas diferentes.

Drew: Entonces, Prisma es esencialmente una especie de capa de abstracción entre su código y cualquier almacén de datos que esté usando, presumiblemente compatible con Prisma, ¿es eso... o está haciendo cosas más inteligentes que eso?

Anthony: Sí, entonces escribes un esquema, creas un archivo schema.Prisma, y ​​tendría una publicación de modelo, y luego tendría una identificación, un entero y un incremento automático, como la secuencia del título, la cadena del cuerpo, creado en fecha, hora . Entonces, básicamente crearías lo que quieres que sea en tu base de datos con los tipos, y luego hace las cosas de la base de datos por ti para que no tengas que interactuar con la base de datos.

Drew: Entonces, usas Prisma para definir, supongo, qué tipo de base de datos o qué tipo de almacenamiento de datos estás hablando. Luego, allí presenta sus diferentes modelos de mvc para usar ese lenguaje. Entonces, cuando su aplicación está hablando con los almacenes de datos, está usando una instancia de un cliente Prisma, ¿verdad? ¿Es eso lo que está pasando?

Antonio: Sí. Sí, eso es exactamente. Entonces, en la carpeta API de su back-end, tiene una carpeta lib con un db.js, y de forma predeterminada tiene configurado su cliente Prisma. Entonces, eso es todo lo que obtienes de la caja y, como dijiste, Prisma puede funcionar con diferentes bases de datos. Puede cambiar entre SQLite para desarrollo y luego Postgres para producción, ese tipo de cosas. En su mayoría son relacionales en este momento, pero la hoja de ruta tiene cosas como Mongo y Fauna.

Drew: Entonces, eso es muy útil si puede configurar y usar SQLite en su entorno de desarrollo local a medida que pone las cosas en marcha y luego entra en producción con algo como MySQL.

Anthony: Así es exactamente como está configurado el tutorial, ese es el flujo de trabajo que te muestra.

Drew: Es bastante interesante, ¿verdad?, ver un enfoque muy moderno de un marco y luego recurrir a algunas de estas bases de datos más tradicionales como MySQL. Estoy muy familiarizado con MySQL. Me encanta por su estabilidad y me encanta la forma relacional de almacenar datos. Creo que funciona muy bien para muchas cosas. A menudo, se ve que el bebé fue descartado cuando se trata de los nuevos tipos de almacenamiento de datos, por lo que es bastante interesante ver que Redwood admite de forma predeterminada estas buenas y antiguas bases de datos relacionales.

Anthony: Sí, no, ese es un buen punto, porque digo que para todas las cosas nuevas que Redwood combina, hay algunas cosas que en realidad dicen que la forma antigua, probada y verdadera es en realidad la mejor. Por lo tanto, son realmente grandes en bases de datos relacionales. Eso proviene de la experiencia de Tom con el uso de Rails y tener un back-end relacional. Active Record era la capa O/RM que Prisma pretendía aproximar.

Drew: Supongo que estamos hablando de una arquitectura sin servidor aquí con Redwood, y hablamos con Chris Coyier, creo que hace dos o tres episodios, todo sobre el uso sin servidor de las API y la función de la nube y esas cosas. Entonces, dando un paso atrás, si pensara en términos de un marco basado en servidor, como mencionamos Ruby on Rails o algo como Laravel en el mundo de PHP. Incluso con un front-end de React, su solicitud de API estaría ejecutando un código que es el código de Rails o el código de Laravel más su código de usuario y configuración. ¿Es lo mismo con Redwood? ¿Hay un código de servidor Redwood real que se ejecuta, o son solo más herramientas, estructura y pegamento que le permiten implementar el suyo propio?

Anthony: Sí, en el back-end, hay un archivo específicamente que es una forma de tomar su SDL, por lo que tiene su lenguaje de definición de esquema, y ​​luego tiene lo que se llama sus servicios, que son como sus métodos para hablar con su parte trasera Luego, todo esto se une en un controlador GraphQL que se implementa en una sola función Lambda. Por lo tanto, está optimizado para Lambda específicamente. De hecho, recientemente tuvimos a alguien que lo hizo con el marco sin servidor, y tenemos algunas personas trabajando en Azure y Google Cloud algo. No es la función de Google Cloud, es la que se construyó encima de eso. Pero sí, en este momento está básicamente optimizado para implementar su back-end como una función GraphQL en un AWS Lambda. Estas son las cosas que son toda la magia que sucede en el código que no entiendo, pero esa es la explicación de alto nivel.

Drew: Entonces, hay herramientas de implementación que toman todo el código que ha escrito, lo agrupan en una especie de bola mágica de código que se puede ejecutar en la nube y lo coloca en AWS o lo hace usted. ¿Aún tiene que administrar ese proceso usted mismo?

Anthony: Sí, entonces todo se hace a través de Netlify si sigues el tutorial. Realmente no tiene que meterse con ningún tipo de funciones sin servidor usted mismo. Todo lo que conecta su back-end para insertarlo en el AWS Lambda, todo se maneja, no tiene que tocar nada de ese código. Todo eso se genera listo para usar como sus convenciones sobre sus configuraciones, por lo que realmente no tiene que pensar demasiado en cómo hacerlo sin servidor. Es sin servidor por defecto. Es realmente una cosa difícil de entender. Me tomó un tiempo entenderlo.

Drew: Sí, porque es un punto importante no porque ahora hay algunas áreas diferentes de las que estamos haciendo un seguimiento aquí. Creo que tenemos tres áreas diferentes. Tenemos nuestra aplicación React de front-end, que se ejecuta en el navegador, y luego tenemos una API basada en GraphQL, que se ejecuta como una función en la nube, y responde a nuestras consultas, pero luego interactúa con un almacén de datos. que utiliza Prisma. Y ese almacén de datos es qué y dónde en esto, porque no puede ejecutar un servidor MySQL en Netlify, ¿verdad?

Anthony: Sí, ahí es donde entra Heroku. Entonces, en la última parte del tutorial, implementa su interfaz en Netlify y luego implementa su back-end en Heroku Postgres y simplemente toma sus variables de configuración de Heroku, conéctelo en Netlify. Lograr que su front-end de Netlify se comunique con su back-end de Postgres es algo muy, muy simple. Querían ir con la cosa que iba a ser la más fácil de hacer girar para cualquiera, pero que aún tuviera una buena tecnología estable y probada en batalla. Al final, lo que sacas de la caja con solo seguir las instrucciones, es realmente increíble.

Drew: Los entusiastas de Jamstack estarán familiarizados con servicios como FaunaDB que mencionó que proporciona un almacén de datos como una API, AWS tiene DynamoDB, Google tiene Cloud SQL, etc. Entonces, mencionó que Redwood está buscando integrarse, o supongo que Prisma es el componente aquí que está buscando integrarse con ese tipo de servicios más adelante.

Anthony: Sí, esta es una buena pregunta. Esto es algo con lo que estoy hablando con Ryan Chenkie en Prisma sobre cómo ayudar, ¿cuál es el tipo de historia de la base de datos para Redwood para cosas que no necesariamente funcionan con Prisma? ¿Sería mejor encontrar una manera de hacer que Redwood trabaje con él directamente como lo hice con Fauna o tendría más sentido implementar un controlador para Prisma? Entonces, hay diferentes maneras de abordarlo. Obviamente, ahora hay un millón de bases de datos diferentes que todo el mundo quiere usar, por lo que depende de cuán motivado esté usted para incorporar su almacén de datos. Hay muchas contribuciones de la comunidad yendo allí.

Drew: Entonces, debido a que Prisma entiende su modelo y sabe cómo consultarlos, ¿puede generar algún tipo de migraciones o cosas por el estilo para ayudarlo a configurar esa base de datos?

Anthony: Eso es exactamente lo que pierde cuando tiene que sacar Prisma y obtener sus datos, es que pierde todas las funciones de migración. Tiene una CLI realmente avanzada que hace un montón de cosas por usted, por lo que puede seguir todo el tutorial de Redwood e ingresar los comandos de Prisma y no tiene que tener idea de lo que está haciendo, simplemente funciona. Es una herramienta realmente genial para hacer todo ese tipo de cosas de tipo base de datos que quieres asegurarte de hacer bien y quieres asegurarte de que se hace correctamente.

Drew: Parece que tener una herramienta realmente buena en torno a los marcos es una tendencia bastante moderna, ¿no es así? No solo decir: "Aquí están todas las cosas que este marco puede hacer, pero aquí hay quizás algunas herramientas CLI que harán un montón de cosas por usted". ¿Redwood tiene herramientas para cosas como generadores de CLI y otras cosas para ponerlo en funcionamiento rápidamente?

Anthony: Esta es probablemente la característica clave más importante que obtiene de Redwood, es que obtiene un conjunto completo de generadores muy sofisticados. Para cualquiera que haya visto alguna vez la demostración original de Ruby on Rails, que dio DHH, crea un blog en unos 15 minutos y lo hace todo con Rails, y la gente dice: "Vaya, esto es increíble". Ese es el efecto que busca Redwood. Quieren que pueda hacer que todo gire muy rápido para que pueda generar páginas, diseños, celdas, de lo que estaba hablando, y puede hacer un comando de andamio que va a crear todo su Interfaz CRUD. Tengo una sección completa, la cuarta parte de la serie de blogs, solo explica todo el código que te da el scaffold. Te da mucho código. Hay un generador de apagado, incluso hay un generador Tailwind que configura tu viento de cola por ti.

Drew: Eso es increíble. Recuerdo haber visto la demostración de Rails de DHH. Quiero decir, probablemente fue hace 15 años cuando hizo ese andamiaje por primera vez y te lo mostró, y obtienes un panel de control bastante rudimentario pero funcional esencialmente para permitirte crear nuevos elementos, editarlos, eliminarlos, etcétera. . Eso puede ser invaluable en un proyecto, especialmente cuando se trabaja en una especie de entorno dinámico en el que, bueno, tal vez implementará mejores herramientas en el futuro para editar ese contenido, pero significa poder hacer girar algo rápidamente, puede obtener pruebe los datos, o incluso puede entregarlos a un equipo de contenido que podría comenzar a trabajar mientras usted trabaja en el front-end, por lo que es realmente útil.

Drew: Si solo quisiera implementar eso y tenerlo en producción, presumiblemente puede implementarlo junto con su código front-end, pero necesitaría alguna forma de asegurar ese aspecto, esas raíces en su aplicación.

Anthony: Sí, hay un par de opciones diferentes para la autenticación. Puede utilizar la identidad de Netlify. Ese es el valor predeterminado si ingresa al tutorial, y luego también puede usar Auth0, y luego uno con el que no estoy familiarizado llamado Magic.Link, y probablemente se agregarán un par de más en el futuro. Pero sí, ya hay un par de soluciones integradas, y eso es lo último que haces, así que esa es la última parte de toda mi serie de blogs de 12 partes que es Auth. No creo que haya descubierto Auth antes de usar Redwood. Es difícil y definitivamente han hecho un buen trabajo con eso.

Drew: ¿Eso se integra en un nivel de ruta o en un nivel de ruta? Lo siento, ¿cómo se aseguran las cosas?

Anthony: Sí, así que parte de cómo tienen su propio enrutador, también tienen... Puedes hacer rutas privadas, por lo que tienen un componente de ruta privada. Luego, su formulario de inicio de sesión real, eso es lo que obtiene de la identidad de Netlify, por lo que no tiene que crear un formulario y hacer su gestión de estado con eso, ahí es donde entran en juego muchos problemas. Quitando las partes realmente clave y luego simplemente puede implementar el acceso basado en roles. Tenemos un complemento de control de acceso basado en roles que se ha realizado durante las últimas dos semanas por David T. Por lo tanto, se está trabajando mucho para crear otras formas de hacerlo, pero lo que obtuvieron ahora ya es ... funciona, es Te pondré funcional.

Drew: La gente siempre dice acerca de la criptografía de hashing de algoritmos de seguridad, que nunca debes escribir la tuya propia porque nunca va a ser tan buena como las cosas que existen. Cada vez más, creo que eso también es cierto para la autenticación a un nivel superior; que la autenticación es un área tan compleja en estos días que las personas no solo quieren iniciar sesión en su sitio con credenciales únicas, sino que pueden querer autenticarse usando Google, o pueden querer autenticarse usando un dispositivo Apple, o pueden querer autenticación de dos factores , o pueden querer integrarlo con un servicio de inicio de sesión único que están usando de una empresa. Todas estas cosas son un dolor de cabeza si intenta implementarlo usted mismo y una gran oportunidad para hacer algo mal y exponer agujeros de seguridad en su aplicación, que usar un servicio de autenticación me parece casi una obviedad en este momento. Por lo tanto, el simple hecho de poder agregar algo con esencialmente unas pocas líneas de código y estar en funcionamiento suena como una forma realmente productiva de trabajar y mantener las cosas seguras.

Drew: Parece que la implementación tanto de la interfaz como de los aspectos del servidor, las cosas de la función sin servidor, es una opción natural para la implementación en Netlify. ¿Estás ligado a eso con Redwood? Quiero decir, mencionamos que Tom Preston-Werner es uno de los principales defensores de este marco, también está en la junta directiva de Netlify. ¿Crees que existe la posibilidad de un acoplamiento demasiado estrecho si tuvieras que elegir a Redwood como base para un proyecto?

Anthony: Sí, esto es algo de lo que Tom definitivamente es consciente. Ha invertido en muchas empresas que flotan. Invirtió en Prisma y Fauna. Solo quiere hacer las herramientas que quiere usar. No se trata tanto de que queramos encerrarte en esto, sino de lo que Netlify ha construido, él cree que es la mejor opción, por eso es que lo construyeron. Pero no quieren que esté bloqueado en ningún destino de implementación, y es por eso que estamos trabajando en cosas como el marco sin servidor y algunas personas han hablado sobre Begin. Queremos ser pragmáticos, queremos que funcione para cualquier caso de uso de alguien. Por lo tanto, le brindamos el 90% del camino y luego solo tiene que conectar las últimas dos cosas para que funcione con cualquiera que sea su servidor de elección.

Drew: Supongo que incluso Netlify está usando AWS Lambda para las funciones de los servidores, por lo que es realmente la parte de implementación de la que se encarga Redwood allí, y en realidad podría implementar eso en Lambda usted mismo. La publicación de su interfaz es solo archivos, ¿no es así? El resto está basado en CDN. Entonces, hay bastante flexibilidad allí sin estar demasiado atado.

Anthony: Sí, en realidad hay un término del que Tom habla como la idea filosófica central detrás de Redwood, que es que queremos llegar a una máquina de implementación universal. Esa es una especie de idea, es que puedes simplemente implementar cosas y no tienes que pensar en ello en absoluto. Ha estado hablando de esta idea durante años y años y años, y de esto se trataba incluso Jekyll en su día. Cuando escuchas eso ahora, dices: "Oh, ¿quieres decir como Netlify?" Eso es básicamente lo que Netlify es para la mayoría de las personas que trabajan en el front-end. Ya ni siquiera piensan en desplegarse, ni siquiera es un pensamiento.

Drew: Aquí está mi aplicación en Git Repo, este directorio es el front-end, este directorio es el back-end, aquí está mi base de datos, y esa es casi toda la configuración que quizás necesites para cualquier servicio que la tome y la construya. y alojarlo.

Anthony: Sí, y una cosa que también debo señalar, hace poco conseguimos la configuración de implementación predeterminada de Vercel Redwood, por lo que cuando está implementando en una aplicación del lado del servidor puede decir: "Oh, tengo la aplicación Gatsby" y sabe exactamente cómo crear una aplicación de Gatsby frente a una NextApp. Tenemos eso para Vercel ahora. Entonces, también hay opciones muy, muy buenas que no son de Netlify, si te gusta más eso.

Drew: Entonces, si quisiera comenzar y crear una aplicación y ponerla en producción esta semana, ¿Redwood está listo para eso? ¿Es maduro?

Anthony: Sí, tenemos alrededor de media docena de aplicaciones que están en producción en este momento. El primero se llamó Predict COVID, que salió en marzo y es como una aplicación de visualización de datos en tiempo real. Luego, tenemos repeater.dev hecho por Rob, es como un trabajo cron para Jamstack. Luego, está Tape.sh, Duoflag creo que es otro. Entonces, hay al menos un puñado. Si te gusta el increíble repositorio de Redwood, puedes ver una lista de todos ellos. Si vas a los foros de la comunidad, también puedes encontrar reseñas de estos, porque las personas los han puesto en producción y han dicho cómo les fue. Hasta ahora, todos han tenido éxito y nadie ha dicho: "Nunca volveré a usar esto".

Drew: Pero, es muy nuevo. Supongo que no hay escapatoria, pero en términos de madurez, Redwood es bastante nuevo, está teniendo muchos seguidores.

Anthony: Bueno, es gracioso, lo es y no lo es. Se anunció en marzo. En ese momento, Tom y Peter habían trabajado en él durante aproximadamente un año. So, they'd already put a ton of upfront work into this, so it wasn't like I'm going to announce this project with a Read Me and then start building it. By the time they announced it, it wasn't… It's not a 1.0 now, but it's pretty dang close in terms of what people would expect out of a 1.0. But, Tom is very against what we call type driven development so he always errs on the say it's not ready. So, we say it's not ready for production even though it's in production.

Drew: I think one thing that people sometimes get burned on using frameworks is that they'll build a project around the framework and then that framework will very quickly go to another major version that had backwards incompatibilities, and they're then left with a big project to update everything onto the new version of the framework. Is that something that's likely to happen with Redwood? I mean, none of us has got a crystal ball, but just with the technologies that are involved and the way it's structured, do you think that's a big danger or a little danger?

Anthony: Yeah, it's a super valid concern and definitely something the team has thought about. The CLI has an upgrade command, so you can basically every time there's a version bump, you just do a command and it bumps you up the version. I've been dealing with this a little bit just because of the series I wrote, I started it when it was on version 11 or 0.11, it's like 0.17 or something now. So, I've been slowly iterating on it as it's gone but nothing breaks. It's all, you get slowly things, or like “Oh, this is kind of a nice little touch you've got here,” but it's pretty much set in stone architecturally. Redwood as it's structured, the front or the back end is not going to change at all. It was very well thought out in terms of what they want architecturally. That's why they built it, so they could get something that's structured like this thing.

Drew: I guess with modern web development, there is a certain point where you're just never going to get away from being reliant on dependencies updating themselves and changing. I mean, even using React, React goes through as many different changes as anything else.

Anthony: That's exactly why Tom inventing semantic versioning.

Drew: I guess from the other side of that coin, if Redwood did happen to go away, which is always something we consider when picking a framework, if development stopped somehow, I guess the impact on a particular app might not be too great because it is just so heavily built on existing other projects around. Is that-

Anthony: Well, some would say that a Redwood tree can survive a lot, it survives for a very long time. That may have been why it's called that, is that you can just make a site and deploy it and it's not going to break, it's just going to work. So yeah, maintainability, sustainability, all that kind of stuff, that's huge. Being built by people who tried to scale Rails apps, I imagine they've thought a lot about that. But in terms of the going away part, that's always going to be a danger with any open source project, so I think what you have to look for is how enthusiastic is the community to continue it without the team if that ever happens. I don't think you even need to worry about that because Tom's a billionaire and he has a venture funding thing that is funding some of the development. It is an open source project that is well funded actually. It has four full time members, Tom, Rob, David, and Peter. You just go to the forums, you can see the activity that's going on, so I wouldn't worry about that too much-

Drew: Por supuesto.

Anthony: Beyond normal open source worries that come along with that stuff.

Drew: What is the community like? You mentioned the community, are there lots of people using it and contributing to the code base or is it mainly the core team who are doing the development?

Anthony: Yeah, it's very much structured to be a community thing. They want to get as much buy in from the community as possible, and this comes from the lineage like you said. There's few people with more open source cred than Tom, so he's done a really great job of bringing people into the fold. I think just my story in general is a big win for the community because I came in, I'm a boot camp student, I'm learning all this stuff as I go. I'm not pushing code to the repo, I'm making doc fixes and writing blog articles and stuff, but they still invited me to the core contributors meeting because they saw what I was doing and they thought it was adding value. Yeah, there's really a lot of things about how they approach community building that I have a lot of respect for, and that is why I've been so invested in it and putting so much of myself into it.

Drew: Some frameworks have got this sort of natural bent for certain types of projects. Por ejemplo. The Python framework, Django came out of online news publishing, and so it's a really good fit if you want to rapidly publish content like you would in a news organization. Does Redwood lean in any particular direction when it comes to the type of projects? Is it suited for content publishing or building web applications or-

Anthony: It's made to be fairly agnostic to that. It wants to be a tool that you use for a lot of stuff. First, before it was called Redwood, it was called Hammer, the idea being that you do a lot of stuff with a hammer. But, there definitely is a kind of sweet spot, which I think is the multi client type applications. So, if you know that you're starting with a web front end but you're pretty sure you're going to end up with a mobile client as well, then it's a really good fit for that because it starts you off in a way that you're going to be able to extend into having multiple clients with GraphQL, which we kind of talked about a little bit. So, I'd say that'd probably be the first thing that I would say is its sweet spot. But, it's meant to work for as many things as possible.

Drew: Does Redwood have a published roadmap of where it's going? What can we expect to be coming in the near future?

Anthony: Glad you asked. We just put out a roadmap to 1.0 less than a month ago, it was probably like two or three weeks ago. It kind of itemizes things that we're working on, things we think we're kind of close on, things we think we still have a long ways to go on. That kind of helps the community see where can I help contribute. That's one of the things we're really great about is showing here are the things that still need to be worked on. They're aiming for 1.0 by the end of the year. We'll see where we get with that, but that's the trajectory we're currently on.

Drew: One of the beauties of a Jamstack and a serverless approach I always think is that it's this idea of lots of pieces loosely joined that has served us so well in computer science up until this point. It should be really easy to scale up a Jamstack and serverless project because you can add multiple front ends or you could put more resources behind running your functions, and you can scale up a big engineering team by having people work on different small pieces. Is there a danger that adopting a framework around all of that, that you might be taking a distributed architecture and creating a tighter binding than you might otherwise have? Could Redwood become the monolith that acts as a bottleneck in your engineering efforts?

Anthony: Yeah, this is something I think about a lot because as I learned web development, I was taking… I'm in a boot camp that supposedly is full stack development, but you learn each piece in isolation. We're essentially learning the PERN stack, but you learn React, and then we learned Express. We never talked about how it actually works together. So, I do think that there is definitely a danger of not being able to comprehend in your project because of how it's all wired up. So, what I really liked about Redwood is that it just made sense. It was a mental model of how to think about my entire app and all the pieces and how they fit together in a way that really made sense to me. But, what I was surprised to find doing the Fauna project is that it's much more modular than you would think based on… You talk about it, and like you said, it sounds like it's a monolith thing, but you can rip pieces out and replace them with other pieces and they can still work. So, it's made to be a fully integrated solution, but not a solution that is tightly coupled just because this is a good way to integrate all these technologies doesn't mean you need to tightly couple them to integrate them well.

Drew: Yeah, that sounds a very promising way of structuring things, and it's going to be really exciting to see what happens with Redwood as it gets to version 1.0. Is there anything else we should know about it that we haven't talked about?

Anthony: No. I mean, I would say if you're interested, just check out the tutorial on YouTube, the RedwoodJS tutorial. They have what they call tutorial driven development, which is kind of a play on Read Me driven development, which is another thing Tom coined, that you should start with a Read Me, and then create your code to make sense with what your Read Me was. This is the idea of you create a tutorial and then you write your framework to make the tutorial work. So, that's why it's a really easy way to get spun up with it because it was made to make sense of going through the process of learning it. They've really thought about how to actually get onboarded into a massive framework with all these different pieces and all this different new tech. They progressively reveal it to you as you go. The series that I wrote is very heavily influenced by it. I essentially built the same project, but I write my own stuff as I go, and reference the docs. So, if you're interested in just learning Redwood, start with the actual tutorial and then check out my series.

Drew: So, I've been learning all about Redwood, what have you been learning about?

Anthony: Yeah, so I've been learning about CMSs, and I was actually really curious to get your thoughts on this because I imagine you've been around the block, you know a lot of CMSs. Obviously, you know you've got your WordPress's, your Drupal, but what's really interesting with something like Redwood is since you have this GraphQL stuff baked in, it has the CMS, it's just such a natural fit. So, I'm trying to figure out, what are interesting headless CMSs to check out? Which ones have GraphQL integration? Which ones have different sweet spots? If I wanted to take a CMS to build an app with RedwoodJS, what would you recommend?

Drew: That is a good question, and I'm not sure I have an immediate answer. I have looked at lots of different CMSs, not particularly with a view to GraphQL. I've not worked with GraphQL myself yet, and so that was not-

Anthony: Oh man, you've got to join the club, dude.

Drew: Yeah, no, I'm definitely getting onboard. But yes, I have a requirement at work that may be coming up to know a bit more about GraphQL, so it's certainly one of the things that I need to be learning.

Anthony: I actually learned GraphQL through Redwood. I didn't really know GraphQL, and I'd say you should know a little bit before going into it, and I had a very, very tiny basic knowledge. You can actually learn what a schema definition language is, and that GraphQL kind of jargon. You'll learn a lot and you'll pick it up as you go with Redwood.

Drew: Yeah, I should definitely get onboard and maybe doing some Redwood is the way to do it. Perhaps I need to pick up a project and start going with Redwood and see where it takes me.

Anthony: Yeah, at the very least I would say just check it out, just because it's interesting. I find it to be just a really fascinating thought experiment of how do we do modern web application development differently and more coherently.

Drew: If you, dear listener, would like to hear more from Anthony, you can find him on Twitter at ajcwebdev. His comprehensive series of articles about getting started with Redwood are on the Redwood community site, which we'll link to from the show notes. Of course, you can find all about Redwood and get started at RedwoodJS.com. Thanks for joining us today, Anthony. ¿Tienes alguna palabra de despedida?

Anthony: Solo si está interesado en algo de esto, no dude en comunicarse. Mis DM están siempre abiertos. La comunidad es muy abierta en general. Estaré encantado de explicarte o guiarte o prepararte con cualquier cosa que necesites saber para ponerte en marcha.