Smashing Podcast Episode 25 Avec Anthony Campolo : Qu'est-ce que RedwoodJS ?

Nous parlons de RedwoodJS. Qu'est-ce que cela signifie exactement d'être un framework Jamstack complet ? J'ai parlé au champion communautaire Anthony Campolo pour le savoir.

Afficher les remarques

• RedwoodJS
• Antoine sur Twitter
• La série d'articles d'Anthony A First Look at RedwoodJS

Mise à jour hebdomadaire

• "Une introduction à l'exécution de Lighthouse par programmation"
  écrit par Katy Bowman
• "Animer des composants React avec GreenSock"
  écrit par Bénédiction Krofegha
• "Concevoir pour attirer l'attention"
  écrit par Victor Yocco
• "Utilisation avancée de GraphQL dans les sites Web Gatsby"
  écrit par Aleem Isiaka
• "Comparaison des méthodes de style dans Next.js"
  écrit par Adebiyi Adedotun

Transcription

Drew McLellan : Il est étudiant à la Lambda School, étudie le développement Web full stack et contribue également à RedwoodJS. En quelque sorte un champion de la communauté, il a récemment écrit une série d'articles en 12 parties intitulée A First Look at RedwoodJS qui aide à expliquer les origines et les motivations de Redwood, ainsi que de nombreux concepts différents introduits par le framework. Donc, nous savons qu'il est un expert chez RedwoodJS, mais saviez-vous qu'il n'a jamais vu de chien ? Mes amis fracassants, veuillez accueillir Anthony Campolo.

Drew : Salut, Anthony. Comment vas-tu?

Antoine Campolo : Bonjour. Je suis fracassant, merci beaucoup de m'avoir reçu.

Drew : Je voulais vous parler aujourd'hui, et c'est probablement évident dès l'introduction, à propos de RedwoodJS. Pour ceux qui n'ont jamais entendu parler de RedwoodJS auparavant, à un niveau élevé, qu'est-ce que c'est ?

Anthony: Je pense qu'il y a plusieurs façons de le décrire en fonction de l'origine des gens, mais la définition canonique est qu'il s'agit d'un framework sans serveur à pile complète pour le Jamstack. Ainsi, il combine le développement Web complet avec des éléments de type AWS Lambda sans serveur et le Jamstack, ce qui est très important de nos jours.

Drew : Donc, c'est un framework complet qui essaie de rassembler un grand nombre d'idées autour d'un écosystème de développement Jamstack ? Est-ce correct?

Anthony : Oui, cela repousse les limites de ce qu'une application Jamstack peut être, donc en l'appelant une pile complète, Jamstack, il s'agit de savoir comment aller au-delà du simple front-end pour avoir le même type de paradigme de déploiement consistant simplement à être poussé, à obtenir tout votre code déployé. Comment pouvons-nous obtenir cela, mais aussi avec notre back-end, et avoir tout connecté ?

Drew : Maintenant, avant de plonger trop profondément dans le sujet, je pense qu'il est assez intéressant d'entendre qu'il vient d'une équipe assez expérimentée, n'est-ce pas ? Les gens derrière Redwood, ce ne sont pas des poulets de printemps. Cela ne veut pas dire qu'ils sont vieux, mais ils ont fait le tour du quartier, n'est-ce pas, en termes de développement Web ?

Anthony : Ils sont aguerris. Oui, j'ai en fait consacré un temps décent à écrire sur l'histoire du framework et les idées qui y ont conduit, et Tom Preston-Werner en est le créateur, et il est donc également connu comme le créateur de Jekyll, qui est un générateur de site statique très influent. Il a également fait TOML, le langage des fichiers de configuration. Et il était à l'origine le PDG de GitHub. Donc, son travail avec les pages Jekyll et GitHub et ce genre de choses, je pense, a vraiment conduit à ce que nous appelons maintenant le Jamstack. Beaucoup de gens diraient : « Oh, le Jamstack est nouveau. Ils font ça depuis toujours. C'est ainsi que nous avons parlé de la façon dont il s'agit d'une extension de ces idées plus anciennes, les générations de sites statiques, mais avec GraphQL et sans serveur et ces idées sur la façon d'utiliser le code de colle et les API pour faire fonctionner votre application.

Drew : Donc, cela vient certainement de personnes très ancrées dans cette communauté ? Je veux dire, le PDG de GitHub, vous n'êtes vraiment pas plus intégré dans le genre de communauté open source que cela. Donc, Redwood est un framework à pile complète et je suppose que cela signifie que vous avez du code Redwood en cours d'exécution dans le front-end et dans le back-end. Est-ce correct?

