Catégories
Plugin et site web

Qu'est-ce que RedwoodJS? – Magazine Smashing

Nous parlons de RedwoodJS. Que signifie exactement être un framework Jamstack à pile complète? Drew McLellan s'entretient avec le champion communautaire Anthony Campolo pour le savoir.

Nous parlons de RedwoodJS. Que signifie exactement être un framework Jamstack à pile complète? J'ai parlé au champion communautaire Anthony Campolo pour le savoir.

Afficher les notes

Mise à jour hebdomadaire

Transcription

Photo d'Anthony CampoloDrew McLellan: Il est étudiant à l’école Lambda, étudiant le développement Web complet et contributeur à RedwoodJS. Quelque chose d'un champion de la communauté, il a récemment écrit une série d'articles en 12 parties intitulée Un premier regard sur RedwoodJS qui aide à expliquer les origines et les motivations de Redwood, ainsi que de nombreux concepts différents que le cadre introduit. Nous savons donc qu’il est un expert chez RedwoodJS, mais saviez-vous qu’il n’a jamais vu de chien? Mes amis fracassants, veuillez souhaiter la bienvenue à Anthony Campolo.

A dessiné: Salut Anthony. Comment allez-vous?

Anthony Campolo: Bonjour. Je fracasse, merci beaucoup de m'avoir invité.

A dessiné: 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, à 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 la provenance des gens, mais la définition canonique est qu'il s'agit d'un framework sans serveur complet 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 une grande chose de nos jours.

A dessiné: C'est donc un framework full stack qui tente 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 full stack, 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 de simplement être poussé, obtenir votre tout code déployé. Comment pouvons-nous obtenir cela, mais aussi avec notre back-end, et tout connecter?

A dessiné: Maintenant, avant d’aller trop loin, je pense que c’est assez intéressant d’entendre qu’il s’agit d’une équipe assez chevronnée, non? Les gens derrière Redwood, ce ne sont pas des poulets de printemps. Pour ne pas dire qu'ils sont vieux, mais ils ont fait le tour du bloc, n'est-ce pas, en termes de développement Web?

Anthony: Ils sont chevronnés. Oui, j'ai en fait consacré beaucoup de temps à écrire sur l'histoire du framework et les idées qui y ont conduit, et Tom Preston-Werner 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 du fichier de configuration. Et il était le PDG de GitHub à l'origine. Donc, son travail avec les pages Jekyll et GitHub et ce genre de choses, je pense, a vraiment conduit à ce que nous considérons maintenant comme 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 anciennes idées, 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 glue et les API pour faire fonctionner votre application.

A dessiné: Donc, cela vient certainement de gens qui sont très intégrés 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 full stack 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 référentiel, puis chacun d'entre eux vit dans ses propres dossiers. Vous disposez d'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 placées dans un gros gestionnaire GraphQL qui est déployé sur AWS Lambda via Netlify.

A dessiné: D'accord, donc en commençant par l'avant, comme vous le dites, c'est basé sur React. Est-ce React plus un tas de code Redwood, ou est-ce simplement React? Quel est le solde?

Anthony: C’est beaucoup de choses. C'est vraiment React dans le sens où vous n'introduisez pas beaucoup de bibliothèques de gestion d'état, vous n'introduisez même pas de routeur en fait. Ils ont leur propre routeur qu'ils ont écrit et ils utilisent beaucoup de trucs GraphQL. Ainsi, lorsque les gens parlent de React, GraphQL et de leurs 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.

A dessiné: Donc, c'est React configuré avec un tas d'autres outils qui fonctionnent bien avec React pour vous donner un écosystème fonctionnel pour effectuer ce type de tâche particulier. 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 meilleures solutions de race qui existent, ainsi que des outils et des technologies vraiment sophistiqués que nous pouvons utiliser, mais il est vraiment difficile de les exploiter parce que vous avez un coût de démarrage si énorme et que vous devez les apprendre. , devoir trouver comment les intégrer. Donc, ils mettent le slogan comme: "Nous faisons votre configuration Webpack pour vous."

A dessiné: Je pense que c'est un problème commun 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, les étapes de construction . Cela peut être tout un champ de mines, n'est-ce pas, pour que tout soit connecté et fonctionne? Et il reste encore beaucoup de temps avant d’arriver à "Hello, World!". Alors, Redwood nous donne tout ce préconfiguré?

Anthony: Ouais, c’est vraiment une convention sur l’idée du 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 cadre complet, et les implémenter avec toute la technologie moderne dont nous disposons actuellement.

