Smashing Podcast Episodio 25 Con Anthony Campolo: Cos'è RedwoodJS?

Stiamo parlando di RedwoodJS. Cosa significa esattamente essere un framework Jamstack full-stack? Ho parlato con il campione della comunità Anthony Campolo per scoprirlo.

Mostra note

• Redwood JS
• Antonio su Twitter
• La serie di articoli di Anthony A First Look at RedwoodJS

Aggiornamento settimanale

• "Un'introduzione all'esecuzione del faro in modo programmatico"
  scritto da Katy Bowman
• "Animazione dei componenti di reazione con GreenSock"
  scritto da Benedizione Krofegha
• "Progettare per l'attenzione"
  scritto da Victor Yocco
• "Utilizzo avanzato di GraphQL nei siti Web Gatsby"
  scritto da Aleem Isiaka
• "Confronto dei metodi di stile in Next.js"
  scritto da Adebiyi Adedotun

Trascrizione

Drew McLellan: È uno studente della Lambda School, studia sviluppo web full stack, oltre ad essere un collaboratore di RedwoodJS. Qualcosa di un campione della comunità, ha recentemente scritto una serie di articoli in 12 parti intitolata A First Look at RedwoodJS che aiuta a spiegare le origini e le motivazioni di Redwood, insieme a molti dei diversi concetti introdotti dal framework. Quindi, sappiamo che è un esperto di RedwoodJS, ma lo sapevi che non ha mai visto un cane? Miei formidabili amici, vi prego di dare il benvenuto ad Anthony Campolo.

Drew: Ciao, Antonio. Come stai?

Antonio Campolo: Ciao. Sto distruggendo, grazie mille per avermi.

Drew: Volevo parlarti oggi, e probabilmente è ovvio dall'introduzione, di RedwoodJS. Per coloro che non hanno mai sentito parlare di RedwoodJS, ad alto livello, che cos'è?

Anthony: Penso che ci siano un paio di modi in cui puoi descriverlo a seconda della provenienza delle persone, ma la definizione canonica è che è un framework serverless full stack per Jamstack. Quindi, combina lo sviluppo Web dello stack completo con elementi di tipo AWS Lambda serverless e Jamstack, che è una cosa importante al giorno d'oggi.

Drew: Quindi, è un framework di stack completo che cerca di mettere insieme molte idee attorno a un ecosistema di sviluppo Jamstack? È giusto?

Anthony: Sì, sta spingendo i confini di ciò che può essere un'applicazione Jamstack, quindi chiamandola full stack, Jamstack, si tratta di come possiamo andare oltre il semplice front-end per avere lo stesso tipo di paradigma di distribuzione di essere semplicemente spinto, ottenere l'intero codice distribuito. Come lo otteniamo, ma anche con il nostro back-end e abbiamo tutto collegato?

Drew: Ora, prima di approfondire la questione, penso che sia piuttosto interessante sentire che proviene da una squadra piuttosto esperta, vero? Le persone dietro Redwood, non sono polli primaverili. Per non dire che sono vecchi, ma sono stati intorno all'isolato, non è vero, in termini di sviluppo web?

Anthony: Sono stagionati. Sì, in realtà ho dedicato una discreta quantità di tempo per scrivere sulla storia del framework e sulle idee che lo hanno portato, e Tom Preston-Werner è il creatore, quindi è anche conosciuto come il creatore di Jekyll, che è un generatore di siti statici davvero influente. Ha anche fatto TOML, il linguaggio dei file di configurazione. E in origine era il CEO di GitHub. Quindi, il suo lavoro con le pagine di Jekyll e GitHub e quel genere di cose penso abbia davvero portato a quello che ora chiamiamo Jamstack. Molte persone direbbero: “Oh, il Jamstack è nuovo. Lo fanno da sempre". È così che abbiamo parlato di come sia un'estensione di queste idee precedenti, le generazioni di siti statici, ma con GraphQL e serverless e queste idee su come utilizzare codice adesivo e API per far funzionare la tua app.

Drew: Quindi, questo è sicuramente da parte di persone che sono molto radicate in quella comunità? Voglio dire, il CEO di GitHub, non sei davvero più radicato nel tipo di comunità open source di così. Quindi, Redwood è un framework completo di stack e immagino che ciò significhi che il codice Redwood è in esecuzione nel front-end e nel back-end. È giusto?