Anthony : Ouais, c'est la première chose que j'aime expliquer aux gens quand je leur montre un projet Redwood, c'est que c'est un monorepo. Ainsi, vous avez votre front-end et votre backend dans le même dépôt, puis chacun de ceux-ci vit dans ses propres dossiers. Vous avez un dossier Web, qui est votre frontal, et il est assez similaire à ce que vous obtiendriez d'une application Create React. Ensuite, vous avez le dossier API, qui est votre back-end, et c'est là que toutes vos fonctions sont essentiellement regroupées dans un seul gros gestionnaire GraphQL qui est déployé sur AWS Lambda via Netlify.

Drew : D'accord, donc en commençant par le début, comme vous le mentionnez, c'est basé sur React. Est-ce React plus un tas de code Redwood, ou est-ce simplement React? Quel est l'équilibre là-bas?

Anthony : C'est beaucoup de choses. C'est certainement juste React dans le sens où vous n'apportez pas beaucoup de bibliothèques de gestion d'état, vous n'apportez même pas de routeur en fait. Ils ont leur propre routeur qu'ils ont écrit et ils utilisent beaucoup de choses GraphQL. Donc, quand les gens parlent de React et de GraphQL et d'amis, c'est un peu ce qui se passe ici, c'est que cela vous donne beaucoup d'intégrations par défaut pour que React parle à votre GraphQL. Parce que nous avons maintenant beaucoup de conventions sur la façon d'utiliser React, mais la récupération des données est toujours un énorme problème.

Drew : Donc, c'est React configuré avec un tas d'autres outils qui fonctionnent bien avec React pour vous donner un écosystème fonctionnel pour faire ce style particulier de tâche. Est-ce une description juste?

Anthony : Ouais, non, ouais, c'est une excellente façon de le dire. La façon dont Tom l'a dit est qu'il existe toutes ces solutions de pointe, ainsi que des outils et des technologies vraiment sophistiqués que nous pouvons utiliser, mais il est vraiment difficile de les exploiter car vous avez un coût de démarrage tellement énorme et vous devez les apprendre , devant trouver comment les intégrer. Ainsi, ils ont mis le slogan comme suit : "Nous réalisons votre configuration Webpack pour vous".

Drew : Je pense que c'est un problème courant que vous entendez de la part de beaucoup de gens lorsqu'ils essaient de se lancer dans le cadre de développement moderne avec des applications JavaScript côté client et la configuration du pack Web, la configuration de toutes les différentes choses, les processus de construction, le étapes de construction. Cela peut être tout un champ de mines, n'est-ce pas, pour que tout soit relié et fonctionne ? Et c'est un long chemin avant d'arriver à "Hello, World!". Alors, Redwood nous donne tout cela préconfiguré ?

Anthony : Ouais, c'est vraiment une convention sur l'idée de type de configuration, parce que vous avez… Tom était, comme il a construit GitHub avec Ruby on Rails et Rob, l'un des autres contributeurs principaux, il a toujours été un développeur Rails. Ils ont beaucoup d'idées avec lesquelles ils s'alignent philosophiquement en termes de Rails, mais ils veulent prendre ces conventions sur les idées de configuration, les idées de framework de pile complète, et les mettre en œuvre avec toute la technologie moderne dont nous disposons maintenant.

Drew: Donc, vous avez mentionné que Redwood vous donne un routeur ou un routeur, comme nous le disons de ce côté-ci de l'étang, est-ce qu'il vient avec des choses comme des composants par défaut et tout ce genre de choses dans React, ou êtes-vous juste alors mettre tout cela en place vous-même ?

Anthony : Ouais, le routeur est, il est très sophistiqué. Il fait la plupart des choses que vous obtiendriez uniquement du routeur React, il a juste des idées différentes sur la façon dont ceux-ci devraient être implémentés, car Ensuite, ils ont aussi leur propre routeur, et ce n'est toujours pas vraiment compris comment nous souhaitez que notre routage d'application à page unique fonctionne. À cause de Suspense, vous avez beaucoup de questions de ce genre sur où les choses asynchrones vont-elles arriver ? Nous avons avec Redwood, cette idée d'une cellule, et c'est ce qui fait vraiment la récupération de vos données pour vous.

Drew : Alors, peut-être pourrions-nous en parler un peu ? Qu'est-ce qu'une cellule en termes de séquoia ?