A dessiné: Donc, vous avez mentionné que Redwood vous donne un routeur ou un routeur, comme nous le disons de ce côté de l'étang, est-il livré avec des éléments tels que des composants par défaut et tout ce genre de choses dans React, ou êtes-vous juste à mettre en œuvre tout ça toi-même?

Anthony: Oui, le routeur 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 quant à la façon dont elles devraient être implémentées, car ensuite, ils ont également leur propre routeur, et il n'est toujours pas vraiment compris comment nous souhaitez que le routage de notre application sur une seule page fonctionne. À cause de Suspense, vous avez beaucoup de ce genre de questions sur où vont les choses asynchrones? Nous avons avec Redwood, cette idée de cellule, et c'est ce que vos données récupèrent vraiment pour vous.

A dessiné: Alors, peut-être pourrions-nous entrer un peu dans cela? 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 en sorte que votre page dise 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 encore un état, j'oublie. Mais oui, cela vous donne les différents états dans lesquels vous pouvez vous trouver en fonction du fait que vous recevez vos données ou non. Il 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 savoir pourquoi 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 cela 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.

A dessiné: Donc, je suppose que l'un des travaux classiques d'un cadre est de prendre tout le code de plaque de chaudière que vous pourriez écrire vous-même et de l'implémenter pour vous, et de ranger le chemin dans les coulisses pour que vous n'ayez plus jamais à regarder cette plaque de chaudière. , et vous pouvez simplement écrire le code qui est unique à votre situation. Je suppose que c’est ce qui se passe avec une cellule, non? 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 accrocher à 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. Donc, Redwood a 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 ont vu 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. C'est pourquoi vous avez cette configuration, car elle vous permet d'avoir vos différents états et vous n'avez pas à faire si / alors la logique pour comprendre, vous devez le faire si cela se produit. Il s'agit donc simplement de disposer d'une seule façon de déclarer tous les différents états dans lesquels vos données pourraient se trouver lorsque vous les chargez.

A dessiné: 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 permet de 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 pour que vous n'ayez pas à y penser et pour 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: Oui, et je pense que c'est vraiment intéressant que nous ayons vu plusieurs tentatives différentes pour résoudre ce problème, parce que je veux dire que vous avez 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 la radio Full Stack entre Michael Chan et Adam Wathan intitulée React is Not a Rails concurrent. C'est l'un des différents cadres.

Anthony: Les autres sont BlitzJS qui a eu beaucoup de buzz, puis Bison est en quelque sorte un nouveau et à venir. Ils ont tous une pile similaire, mais ils utilisent des pièces différentes. Vous aurez une 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 tous aussi entre les frameworks. Il n’y a pas d’animosité.

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

Anthony: Ouais, c'est une excellente question. Lorsque 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 donnera un bon départ. Ensuite, connaissez au moins un peu GraphQL car il est très central. Ainsi, 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 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 en retour. la base de données. Donc, il faut un peu plus de temps de démarrage pour que votre serveur GraphQL parle aux deux pièces. Ensuite, une fois que vous l'avez là, les développeurs front-end 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 responsables back-end doivent continuer à créer.

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

Anthony: Je veux dire, le vrai rêve est que vous puissiez lancer un client mobile, que ce soit finalement aussi flexible que cela 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.

A dessiné: Donc, nous avons GraphQL là-bas qui nous permet d'interroger une sorte de back-end. Dans Redwood, quel est le back-end?

Anthony: Ouais. Il existe plusieurs façons de créer votre back-end. Voici comment vous sortirez de la boîte avec le didacticiel, qui consiste à utiliser 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, dans le but de simplement l'expliquer aux gens, Prisma est ce qui vous permet de parler à votre base de données. Il effectue vos migrations et configure vos tables. Il fait tout le truc SQL pour que vous n'ayez pas à écrire du 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 créé une application de preuve de concept dans laquelle nous avons utilisé FaunaDB à la place. FaunaDB, ils ont leur propre API GraphQL, vous pouvez donc simplement envoyer l'API GraphQL directement à Fauna, puis effectuer les mutations de votre 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 pourriez penser, vous pourriez 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.

A dessiné: Ainsi, Prisma est essentiellement une sorte de couche d'abstraction entre votre code et le magasin de données que vous utilisez, vraisemblablement, que Prisma prend en charge, est-ce que… 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 post de modèle, puis il aurait un id et un entier et une incrémentation automatique, comme le titre sting, 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 s'occupe de la base de données pour vous afin que vous n'ayez pas à interagir avec la base de données.

A dessiné: 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 parlez. Ensuite, là-dedans, vous exposez vos différents modèles de mvc pour utiliser ce langage. Alors, 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? Est-ce que c'est ce qui se passe?