Anthony: Sì, questa è la prima cosa che mi piace spiegare alle persone quando mostro loro un progetto Redwood, è che è un monorepo. Quindi, hai il tuo front-end e il tuo back-end nello stesso repository, e quindi ognuno di questi vive nelle proprie cartelle. Hai una cartella web, che è il tuo front-end, ed è abbastanza simile a quella che otterresti da un'app Create React. Quindi, hai la cartella API, che è il tuo back-end, ed è qui che tutte le tue funzioni vengono essenzialmente inserite in un grande gestore GraphQL che viene distribuito in AWS Lambda tramite Netlify.

Drew: Ok, quindi partendo dalla parte anteriore, come hai detto, è basato su React. È React più un mucchio di codice Redwood, o è semplicemente React? Qual è il saldo lì?

Anthony: Sono molte cose. È sicuramente solo Reagire nel senso che non stai introducendo molte librerie di gestione dello stato, in realtà non stai nemmeno introducendo un router. Hanno il loro router che hanno scritto e usano molte cose GraphQL. Quindi, quando le persone parlano di React, GraphQL e amici, questo è un po' quello che sta succedendo qui, è che ti offre molte integrazioni predefinite per far parlare React al tuo GraphQL. Perché ora abbiamo molte convenzioni su come usare React, ma il recupero dei dati è ancora una seccatura enorme.

Drew: Quindi, è React configurato con un sacco di altri strumenti che funzionano bene con React per darti un ecosistema funzionante per svolgere questo particolare stile di attività. È una descrizione corretta?

Anthony: Sì, no, sì, è un ottimo modo per dirlo. Il modo in cui Tom ha messo le cose è che ci sono tutte queste migliori soluzioni di razza che esistono e strumenti e tecnologie davvero sofisticati che possiamo usare, ma è davvero difficile sfruttarli effettivamente perché hai un costo di avvio così enorme e devi impararli , dovendo capire come integrarli. Quindi, hanno messo lo slogan come "Facciamo la configurazione del tuo pacchetto web per te".

Drew: Penso che sia un punto dolente comune che senti da molte persone quando stanno cercando di iniziare nel moderno framework di sviluppo con app JavaScript lato client e configurando web pack, configurando tutte le diverse cose, i processi di compilazione, il costruire passaggi. Può essere un bel campo minato, non è vero, mettere tutto in ordine e funzionare? E c'è molta strada da fare prima di arrivare a "Hello, World!". Quindi, Redwood ci sta dando tutto ciò che è preconfigurato?

Anthony: Sì, è più che altro una convenzione sull'idea del tipo di configurazione, perché tu... Tom era, come se avesse creato GitHub con Ruby on Rails e Rob, uno degli altri contributori principali, è uno sviluppatore Rails da sempre. Hanno molte idee con cui si allineano filosoficamente in termini di Rails, ma vogliono prendere quelle convenzioni sulle idee di configurazione, le idee di framework full stack e implementarle con tutta la tecnologia moderna che abbiamo ora.

Drew: Quindi, hai detto che Redwood ti offre un router o un router, come diciamo da questa parte dello stagno, viene fornito con cose come componenti predefiniti e cose del genere in React, o sei proprio in quel momento per implementare tutto ciò da soli?

Anthony: Sì, il router è molto sofisticato. Fa la maggior parte delle cose che otterresti solo dal router React, ha solo idee diverse in termini di come dovrebbero essere implementate, perché Next hanno anche il loro router e non è ancora del tutto capito come vuoi far funzionare il nostro instradamento dell'app a pagina singola. A causa di Suspense, hai un sacco di questo tipo di domande su dove entreranno le cose asincrone? Abbiamo con Redwood, questa idea di una cella, e questo è ciò che i tuoi dati recuperano davvero per te.

Drew: Quindi, forse potremmo approfondire un po' questo? Cos'è una cella in termini di Redwood?