Anthony : Oui, donc une cellule est un moyen par défaut d'écrire une requête GraphQL, puis de faire savoir à votre page si vous récupérez les données, si vous obtenez une erreur, si vous êtes dans un état de chargement, ou si… Il y a un état de plus, j'oublie. Mais oui, cela vous donne donc les différents états dans lesquels vous pouvez vous trouver, selon que vous obtenez ou non vos données. C'est configuré avec Apollo sous les couvertures. Donc, si vous utilisez Redwood, vous utilisez Apollo comme client GraphQL, mais vous n'avez jamais à y penser. Vous n'avez jamais à écrire d'Apollo ni même à y penser, tout est intégré. Il vous permet simplement d'écrire des requêtes GraphQL, ce qui était vraiment le rêve de la raison pour laquelle les gens voulaient GraphQL, c'est que c'était ce langage de requête très simple que les développeurs frontaux pourrait utiliser. Mais ensuite, vous deviez comprendre comment configurer un serveur GraphQL, vous deviez comprendre toutes ces autres choses, et comment faire pour que tout soit câblé. Donc, il fait toute l'intégration de GraphQL pour vous afin que vous puissiez simplement écrire GraphQL, vous n'avez pas à penser à la façon dont j'implémente même GraphQL.

Drew : Donc, je suppose que l'une des tâches classiques d'un framework consiste à prendre tout le code de la plaque de chaudière que vous pourriez écrire vous-même et à l'implémenter pour vous, et à ranger le chemin dans les coulisses pour que vous n'ayez jamais à regarder cette plaque de chaudière plus jamais, et vous pouvez simplement écrire le code qui est unique à votre situation. Je suppose que c'est ce qui se passe avec une cellule, n'est-ce pas ? Il n'y a rien de révolutionnaire ici, c'est quelque chose que vous pouvez configurer un composant React pour avoir tous ces états différents et vous pouvez vous connecter à Apollo et vous pouvez faire tout cela vous-même, mais c'est en fait beaucoup de travail et c'est un modèle commun. Ainsi, Redwood a été rangé dans un joli motif réutilisable que vous pouvez simplement commencer à utiliser sans avoir à y penser. Est-ce une bonne description?

Anthony : Oui, ils ont trouvé le nom, mais ils reconnaissent définitivement que c'était une pratique qu'ils voyaient fréquemment et qu'ils voyaient beaucoup de gens le coder eux-mêmes, et ils ont décidé qu'ils voulaient un moyen déclaratif de récupérer vos données. Donc, c'est pourquoi vous avez cette configuration, car elle vous permet simplement d'avoir vos différents états et vous n'avez pas à faire de logique si/alors pour comprendre, vous devez le faire si cela se produit. Il s'agit donc d'avoir une seule façon de déclarer tous les différents états dans lesquels vos données pourraient se trouver lorsque vous les chargez.

Drew : C'est l'une des caractéristiques de React, n'est-ce pas, que React n'essaie pas de vous donner une architecture pour votre projet, il vous laisse décider comment vous allez structurer les choses. Cela, bien sûr, a des avantages et des inconvénients. Mais, il semble que Redwood vous impose une partie de cette structure afin que vous n'ayez pas à y penser et qu'il puisse mettre la plomberie pour vous et reprendre en quelque sorte là où React s'est arrêté en termes de vous donner ce genre de structure.

Anthony : Ouais, et je pense que c'est vraiment intéressant que nous ayons vu plusieurs tentatives différentes pour cette solution à ce problème, parce que je veux dire que vous avez eu des gens qui le disent depuis toujours : « Pourquoi n'y a-t-il pas de Rails pour JavaScript ou un Rails pour React ? » Il y a une excellente interview de Full Stack Radio entre Michael Chan et Adam Wathan intitulée React n'est pas un concurrent de Rails. C'est l'un des différents cadres.

Anthony : Les autres sont BlitzJS qui a eu un buzz décent, et puis Bison est une sorte de nouveau et à venir. Ils ont tous une pile similaire, mais ils utilisent des pièces différentes. Vous aurez la requête React au lieu d'Apollo, ou vous aurez Chakra au lieu de Tailwind. Les gens qui rassemblent toutes ces pièces dans leurs piles, toutes ces piles sont en quelque sorte, ils se battent, c'est une compétition très amicale. En fait, c'est une chose que j'apprécie vraiment, c'est que nous collaborons également tous entre les frameworks. Il n'y a là aucune animosité.

Drew : Donc, nous avons mentionné Apollo et GraphQL, Redwood utilise assez fortement GraphQL comme l'une des pièces maîtresses, n'est-ce pas, du framework ? Nous pouvons probablement consacrer un épisode de podcast entier à GraphQL uniquement, mais pour ceux qui ne sont pas familiers, quelle pièce GraphQL fait-il ici, quel problème résout-il dans ce contexte ?