Anthony: 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 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 travailler avec différentes bases de données. Il peut basculer entre SQLite pour le développement et Postgres pour la production, ce genre de chose. Il s'agit principalement de relations relationnelles pour le moment, mais la feuille de route contient des éléments comme Mongo et Fauna.

A dessiné: C'est donc très utile si vous pouvez configurer et utiliser SQLite dans votre environnement de développement local au fur et à mesure que vous mettez les choses en marche, puis passez à la production avec quelque chose comme MySQL.

Anthony: C’est exactement ainsi que le didacticiel est mis en place, c’est le flux de travail qu’il vous montre.

A dessiné: 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'adore pour sa stabilité et j'adore 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 magasin de données, il est donc très intéressant de voir Redwood par défaut prendre en charge ces bonnes et anciennes bases de données relationnelles.

Anthony: Oui, non, c’est un très bon point, car je dis que pour toutes les nouvelles choses que Redwood combine, il y a des choses qui disent 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 avec un back-end relationnel. Active Record était la couche O / RM que Prisma entendait rapprocher.

A dessiné: Je suppose que nous parlons ici d'une architecture sans serveur avec Redwood, et nous avons parlé à Chris Coyier, je pense, il y a deux ou trois épisodes, tous sur l'utilisation sans serveur d'API, la fonction cloud et autres. 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 demande d'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 code de serveur Redwood qui s'exécute, ou est-ce simplement 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, puis vous avez ce que l'on appelle vos services, qui sont comme vos méthodes pour parler à votre back-end . Ensuite, tout cela est assemblé dans un gestionnaire GraphQL qui est déployé sur une seule fonction Lambda. Il est donc optimisé spécifiquement pour Lambda. En fait, nous avons récemment demandé à quelqu'un de le faire avec le framework sans serveur, et certaines personnes travaillent sur Azure et Google Cloud. Ce n’est pas la fonction Google Cloud, c’est celle qui s’ajoute à 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 tout ce qui se passe de façon magique dans le code que je ne comprends pas, mais c’est l’explication de haut niveau.

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

Anthony: Oui, donc tout est fait via Netlify si vous suivez le tutoriel. Vous n’avez pas vraiment à vous soucier des fonctions sans serveur. Les éléments qui connectent votre back-end pour le pousser dans AWS Lambda, tout cela est géré, vous n'avez pas à toucher à aucun de ce code. Tout cela est généré dès le départ en fonction de vos conventions sur vos configurations afin que vous n'ayez pas vraiment à réfléchir à la façon de le rendre sans serveur. Il est sans serveur par défaut. C’est vraiment une chose difficile à comprendre. Il m'a fallu un certain temps pour m'envelopper la tête.

A dessiné: Oui, parce que c’est un point important, ce n’est pas parce qu’il y a maintenant plusieurs domaines différents que nous suivons ici. 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. Donc, 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 de 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 pour quiconque, mais ils avaient toujours une bonne technologie stable et testée au combat. À la fin, ce que vous sortez de la boîte en suivant simplement les instructions est vraiment incroyable.

A dessiné: Les passionnés de Jamstack seront familiarisés avec des services tels que FaunaDB que vous avez mentionné et qui fournit un magasin de données en tant qu'API, AWS a DynamoDB, Google a Cloud SQL, et ainsi de suite. Donc, vous avez mentionné que Redwood envisage d’intégrer, ou je suppose que Prisma est le composant ici qui cherche à s’intégrer avec ces types de services plus tard?

Anthony: Ouais, c'est une bonne question. C'est quelque chose dont je parle en fait avec Ryan Chenkie chez Prisma pour aider, est-ce que quel 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 en sorte que Redwood fonctionne directement avec lui comme je l'ai fait avec Fauna ou serait-il plus logique d'implémenter un pilote pour Prisma? Il existe donc différentes manières de l'aborder. Il y a manifestement un million de bases de données différentes que tout le monde souhaite utiliser maintenant, c'est pourquoi vous êtes motivé pour y installer votre stockage de données. Il y a beaucoup de contributions de la communauté là-dedans.

A dessiné: Donc, parce que Prisma comprend votre modèle et sait comment les interroger, est-il capable de générer une sorte de migration 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 vraiment 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 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 faites correctement et que vous voulez vous assurer que cela est fait correctement.

A dessiné: Il semble qu'avoir un très bon outil autour des frameworks soit une tendance assez moderne, n'est-ce pas? 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 d'autres choses pour vous permettre de démarrer rapidement?