Anthony: Sì, quindi una cella è un modo predefinito per scrivere una query GraphQL e quindi fare in modo che la tua pagina in pratica dica se stai recuperando i dati, se stai ricevendo un errore, se sei in uno stato di caricamento, o se... C'è un altro stato, dimentico. Ma sì, quindi ti dà i diversi stati in cui sostanzialmente puoi trovarti in base al fatto che stai ricevendo i tuoi dati o meno. È sistemato con Apollo sotto le coperte. Quindi, se stai usando Redwood, stai usando Apollo come client GraphQL, ma non devi mai pensarci. Non devi mai scrivere Apollo o nemmeno pensarci, è tutto integrato. Ti consente solo di scrivere query GraphQL, che era davvero il sogno del motivo per cui le persone volevano GraphQL, è che era questo linguaggio di query davvero semplice che gli sviluppatori front-end potrei usare. Ma poi, dovevi capire come configurare un server GraphQL, dovevi capire tutte queste altre cose e come collegarle. Quindi, esegue tutta l'integrazione di GraphQL per te, quindi puoi semplicemente scrivere GraphQL, non devi pensare a come implementare GraphQL.

Drew: Quindi, suppongo che uno dei compiti classici di un framework sia quello di prendere tutto il codice della piastra della caldaia che potresti scrivere tu stesso e implementarlo per te, e riordinare il modo dietro le quinte in modo da non dover mai guardare quella piastra della caldaia mai più, e puoi semplicemente scrivere il codice unico per la tua circostanza. Immagino che sia quello che sta succedendo con una cella, vero? Non c'è niente di rivoluzionario qui, è qualcosa che potresti impostare un componente React per avere tutti questi diversi stati e potresti agganciarti ad Apollo e potresti fare tutto da solo, ma in realtà è un bel po' di lavoro ed è uno schema comune. Quindi, Redwood si è riordinato in uno schema piacevole e riutilizzabile che puoi semplicemente iniziare a utilizzare senza doverci pensare. È una buona descrizione?

Anthony: Sì, hanno inventato il nome, ma hanno sicuramente riconosciuto che questa era una pratica che vedevano frequentemente e che hanno visto molte persone che lo codificavano da soli, e hanno deciso che volevano un modo dichiarativo per recuperare i tuoi dati. Quindi, ecco perché hai questa configurazione, perché ti consente solo di avere i tuoi diversi stati e non devi fare se/quindi logica per capire, devi farlo se ciò accade. Quindi, si tratta solo di avere un unico modo per dichiarare tutti i diversi stati in cui potrebbero trovarsi i tuoi dati mentre li stai caricando.

Drew: È una delle caratteristiche di React, vero, che React non cerca di darti un'architettura per il tuo progetto, ti permette di decidere come strutturare le cose. Questo, ovviamente, ha pro e contro. Ma sembra che Redwood ti stia imponendo parte di quella struttura in modo che tu non debba pensarci e in modo che possa mettere l'impianto idraulico per te e in qualche modo riprendere da dove React si era interrotto in termini di darti quel tipo di struttura.

Anthony: Sì, e penso che sia davvero interessante che abbiamo visto diversi tentativi di questa soluzione a questo problema, perché voglio dire che hai avuto persone che lo dicono da sempre, "Perché non c'è un Rails per JavaScript o Rails for React?" C'è una fantastica intervista a Full Stack Radio tra Michael Chan e Adam Wathan intitolata React is Not a Rails competitor. Questo è uno dei diversi framework.

Anthony: Gli altri sono BlitzJS che ha ottenuto una discreta quantità di entusiasmo, e poi Bison è una specie di nuovo emergente. Hanno tutti una pila simile, ma usano pezzi diversi. Avrai React query invece di Apollo, o avrai Chakra invece di Tailwind. Le persone che stanno mettendo insieme tutti questi pezzi nei loro stack, tutti questi stack sono una specie di, stanno combattendo, è tutta una competizione molto amichevole. In realtà, questa è una cosa che apprezzo molto, è che in realtà tutti collaboriamo anche tra i framework. Non c'è animosità lì.

Drew: Quindi, abbiamo menzionato Apollo e GraphQL, Redwood usa GraphQL abbastanza pesantemente come uno dei pezzi fondamentali, non è vero, del framework? Probabilmente possiamo dedicare un intero episodio del podcast solo a GraphQL, ma per coloro che non hanno familiarità, quale pezzo sta facendo GraphQL qui, quale problema sta risolvendo in questo contesto?

Anthony: Sì, questa è un'ottima domanda. Quando dico alle persone cosa dovrebbero sapere per iniziare bene con Redwood, direi che avresti dovuto usare l'app Create React, solo se hai creato un'app Create React e l'hai distribuita su Netlify o Vercel, questo ti farà iniziare bene. Quindi, conosci almeno un po' di GraphQL perché è molto centrale. Quindi, GraphQL è il modo in cui il tuo front-end parlerà con il tuo back-end. Dicono che sia un linguaggio di query per le API, l'idea è che è pensato per essere un'alternativa ai metodi API RESTful e che invece di fare quella cosa RESTful, stai inviando query che specificano esattamente la struttura di dati gerarchica da cui vuoi ricevere indietro la banca dati. Quindi, richiede un po' più di tempo di avvio per far parlare il tuo server GraphQL con i due pezzi. Quindi, una volta che lo hai lì, gli sviluppatori front-end hanno la possibilità di ottenere i dati in un modo molto più flessibile. Non hai bisogno di tutti questi diversi endpoint API che i tuoi ragazzi back-end devono continuare a creare.

Drew: Quindi, se ci sono cambiamenti nei requisiti nel front-end, presumibilmente puoi semplicemente modificare la tua query GraphQL e non hai bisogno dell'aiuto di qualcuno che lavora sul back-end per apportare quel cambiamento per te?

Anthony: Voglio dire, il vero sogno è che puoi inserire un client mobile su di esso, che alla fine sarebbe così flessibile da diventare, puoi avere più client che parlano tutti con la tua unica API. La tua API GraphQL diventa la tua fonte di verità, è lì che tutta la tua logica è centralizzata. Quindi, puoi costruire tutti questi diversi livelli di visualizzazione in cima.

Drew: Quindi, abbiamo GraphQL che ci dà la possibilità di interrogare una sorta di back-end. In Redwood, qual è il back-end?

Antonio: Sì. Ci sono un paio di modi diversi per creare il tuo back-end. C'è il modo in cui uscirai dagli schemi con il tutorial, ovvero usi il database Postgres distribuito su Heroku, super facile, super semplice. Quindi, la tua app Redwood parla con Prisma. Non so se hai familiarità con Prisma, ma è come un O/RM. Dicono specificamente che non è un O/RM, è un generatore di query, che è un livello leggermente più basso. Ma, solo per spiegarlo alle persone, Prisma è la cosa che ti consente di parlare con il tuo database. Fa le tue migrazioni e imposta le tue tabelle. Fa tutte le cose SQL quindi non devi scrivere SQL. Per me suona come un O/RM. Non devi necessariamente usare Prisma per usare Redwood.

Anthony: In realtà ho creato un'app proof of concept in cui invece abbiamo usato FaunaDB. FaunaDB, hanno la loro API GraphQL, quindi puoi semplicemente inviare l'API GraphQL direttamente a Fauna e quindi eseguire le mutazioni del tuo database in questo modo. Perdi molte delle funzionalità della CLI di Prisma, ma Prisma è davvero un fattore di comodità per lavorare molto facilmente con il tuo database relazionale. Ma in realtà, qualsiasi cosa tu possa pensare, potresti capire come collegarlo a Redwood è quello che ho scoperto solo perché è costruito attorno a GraphQL e il punto è essere in grado di parlare con tutti questi diversi pezzi.

Drew: Quindi, Prisma è essenzialmente una sorta di livello di astrazione tra il tuo codice e qualsiasi archivio di dati che stai utilizzando presumibilmente supportato da Prisma, è quello... o sta facendo cose più intelligenti di così?

Anthony: Sì, quindi scrivi uno schema, quindi crei un file schema.Prisma, e avrebbe un post del modello, quindi avrebbe id e intero e incremento automatico, come il pungiglione del titolo, la stringa del corpo, creato alla data, all'ora . Quindi, creeresti fondamentalmente quello che vuoi essere nel tuo database con i tipi, e quindi fa le cose del database per te in modo da non dover interagire con il database.

Drew: Quindi, usi Prisma per definire, immagino, quale tipo di database o quale tipo di archivio dati con cui stai parlando. Quindi, lì disponi i tuoi diversi modelli mvc per usare quel gergo. Quindi, quando la tua applicazione comunica con gli archivi dati, sta usando un'istanza di un client Prisma, vero? È quello che sta succedendo?

Antonio: Sì. Sì, è proprio così. Quindi, nella cartella API del tuo back-end, hai una cartella lib con db.js e solo per impostazione predefinita che ha il tuo client Prisma impostato. Quindi, questa è tutta la roba che ottieni fuori dagli schemi e, come hai detto, Prisma può funzionare con database diversi. Può passare da SQLite per lo sviluppo a Postgres per la produzione, quel genere di cose. Al momento sono per lo più relazionali, ma la tabella di marcia contiene cose come Mongo e Fauna.

Drew: Quindi, è abbastanza utile se puoi configurare e utilizzare SQLite nel tuo ambiente di sviluppo locale mentre stai mettendo in funzione le cose, e poi vai in produzione con qualcosa come MySQL.

Anthony: Questo è esattamente come è impostato il tutorial, questo è il flusso di lavoro che ti mostra.

Drew: È piuttosto interessante, non è vero, vedere un approccio molto moderno a un framework e poi ricorrere ad alcuni di questi database più tradizionali come MySQL. Conosco molto MySQL. Lo adoro per la sua stabilità e adoro il modo relazionale di archiviare i dati. Penso che funzioni così bene per così tante cose. Spesso si vede il bambino buttato fuori che era l'acqua del bagno quando si tratta di nuovi tipi di archivi di dati, quindi è piuttosto interessante vedere Redwood che supporta di default questi vecchi database relazionali.

Anthony: Sì, no, questo è un buon punto, perché dico che per tutte le cose nuove che Redwood combina insieme, ci sono alcune cose che in realtà dicono che il vecchio, provato e vero modo è in realtà il migliore. Quindi, sono davvero grandi sui database relazionali. Ciò deriva dall'esperienza di Tom nell'uso di Rails e nell'avere un back-end relazionale. Active Record era il livello O/RM che Prisma intendeva approssimare.

Drew: Immagino, stiamo parlando di un'architettura serverless qui con Redwood, e abbiamo parlato con Chris Coyier penso a due o tre episodi indietro, tutti sull'utilizzo senza server di API e funzioni cloud e cose del genere. Quindi, facendo un passo indietro, se dovessi pensare in termini di un framework basato su server, come abbiamo menzionato Ruby on Rails o qualcosa come Laravel nel mondo PHP. Anche con un front-end React, la tua richiesta API dovrebbe eseguire codice che è il codice Rails o il codice Laravel più il tuo codice utente e configurazione. È lo stesso con Redwood? Esiste un codice server Redwood effettivo che viene eseguito o sono solo più strumenti, struttura e colla che ti consentono di implementare il tuo?

Anthony: Sì, quindi nel back-end c'è un file specifico che è un modo per prendere il tuo SDL, quindi hai il tuo linguaggio di definizione dello schema e poi hai quelli che sono chiamati i tuoi servizi, che sono come i tuoi metodi per parlare con il tuo parte posteriore. Quindi, tutto questo viene unito in un gestore GraphQL che viene distribuito a una singola funzione Lambda. Quindi, è ottimizzato specificamente per Lambda. In realtà, di recente, qualcuno lo ha fatto con il framework serverless e alcune persone stanno lavorando su Azure e Google Cloud qualcosa. Non è la funzione Google Cloud, è quella costruita su di essa. Ma sì, quindi in questo momento è sostanzialmente ottimizzato per la distribuzione del back-end come funzione GraphQL in un AWS Lambda. Questa è la roba che sta accadendo tutta la magia nel codice che non capisco, ma questa è la spiegazione di alto livello.

Drew: Quindi, ci sono strumenti di distribuzione che prendono tutto il codice che hai scritto, lo schiacciano tutto insieme in una sorta di palla magica di codice che può essere eseguita nel cloud e lo inserisce su AWS o tu devi ancora gestire quel processo da solo?

Anthony: Sì, quindi è tutto fatto tramite Netlify se segui il tutorial. Non devi davvero pasticciare con nessun tipo di funzione serverless da solo. Le cose che collegano il tuo back-end insieme per inserirlo in AWS Lambda, è tutto gestito, non devi toccare nessuno di quel codice. Questo è tutto generato fuori dagli schemi come le tue convenzioni sulle tue configurazioni, quindi non devi davvero pensare troppo a come renderlo serverless. È serverless per impostazione predefinita. È davvero una cosa difficile da girare la testa. Mi ci è voluto un po' per avvolgerci la testa.

Drew: Sì, perché è un punto importante non perché ora ci sono alcune aree diverse di cui teniamo traccia qui. Abbiamo, credo, tre aree diverse. Abbiamo la nostra app React front-end, che è in esecuzione nel browser, e poi abbiamo un'API basata su GraphQL, in esecuzione come funzione cloud, che risponde alle nostre domande, ma interagisce con un archivio dati che usa Prisma. E quell'archivio dati è cosa e dove in questo, perché non puoi eseguire un server MySQL su Netlify, vero?

Anthony: Sì, è qui che entra in gioco Heroku. Quindi, nell'ultima parte del tutorial, distribuisci il tuo front-end su Netlify e poi distribuisci il tuo back-end su Heroku Postgres e prendi le tue variabili di configurazione da Heroku, collegalo in Netlify. Fare in modo che il tuo front-end Netlify parli con il tuo back-end Postgres è una cosa davvero, davvero semplice. Volevano andare con la cosa che sarebbe stata la cosa più facile da far girare per chiunque, ma hanno comunque una buona tecnologia stabile e testata in battaglia. Alla fine, quello che si ottiene solo seguendo le istruzioni, è davvero incredibile.

Drew: Gli appassionati di Jamstack avranno familiarità con servizi come FaunaDB che hai menzionato che fornisce un archivio dati come API, AWS ha DynamoDB, Google ha Cloud SQL e così via. Quindi, hai detto che Redwood sta cercando di integrarsi, o immagino che Prisma sia il componente qui che sta cercando di integrarsi con quel tipo di servizi più avanti?

Anthony: Sì, questa è una buona domanda. Questo è qualcosa con cui sto effettivamente parlando con Ryan Chenkie a Prisma su come dare una mano, qual è il tipo di storia del database per Redwood per cose che non funzionano necessariamente con Prisma? Sarebbe meglio trovare un modo per convincere Redwood a lavorarci direttamente come ho fatto con Fauna o avrebbe più senso implementare un driver per Prisma? Quindi, ci sono diversi modi per affrontarlo. C'è ovviamente un milione di database diversi ora che tutti vogliono utilizzare, quindi è quanto sei motivato a inserire il tuo archivio dati su di esso. Ci sono molti contributi della comunità che vanno lì.

Drew: Quindi, poiché Prisma comprende il tuo modello e sa come interrogarli, è in grado di generare qualche tipo di migrazione o cose del genere per aiutarti a configurare quel database?

Anthony: Questa è esattamente la cosa che perdi quando devi eliminare Prisma e recuperare i tuoi dati, è che perdi tutte le funzioni di migrazione. Ha una CLI davvero avanzata che fa un sacco di cose per te, quindi puoi seguire l'intero tutorial di Redwood e inserire i comandi Prisma e non devi avere idea di cosa stia facendo, funziona e basta. È davvero un ottimo strumento per fare tutto quel tipo di roba tipo database che vuoi assicurarti di fare bene e vuoi assicurarti che sia fatto correttamente.

Drew: Sembra che avere un ottimo strumento per i framework sia una tendenza piuttosto moderna, vero? Non solo per dire: "Ecco tutte le cose che questo framework può fare, ma ecco forse alcuni strumenti CLI che faranno un sacco di cose per te". Redwood ha strumenti per cose come generatori CLI e cose per farti funzionare rapidamente?

Anthony: Questa è probabilmente la più grande caratteristica chiave che ottieni da Redwood, è che ottieni un intero set di generatori molto sofisticati. Per chiunque abbia mai visto la demo originale di Ruby on Rails, che DHH ha dato, crea un blog in circa 15 minuti e fa tutto con Rails, e la gente dice: "Whoa, è fantastico". Questo è l'effetto con cui Redwood sta andando. Vogliono che tu sia in grado di far funzionare tutto molto rapidamente in modo da poter generare pagine, creare layout, generare le tue celle, di cui stavo parlando, e puoi eseguire un comando scaffold che creerà il tuo intero Interfaccia CRUD. Ho un'intera sezione, la quarta parte della serie di blog, spiega solo tutto il codice che ti dà lo scaffold. Ti dà così tanto codice. C'è un generatore spento, c'è anche un generatore Tailwind che configura il tuo vento in coda per te.

Drew: È incredibile. Ricordo di aver visto la demo di Rails di DHH. Voglio dire, è stato probabilmente, cosa, 15 anni fa, quando ha fatto quel ponteggio per la prima volta e te lo ha mostrato, e ottieni un pannello di controllo abbastanza rudimentale ma funzionale essenzialmente per consentirti di creare nuovi elementi, modificarli, eliminarli, eccetera . Questo può essere prezioso in un progetto, specialmente lavorando in una sorta di ambiente dinamico in cui, ok, forse in futuro implementerai strumenti migliori per modificare quel contenuto, ma significa essere in grado di creare rapidamente qualcosa, puoi ottenere testare i dati in, oppure puoi anche consegnarli a un team di contenuti che potrebbe iniziare a lavorare mentre lavori sul front-end, quindi è davvero utile.

Drew: Se vuoi semplicemente distribuirlo e averlo in produzione, presumibilmente puoi semplicemente distribuirlo insieme al tuo codice front-end, ma avresti bisogno di un modo per proteggere quell'aspetto, quelle radici nella tua applicazione.

Anthony: Sì, ci sono un paio di opzioni diverse per l'autenticazione. Puoi usare l'identità Netlify. Questa è l'impostazione predefinita se vai nel tutorial, quindi puoi anche usare Auth0, quindi uno con cui non ho familiarità chiamato Magic.Link, e probabilmente ne verranno aggiunti un paio in futuro. Ma sì, quindi ci sono già un paio di soluzioni integrate lì, e questa è l'ultima cosa che fai, quindi l'ultima parte della mia intera serie di blog in 12 parti è quella Auth. Non credo di aver mai scoperto Auth prima di usare Redwood. È difficile e hanno sicuramente fatto un buon lavoro con esso.

Drew: Si integra a livello di percorso o livello di percorso, scusa, come proteggi le cose?

Anthony: Sì, quindi parte del modo in cui hanno il proprio router, hanno anche... Puoi fare percorsi privati, quindi hanno un componente di percorso privato. Quindi, il tuo modulo di accesso effettivo, questo è ciò che ottieni dall'identità di Netlify, quindi non devi effettivamente creare un modulo e fare la gestione dello stato con quello, è qui che entrano in gioco molti problemi. Togliendo le parti veramente chiave e quindi puoi semplicemente implementare l'accesso basato sui ruoli. Abbiamo aggiunto il controllo degli accessi basato sui ruoli che è stato fatto nelle ultime due settimane, come David T. Quindi, c'è molto lavoro da fare per creare altri modi per farlo, ma quello che hanno ora è già... funziona, è' ti metterò in funzione.

Drew: La gente dice sempre della crittografia di hashing degli algoritmi di sicurezza, che non dovresti mai scrivere la tua perché non sarà mai buona come le cose che sono là fuori. Sempre più spesso, penso che questo sia vero anche per l'autenticazione a un livello superiore; che l'autenticazione è un'area così complessa al giorno d'oggi che le persone non vogliono solo accedere al tuo sito con credenziali univoche, ma potrebbero voler autenticarsi utilizzando Google, oppure potrebbero voler autenticarsi utilizzando un dispositivo Apple o potrebbero volere l'autenticazione a due fattori oppure potrebbero volerlo integrare con un servizio di accesso singolo che stanno utilizzando da un'azienda. Tutte queste cose sono un tale mal di testa se provi a implementarlo da solo e così tante opportunità per sbagliare qualcosa ed esporre falle di sicurezza nella tua applicazione, che l'utilizzo di un servizio di autenticazione sembra quasi un gioco da ragazzi a questo punto per me. Quindi, solo essere in grado di inserire qualcosa essenzialmente con poche righe di codice ed essere attivo e funzionante suona come un modo davvero produttivo di lavorare e mantenere le cose al sicuro.

Drew: Sembra che la distribuzione di entrambi gli aspetti front-end e server, le cose della funzione serverless, sia naturalmente adatta per la distribuzione su Netlify. Sei legato a questo con Redwood? Voglio dire, abbiamo detto che Tom Preston-Werner è uno dei principali sostenitori di questo framework, è anche nel consiglio di Netlify. Pensi che ci sia il potenziale per un accoppiamento troppo stretto lì se dovessi scegliere Redwood come base per un progetto?

Anthony: Sì, questo è qualcosa di cui Tom è decisamente consapevole. Ha investito in molte società che circolano. Ha investito in Prisma e Fauna. Vuole solo creare gli strumenti che vuole usare. Non si tratta di volerti bloccare in questa cosa, ma di ciò che Netlify ha costruito secondo lui l'opzione migliore, quindi è per questo che ci hanno costruito attorno. Ma non vogliono che sia bloccato su nessun target di distribuzione, ed è per questo che stiamo lavorando su cose come il framework serverless e alcune persone hanno parlato di Begin. Vogliamo essere pragmatici, vogliamo che funzioni per qualunque sia il caso d'uso di qualcuno. Quindi, ti otteniamo il 90% del percorso e poi devi solo collegare le ultime due cose per farlo funzionare con qualunque sia il tuo server preferito.

Drew: Immagino che anche Netlify stia utilizzando AWS Lambda per le funzioni dei server, quindi è davvero la parte di distribuzione che si occupa di Redwood lì, e in realtà potresti distribuirla tu stesso su Lambda. Pubblicare il tuo front-end è solo file, vero, è basato su CDN per il resto? Quindi, c'è molta flessibilità lì senza essere troppo vincolati.

Anthony: Sì, in realtà c'è un termine di cui Tom parla come l'idea filosofica centrale dietro Redwood, ovvero che vogliamo arrivare a una macchina di distribuzione universale. Questa è una specie di idea, è che puoi semplicemente distribuire le cose e non devi pensarci affatto. Ha parlato di questa idea per anni e anni e anni, e questo è ciò di cui Jekyll parlava anche ai tempi. Quando lo senti ora, sei tipo "Oh, intendi come Netlify?" Questo è fondamentalmente ciò che Netlify è per la maggior parte delle persone che lavorano sul front-end. Non pensano nemmeno più a schierarsi, non è nemmeno un pensiero.

Drew: ecco la mia applicazione in un Git Repo, questa directory è il front-end, questa directory è il back-end, ecco il mio database e si tratta di tutta la configurazione di cui forse avresti bisogno per qualsiasi servizio per prenderlo e costruirlo e ospitalo.

Anthony: Sì, e una cosa che dovrei anche sottolineare, di recente abbiamo configurato la distribuzione predefinita di Vercel Redwood, quindi quando esegui la distribuzione su un'app lato server puoi dire "Oh, ho l'app Gatsby" e sa esattamente come costruire un'app Gatsby rispetto a una NextApp. Lo abbiamo per Vercel ora. Quindi, ci sono anche opzioni non Netlify davvero molto buone, se ti interessa di più.

Drew: Quindi, se volevo iniziare a creare un'app e portarla in produzione questa settimana, Redwood è pronto per questo? È maturo?

Anthony: Sì, abbiamo circa una mezza dozzina di app in produzione in questo momento. Il primo si chiamava Predict COVID, uscito a marzo, ed è come un'applicazione di visualizzazione dei dati in tempo reale. Quindi, abbiamo repeater.dev è fatto da Rob, è come un cron job come una cosa per Jamstack. Poi c'è Tape.sh, Duoflag credo sia un altro. Quindi, ce n'è almeno una manciata. Se fai un fantastico repository Redwood, puoi vedere un elenco di tutti loro. Se vai sui forum della community, puoi trovare anche i commenti di questi, perché le persone li hanno messi in produzione e in qualche modo hanno detto come è andata. Finora, hanno avuto tutti successo e nessuno ha detto: "Non lo userò mai più".

Drew: Ma è molto nuovo. Immagino che non si possa sfuggire a questo, ma in termini di maturità, Redwood è piuttosto nuovo, sta ottenendo un buon seguito.

Anthony: Beh, è ​​divertente, lo è e non lo è. È stato annunciato a marzo. A quel punto, era stato lavorato per circa un anno da Tom e 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: Certo.

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. Per esempio. 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. Hai qualche parola d'addio?

Anthony: Solo se sei interessato a queste cose, sentiti libero di contattarci. I miei DM sono sempre aperti. La comunità è molto aperta in generale. Sarò felice di spiegare o fare una guida dettagliata o prepararti con tutto ciò che devi sapere per iniziare.