Anthony : Oui, c'est une excellente question. Quand je dis aux gens ce qu'ils doivent savoir pour bien démarrer avec Redwood, je dirais que vous auriez dû utiliser l'application Create React, juste si vous avez créé une application Create React et que vous l'avez déployée sur Netlify ou Vercel, ça vous fera un bon départ. Ensuite, connaissez au moins un peu GraphQL car il est très central. Ainsi, le GraphQL est la façon dont votre front-end parlera à votre back-end. Ils disent que c'est un langage de requête pour les API, l'idée étant qu'il est censé être une alternative aux méthodes d'API RESTful, et qu'au lieu de faire cette chose RESTful, vous envoyez des requêtes qui spécifient exactement la structure de données hiérarchique que vous souhaitez recevoir de la base de données. Il faut donc un peu plus de temps de démarrage pour que votre serveur GraphQL communique avec les deux éléments. Ensuite, une fois que vous l'avez là, les développeurs frontaux ont la possibilité d'obtenir des données de manière beaucoup plus flexible. Vous n'avez pas besoin de tous ces différents points de terminaison d'API que vos back-ends doivent continuer à créer.

Drew : Donc, s'il y a des changements dans les exigences du front-end, vous pouvez probablement modifier votre requête GraphQL et vous n'avez pas besoin de l'aide de quelqu'un qui travaille sur le back-end pour faire ce changement pour vous ?

Anthony : Je veux dire, le vrai rêve est que vous puissiez y ajouter un client mobile, qu'il soit finalement aussi flexible qu'il le devienne, vous pouvez avoir plusieurs clients qui parlent tous à votre seule API. Votre API GraphQL devient votre source de vérité, c'est là que toute votre logique est centralisée. Ensuite, vous pouvez créer toutes ces différentes couches de vue par-dessus.

Drew : Donc, nous avons GraphQL qui nous donne la possibilité d'interroger une sorte de back-end. Dans Redwood, quel est le back-end ?

Antoine : Ouais. Il existe plusieurs façons de créer votre back-end. Il y a la façon dont vous sortirez de la boîte avec le tutoriel, c'est-à-dire que vous utilisez la base de données Postgres déployée sur Heroku, super facile, super simple. Ensuite, votre application Redwood lui parle avec Prisma. Je ne sais pas si vous connaissez du tout Prisma, mais c'est comme un O/RM. Ils disent spécifiquement que ce n'est pas un O/RM, c'est un générateur de requêtes, qui est un peu plus bas. Mais, juste pour l'expliquer aux gens, Prisma est la chose qui vous permet de parler à votre base de données. Il effectue vos migrations et configure vos tables. Il fait tout le travail SQL donc vous n'avez pas à écrire de SQL. Pour moi, cela ressemble à un O/RM. Vous n'avez pas nécessairement besoin d'utiliser Prisma pour utiliser Redwood.

Anthony : En fait, j'ai construit une application juste de preuve de concept où nous avons utilisé FaunaDB à la place. FaunaDB, ils ont leur propre API GraphQL, vous pouvez donc simplement envoyer l'API GraphQL directement à Fauna, puis faire vos mutations de base de données de cette façon. Vous perdez une grande partie des fonctionnalités de la CLI de Prisma, mais Prisma est vraiment un facteur de commodité pour travailler très facilement avec votre base de données relationnelle. Mais vraiment, tout ce à quoi vous pouvez penser, vous pouvez comprendre comment le connecter à Redwood, c'est ce que j'ai découvert simplement parce qu'il est construit autour de GraphQL et que le but est de pouvoir parler à toutes ces différentes pièces.

Drew : Donc, Prisma est essentiellement une sorte de couche d'abstraction entre votre code et le magasin de données que vous utilisez et que Prisma prend en charge, est-ce… ou fait-il des choses plus intelligentes que cela ?

Anthony : Ouais, donc vous écrivez un schéma, donc vous créez un fichier schema.Prisma, et il aurait un article de modèle, puis il aurait un identifiant et un entier et une incrémentation automatique, comme la piqûre de titre, la chaîne de corps, créé à la date, l'heure . Donc, vous créez essentiellement ce que vous voulez être dans votre base de données avec les types, puis il fait les choses pour vous afin que vous n'ayez pas à interagir avec la base de données.

Drew : Donc, vous utilisez Prisma pour définir, je suppose, à quel type de base de données ou à quel type de magasin de données vous vous adressez. Ensuite, vous y disposez vos différents modèles mvc pour utiliser ce langage. Ainsi, lorsque votre application communique avec les magasins de données, elle utilise en quelque sorte une instance d'un client Prisma, n'est-ce pas ? C'est ce qui se passe ?

Antoine : Oui. Ouais, c'est exactement ça. Ainsi, dans le dossier API de votre back-end, vous avez un dossier lib avec un db.js, et juste par défaut, votre client Prisma est configuré. Donc, c'est tout ce que vous sortez de la boîte, et comme vous l'avez dit, Prisma peut fonctionner avec différentes bases de données. Il peut basculer entre SQLite pour le développement et Postgres pour la production, ce genre de choses. Ce sont principalement des relations relationnelles en ce moment, mais la feuille de route contient des choses comme Mongo et Fauna.

Drew : Donc, c'est très utile si vous pouvez configurer et utiliser SQLite dans votre environnement de développement local pendant que vous faites fonctionner les choses, puis passez en production avec quelque chose comme MySQL.

Anthony : C'est exactement comme ça que le tutoriel est configuré, c'est le flux de travail qu'il vous montre.

Drew : C'est assez intéressant, n'est-ce pas, de voir une approche très moderne d'un framework puis de se rabattre sur certaines de ces bases de données plus traditionnelles comme MySQL. Je connais très bien MySQL. Je l'aime pour sa stabilité et j'aime la manière relationnelle de stocker les données. Je pense que cela fonctionne si bien pour tant de choses. Souvent, vous voyez le bébé jeté qui était l'eau du bain en ce qui concerne les nouveaux types de stockage de données, il est donc assez intéressant de voir Redwood prendre en charge par défaut ces bonnes et anciennes bases de données relationnelles.

Anthony : Ouais, non, c'est un si bon point, parce que je dis que pour toutes les nouvelles choses que Redwood combine, il y a certaines choses qui disent en fait que l'ancienne méthode éprouvée est en fait la meilleure. Donc, ils sont vraiment gros sur les bases de données relationnelles. Cela vient de l'expérience de Tom avec l'utilisation de Rails et d'avoir un back-end relationnel. Active Record était la couche O/RM que Prisma voulait rapprocher.

Drew : Je suppose que nous parlons ici d'une architecture sans serveur avec Redwood, et nous avons parlé à Chris Coyier, il y a deux ou trois épisodes, tout sur l'utilisation sans serveur des API et de la fonction cloud, etc. Donc, en prenant du recul, si vous deviez penser en termes de framework basé sur un serveur, comme nous l'avons mentionné Ruby on Rails ou quelque chose comme Laravel dans le monde PHP. Même avec un frontal React, votre requête API exécuterait du code qui est du code Rails ou du code Laravel plus votre code utilisateur et votre configuration. Est-ce la même chose avec Redwood ? Existe-t-il un véritable code de serveur Redwood qui s'exécute, ou s'agit-il simplement de plus d'outils, de structure et de colle qui vous permettent d'implémenter le vôtre ?

Anthony : Ouais, donc dans le back-end, il y a un fichier spécifiquement qui est un moyen de prendre votre SDL, donc vous avez votre langage de définition de schéma, et puis vous avez ce qu'on appelle vos services, qui sont comme vos méthodes pour parler à votre fin arrière. Ensuite, tout cela est assemblé dans un gestionnaire GraphQL qui est déployé sur une seule fonction Lambda. Il est donc spécifiquement optimisé pour Lambda. En fait, nous avons récemment demandé à quelqu'un de le faire avec le framework sans serveur, et nous avons des personnes qui travaillent sur Azure et Google Cloud quelque chose. Ce n'est pas la fonction Google Cloud, c'est celle construite en plus de cela. Mais oui, il est donc actuellement essentiellement optimisé pour déployer votre back-end en tant que fonction GraphQL dans un AWS Lambda. C'est ce qui se passe de magique dans le code que je ne comprends pas, mais c'est l'explication de haut niveau.

Drew : Donc, il existe des outils de déploiement qui prennent tout le code que vous avez écrit, le rassemblent dans une sorte de boule de code magique qui peut être exécutée dans le cloud et la place sur AWS ou est-ce que vous devez-vous encore gérer ce processus vous-même ?

Anthony : Ouais, donc tout se fait via Netlify si vous suivez le tutoriel. Vous n'avez pas vraiment à vous soucier de toutes sortes de fonctions sans serveur vous-même. Tout ce qui relie votre back-end pour le pousser dans AWS Lambda, tout est géré, vous n'avez pas à toucher à ce code. Tout cela est généré dès le départ selon vos conventions sur vos configurations, vous n'avez donc pas vraiment à réfléchir trop à la façon de le rendre sans serveur. C'est sans serveur par défaut. C'est vraiment une chose difficile à comprendre. Il m'a fallu du temps pour m'y faire.

Drew : Oui, parce que c'est un point important, ce n'est pas parce qu'il y a en fait quelques domaines différents dont nous suivons ici la trace. Nous avons, je pense, trois domaines différents. Nous avons notre application frontale React, qui s'exécute dans le navigateur, puis nous avons une API basée sur GraphQL, fonctionnant comme une fonction cloud, et qui répond à nos requêtes, mais qui interagit ensuite avec un magasin de données qui utilise Prisma. Et ce magasin de données est quoi et où, parce que vous ne pouvez pas exécuter un serveur MySQL sur Netlify, n'est-ce pas ?

Anthony : Oui, c'est là qu'intervient Heroku. Ainsi, dans la toute dernière partie du didacticiel, vous déployez votre front-end sur Netlify, puis vous déployez votre back-end sur Heroku Postgres et vous récupérez simplement vos variables de configuration depuis Heroku, branchez-le dans Netlify. Faire en sorte que votre frontal Netlify communique avec votre back-end Postgres est une chose vraiment très simple. Ils voulaient aller avec ce qui allait être le plus facile à faire tourner pour quiconque, mais toujours avoir une bonne technologie stable et testée au combat. À la fin, ce que vous obtenez en suivant simplement les instructions est vraiment incroyable.

Drew : Les passionnés de Jamstack connaissent des services comme FaunaDB que vous avez mentionné qui fournit un magasin de données en tant qu'API, AWS a DynamoDB, Google a Cloud SQL, etc. Donc, vous avez mentionné que Redwood envisageait de s'intégrer, ou je suppose que Prisma est le composant ici qui envisage de s'intégrer à ces types de services plus tard ?

Anthony : Oui, c'est une bonne question. C'est quelque chose dont je parle en fait avec Ryan Chenkie chez Prisma sur le genre d'aide, est-ce que c'est le genre d'histoire de base de données pour Redwood pour des choses qui ne fonctionnent pas nécessairement avec Prisma ? Serait-il préférable de trouver un moyen de faire fonctionner Redwood directement comme je l'ai fait avec Fauna ou serait-il plus logique d'implémenter un pilote pour Prisma? Donc, il y a différentes façons de l'aborder. Il y a évidemment un million de bases de données différentes maintenant que tout le monde veut utiliser, c'est donc à quel point êtes-vous motivé pour y intégrer votre magasin de données. Il y a beaucoup de contributions communautaires là-dedans.

Drew : Donc, parce que Prisma comprend votre modèle et sait comment les interroger, est-il capable de générer une sorte de migrations ou des choses comme ça pour vous aider à configurer cette base de données ?

Anthony : C'est exactement ce que vous perdez lorsque vous devez retirer Prisma et récupérer vos données, c'est que vous perdez toutes les fonctions de migration. Il a une CLI très avancée qui fait une tonne de choses pour vous, vous pouvez donc parcourir tout le didacticiel Redwood et entrer les commandes Prisma et vous n'avez aucune idée de ce qu'il fait, cela fonctionne tout simplement. C'est un très bon outil pour faire tout ce genre de choses de type base de données que vous voulez vous assurer que vous avez bien fait et vous voulez vous assurer que c'est fait correctement.

Drew : Il semble que le fait d'avoir un très bon outil autour des frameworks soit une tendance assez moderne, n'est-ce pas ? Pour ne pas simplement dire : "Voici tout ce que ce framework peut faire, mais voici peut-être quelques outils CLI qui vont en faire tout un tas pour vous." Redwood a-t-il des outils pour des choses comme les générateurs CLI et des trucs pour vous permettre d'être opérationnel rapidement ?

Anthony : C'est probablement la plus grande fonctionnalité clé que vous obtenez de Redwood, c'est que vous obtenez tout un ensemble de générateurs très sophistiqués. Pour tous ceux qui ont déjà vu la démo originale de Ruby on Rails, que DHH a donnée, il crée un blog en 15 minutes environ et il fait tout cela avec Rails, et les gens disent : "Whoa, c'est incroyable." C'est l'effet recherché par Redwood. Ils veulent que vous puissiez tout faire tourner très rapidement afin que vous puissiez générer des pages, vous pouvez générer des mises en page, vous pouvez générer vos cellules, dont je parlais, et vous pouvez faire une commande d'échafaudage qui va créer votre ensemble Interface CRUD. J'ai une section entière, la quatrième partie de la série de blogs, qui explique simplement tout le code que l'échafaudage vous donne. Cela vous donne tellement de code. Il y a un générateur éteint, il y a même un générateur Tailwind qui configure votre vent arrière pour vous.

Drew : C'est incroyable. Je me souviens avoir vu la démo de Rails de DHH. Je veux dire, c'était probablement, quoi, il y a 15 ans maintenant, quand il a fait cet échafaudage pour la première fois et vous a montré, et vous obtenez un panneau de contrôle assez rudimentaire mais fonctionnel essentiellement pour vous permettre de créer de nouveaux éléments, de les modifier, de les supprimer, etc. . Cela peut être inestimable dans un projet, en particulier dans une sorte d'environnement dynamique où, d'accord, vous allez peut-être implémenter de meilleurs outils à l'avenir pour éditer ce contenu, mais cela signifie être capable de faire tourner quelque chose rapidement, vous pouvez obtenir tester les données, ou vous pouvez même les confier à une équipe de contenu qui pourrait commencer à travailler pendant que vous travaillez sur le front-end, donc c'est vraiment utile.

Drew : Si vous vouliez simplement déployer cela et l'avoir en production, vous pouvez probablement le déployer avec votre code frontal, mais vous auriez besoin d'un moyen de sécuriser cet aspect, ces racines dans votre application.

Anthony : Oui, il y a plusieurs options différentes pour l'authentification. Vous pouvez utiliser l'identité Netlify. C'est la valeur par défaut si vous allez dans le didacticiel, puis vous pouvez également utiliser Auth0, puis un que je ne connais pas appelé Magic.Link, et il y en aura probablement quelques autres ajoutés à l'avenir. Mais oui, il y a donc déjà quelques solutions intégrées, et c'est la toute dernière chose que vous faites, donc c'est la toute dernière partie de ma série de blogs en 12 parties est celle d'Auth. Je ne pense pas avoir jamais compris Auth avant d'utiliser Redwood. C'est difficile et ils ont certainement fait du bon travail avec ça.

Drew : Est-ce que cela s'intègre au niveau de la route, ou au niveau de la route, désolé, comment sécurisez-vous les choses ?

Anthony : Ouais, donc une partie de la façon dont ils ont leur propre routeur, ils ont aussi… Vous pouvez faire des routes privées, donc ils ont un composant de route privée. Ensuite, votre formulaire de connexion réel, c'est ce que vous obtenez de l'identité Netlify, vous n'avez donc pas besoin de créer un formulaire et de gérer votre état avec cela, c'est là que de nombreux problèmes entrent en jeu. En supprimant les éléments vraiment clés, vous pouvez simplement implémenter un accès basé sur les rôles. Nous avons ajouté un contrôle d'accès basé sur les rôles qui a été fait au cours des deux dernières semaines, soit David T. Donc, il y a beaucoup de travail en cours pour créer d'autres façons de le faire, mais ce qu'ils ont maintenant est déjà… ça marche, ça ' vous rendra fonctionnel.

Drew : Les gens disent toujours à propos de la cryptographie de hachage d'algorithme de sécurité, que vous ne devriez jamais écrire la vôtre car elle ne sera jamais aussi bonne que les choses qui existent. De plus en plus, je pense que c'est également vrai pour l'authentification à un niveau supérieur ; que l'authentification est un domaine tellement complexe de nos jours que les gens veulent non seulement se connecter à votre site avec des informations d'identification uniques, mais ils peuvent vouloir s'authentifier à l'aide de Google, ou ils peuvent vouloir s'authentifier à l'aide d'un appareil Apple, ou ils peuvent vouloir une authentification à deux facteurs , ou ils peuvent souhaiter l'intégrer à un service d'authentification unique qu'ils utilisent dans une entreprise. Toutes ces choses sont un tel casse-tête si vous essayez de l'implémenter vous-même et tellement d'occasions de vous tromper et d'exposer des failles de sécurité dans votre application, que l'utilisation d'un service d'authentification me semble presque une évidence à ce stade. Ainsi, le simple fait de pouvoir déposer quelque chose avec essentiellement quelques lignes de code et d'être opérationnel semble être une façon vraiment productive de travailler et de garder les choses en sécurité.

Drew : Il semble que le déploiement des aspects front-end et serveur, les fonctions sans serveur, est naturellement adapté au déploiement sur Netlify. Êtes-vous lié à cela avec Redwood? Je veux dire, nous avons mentionné que Tom Preston-Werner est l'un des principaux partisans de ce cadre, il est également membre du conseil d'administration de Netlify. Pensez-vous qu'il existe un potentiel de couplage trop étroit si vous deviez choisir Redwood comme base d'un projet ?

Anthony : Ouais, c'est quelque chose dont Tom est définitivement conscient. Il a investi dans beaucoup d'entreprises qui flottent. Il a investi dans Prisma et Fauna. Il veut juste fabriquer les outils qu'il veut utiliser. Il ne s'agit pas tant de vouloir vous enfermer dans cette chose que de ce que Netlify a construit, il pense être la meilleure option, c'est pourquoi ils ont construit autour de cela. Mais, ils ne veulent pas qu'il soit verrouillé sur une seule cible de déploiement, et c'est pourquoi nous travaillons sur des choses comme le framework sans serveur et certaines personnes ont parlé de Begin. Nous voulons être pragmatiques, nous voulons que cela fonctionne quel que soit le cas d'utilisation de quelqu'un. Donc, nous vous obtenons 90% du chemin et il vous suffit ensuite de câbler les deux dernières choses pour le faire fonctionner avec les serveurs de votre choix.

Drew : Je suppose que même Netlify utilise AWS Lambda pour les fonctions des serveurs, donc c'est vraiment la partie déploiement qui est prise en charge par Redwood là-bas, et en fait vous pouvez la déployer vous-même sur Lambda. La publication de votre frontal n'est que des fichiers, n'est-ce pas, le reste est basé sur CDN ? Donc, il y a beaucoup de flexibilité là-bas sans être trop lié.

Anthony : Ouais, il y a en fait un terme dont Tom parle comme l'idée philosophique de base derrière Redwood, qui est que nous voulons arriver à une machine de déploiement universelle. C'est un peu l'idée, c'est que vous pouvez simplement déployer des choses et vous n'avez pas du tout à y penser. Il parle de cette idée depuis des années et des années et des années, et c'est ce dont parlait Jekyll à l'époque. Quand vous entendez ça maintenant, vous vous dites : « Oh, tu veux dire comme Netlify ? C'est essentiellement ce que Netlify est pour la plupart des gens qui travaillent sur le front-end. Ils ne pensent même plus à se déployer, ce n'est même pas une pensée.

Drew : Voici mon application dans un Git Repo, ce répertoire est le front-end, ce répertoire est le back-end, voici ma base de données, et c'est à peu près autant de configuration que vous auriez peut-être besoin pour ensuite n'importe quel service pour le prendre et le construire et hébergez-le.

Anthony : Oui, et une chose que je devrais également souligner, nous venons tout juste de configurer le déploiement par défaut de Vercel Redwood, donc lorsque vous déployez sur une application côté serveur, vous pouvez dire : « Oh, j'ai l'application Gatsby », et il sait exactement comment créer une application Gatsby par rapport à une NextApp. Nous avons cela pour Vercel maintenant. Donc, il existe également de très bonnes options non Netlify, si vous êtes plus intéressé par cela.

Drew : Donc, si je voulais commencer et créer une application et la mettre en production cette semaine, est-ce que Redwood est prêt pour cela ? Est-il mature ?

Anthony : Oui, nous avons environ une demi-douzaine d'applications en production en ce moment. Le premier s'appelait Predict COVID, qui est sorti en mars, et c'est comme une application de visualisation de données en temps réel. Ensuite, nous avons repeater.dev est fait par Rob, c'est comme un travail cron comme chose pour Jamstack. Ensuite, il y a Tape.sh, Duoflag je pense en est un autre. Donc, il y en a au moins une poignée. Si vous allez au repo Redwood génial, vous pouvez voir une liste de tous. Si vous allez sur les forums de la communauté, vous pouvez également trouver des comptes rendus de ceux-ci, car les gens les ont mis en production et ont en quelque sorte expliqué comment cela s'était passé. Jusqu'à présent, ils ont tous réussi et personne n'a dit : « Je ne l'utiliserai plus jamais.

Drew : Mais, c'est très nouveau. Je suppose qu'il n'y a pas moyen d'y échapper, mais en termes de maturité, Redwood est assez nouveau, il est bien suivi.

Anthony : Eh bien, c'est drôle, ça l'est et ce n'est pas le cas. Il a été annoncé en mars. À ce stade, il avait été travaillé pendant environ un an par Tom et Peter. 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 : Bien sûr.

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. Par exemple. 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. Avez-vous des mots d'adieu?

Anthony : Juste si vous êtes intéressé par l'un de ces trucs, n'hésitez pas à nous contacter. Mes DM sont toujours ouverts. La communauté est très ouverte en général. Je serai heureux de vous expliquer ou de vous guider ou de vous préparer avec tout ce que vous devez savoir pour commencer.