Anthony: C'est probablement la plus grande caractéristique clé que vous obtenez de Redwood, c'est que vous obtenez un ensemble complet 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 avec Rails, et les gens se disent: "Whoa, c'est incroyable." C’est l’effet de 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, explique simplement tout le code que l'échafaudage vous donne. Cela vous donne tellement de code. Il y a un générateur hors tension, il y a même un générateur Tailwind qui configure votre vent arrière pour vous.

A dessiné: C’est incroyable. Je me souviens avoir vu la démo de DHH de Rails. 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 qu'il 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, et cetera . 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 testez les données ou vous pouvez même les remettre à une équipe de contenu qui pourrait commencer à travailler pendant que vous travaillez sur le front-end, ce qui est vraiment utile.

A dessiné: Si vous vouliez simplement déployer cela et l'avoir en production, vous pouvez probablement simplement 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 existe plusieurs options d’authentification. Vous pouvez utiliser l'identité Netlify. C’est la valeur par défaut si vous suivez le didacticiel, puis vous pouvez également utiliser Auth0, puis celle que je ne connais pas, appelée Magic.Link, et il y en aura probablement quelques autres à l’avenir. Mais oui, donc il y a déjà quelques solutions intégrées là-bas, et c'est la toute dernière chose que vous faites pour que la toute dernière partie de ma série de blogs en 12 parties soit celle d'Auth. Je ne pense pas avoir jamais compris Auth avant d’utiliser Redwood. C’est difficile et ils ont vraiment fait du bon travail avec.

A dessiné: Est-ce que cela s'intègre au niveau de l'itinéraire, ou au niveau de l'itinéraire, 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 pour que vous n'ayez pas à créer un formulaire et à 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 dernières semaines par 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, c'est déjà … ça marche, ça ' vous rendra fonctionnel.

A dessiné: Les gens disent toujours à propos de la cryptographie de hachage des algorithmes 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; cette 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 depuis une entreprise. Toutes ces choses sont un tel casse-tête si vous essayez de l'implémenter vous-même et tant d'opportunités de se 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. Donc, le simple fait de pouvoir insérer 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é.

A dessiné: Il semble que le déploiement à la fois des aspects front-end et serveur, les fonctions sans serveur, soit 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 promoteurs 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 vraiment conscient. Il a investi dans de nombreuses entreprises qui flottent. Il a investi dans Prisma et Fauna. Il veut simplement fabriquer les outils qu'il veut utiliser. Il ne s’agit pas de vouloir vous enfermer dans cette chose, mais ce que Netlify a construit, selon lui, est 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 avons du travail 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 assurons 90% du chemin et il vous suffit ensuite de câbler les deux dernières choses pour que cela fonctionne avec les serveurs de votre choix.

A dessiné: Je suppose que même Netlify utilise AWS Lambda pour les fonctions des serveurs, donc c'est vraiment la partie de déploiement qui est prise en charge par Redwood là-bas, et en fait vous pouvez déployer cela vous-même sur Lambda. Publier votre front-end 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 fondamentale derrière Redwood, à savoir 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 éléments et vous n’avez pas à y penser du tout. Il parle de cette idée depuis des années, des années et des années, et c'est ce dont Jekyll parlait même à 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 personnes qui travaillent sur le front-end. Ils ne pensent même plus à déployer, ce n’est même pas une pensée.

A dessiné: 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 n'importe quel service pour le prendre et le construire et l'héberger il.

Anthony: Oui, et une chose que je dois é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 l'avons maintenant pour Vercel. Donc, il existe également de très bonnes options non-Netlify, si vous êtes plus intéressé par cela.

A dessiné: 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-ce mature?

Anthony: Ouais, nous avons environ une demi-douzaine d’applications actuellement en production. Le premier s'appelait Predict COVID, 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 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 optez pour un excellent repo Redwood, vous pouvez voir une liste de tous. Si vous allez sur les forums de la communauté, vous pouvez également en trouver des articles, car les gens les ont mis en production et ont en quelque sorte dit comment cela s'est passé. Jusqu'à présent, ils ont tous réussi et personne n'a dit: «Je ne m'en servirai plus jamais.»

A dessiné: Mais, c'est très nouveau. I guess there’s no escaping that, but in terms of maturity, Redwood’s pretty new, it’s getting a good following.

Anthony: Well, it’s funny, it is and it isn’t. It was announced in March. At that point, it had been worked on for about a year by Tom and 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. For example. 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. Do you have any parting words?

Anthony: Just if you’re interested in any of this stuff, feel free to reach out. My DMs are always open. The community is very open in general. I’ll be happy to explain or walkthrough or get you set up with anything you need to know to get going.

Éditorial fracassant(il)

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *