Smashing Podcast Episodul 25 cu Anthony Campolo: Ce este RedwoodJS?

Vorbim despre RedwoodJS. Ce înseamnă exact să fii un framework Jamstack complet? Am vorbit cu campionul comunității Anthony Campolo pentru a afla.

Afișați note

• RedwoodJS
• Anthony pe Twitter
• Seria de articole a lui Anthony O primă privire asupra RedwoodJS

Actualizare săptămânală

• „O introducere în rularea farului în mod programatic”
  scris de Katy Bowman
• „Animarea componentelor React cu GreenSock”
  scris de Blessing Krofegha
• „Proiectarea pentru atenție”
  scris de Victor Yocco
• „Utilizarea avansată a GraphQL pe site-urile Gatsby”
  scris de Aleem Isiaka
• „Compararea metodelor de stilare în Next.js”
  scris de Adebiyi Adedotun

Transcriere

Drew McLellan: Este un student la Lambda School, studiază dezvoltarea web full stack, precum și contribuie la RedwoodJS. Un fel de campion al comunității, el a scris recent o serie de articole din 12 părți numită A First Look at RedwoodJS, care ajută la explicarea originilor și motivațiilor Redwood, împreună cu multe dintre conceptele diferite pe care cadrul le introduce. Deci, știm că este un expert la RedwoodJS, dar știai că nu a văzut niciodată un câine? Prietenii mei zdrobitori, vă rog bun venit lui Anthony Campolo.

Drew: Bună, Anthony. Ce mai faci?

Anthony Campolo: Bună. Sunt zdrobitor, mulțumesc foarte mult că m-ai primit.

Drew: Am vrut să vorbesc cu tine astăzi și probabil că din introducere este evident despre RedwoodJS. Pentru cei care nu au auzit de RedwoodJS până acum, la un nivel înalt, ce este?

Anthony: Cred că există câteva moduri în care îl puteți descrie în funcție de locul de unde vin oamenii, dar definiția canonică este că este un cadru complet fără server pentru Jamstack. Deci, combină dezvoltarea web full stack cu chestii de tip AWS Lambda fără server și Jamstack, care este un lucru important în zilele noastre.

Drew: Deci, este un cadru full stack care încearcă să pună cap la cap o mulțime de idei în jurul unui ecosistem de dezvoltare Jamstack? Este corect?

Anthony: Da, depășește limitele a ceea ce poate fi o aplicație Jamstack, așa că, numind-o stiva completă, Jamstack, este vorba despre cum depășim doar front-end-ul pentru a avea același tip de paradigmă de implementare de a fi împins, a primi întregul tău cod a fost implementat. Cum obținem asta, dar și cu back-end-ul nostru și să avem totul conectat?

Drew: Acum, înainte să ne adâncim prea mult în ea, cred că este destul de interesant să aud că este de la o echipă destul de experimentată, nu-i așa? Oamenii din spatele lui Redwood, nu sunt găini de primăvară. Ca să nu spun că sunt bătrâni, dar au fost în jurul blocului, nu-i așa, în ceea ce privește dezvoltarea web?

Anthony: Sunt experimentați. Da, am investit de fapt o cantitate decentă de timp pentru a scrie despre istoria cadrului și ideile care au condus la acesta, iar Tom Preston-Werner este creatorul și, prin urmare, este cunoscut și ca creatorul lui Jekyll, care este un generator de site static cu adevărat influent. A făcut și TOML, limbajul fișierului de configurare. Și inițial a fost CEO-ul GitHub. Așadar, munca lui cu paginile Jekyll și GitHub și așa ceva cred că au dus cu adevărat la ceea ce noi considerăm acum Jamstack. Mulți oameni ar spune: „Oh, Jamstack-ul este nou. Ei au făcut asta pentru totdeauna.” Așa am vorbit despre modul în care este o extensie a acestor idei mai vechi, generațiile de site-uri statice, dar cu GraphQL și serverless și despre aceste idei despre cum să folosiți codul glue și API-urile pentru a vă face aplicația să funcționeze.

Drew: Deci, acesta este cu siguranță de la oameni care sunt foarte încorporați în acea comunitate? Adică, CEO al GitHub, chiar nu te încorporezi mai mult în genul de comunitate open source decât atât. Deci, Redwood este un cadru full stack și cred că asta înseamnă că aveți cod Redwood care rulează în front-end și în back-end. Este corect?

Anthony: Da, acesta este primul lucru pe care îmi place să le explic oamenilor când le arăt un proiect Redwood, este că este un monorepo. Deci, aveți front-end-ul și backend-ul în același depozit, iar apoi fiecare dintre aceștia trăiește în propriile foldere. Aveți un folder web, care este front-end-ul dvs. și este destul de similar cu ceea ce ați obține dintr-o aplicație Create React. Apoi, aveți folderul API, care este back-end-ul dvs. și aici este locul în care toate funcțiile dvs. sunt introduse în esență într-un singur handler GraphQL mare care este implementat în AWS Lambda prin Netlify.

Drew: Bine, deci începând din față, așa cum ați menționat, se bazează pe React. Este React plus o grămadă de cod Redwood, sau este pur și simplu React? Care este echilibrul acolo?

Anthony: Sunt o mulțime de lucruri. Cu siguranță este doar React, în sensul că nu aduci o mulțime de biblioteci de management de stat, nici măcar nu aduci un router. Au propriul lor router pe care l-au scris și folosesc o mulțime de lucruri GraphQL. Așadar, când oamenii vorbesc despre React și GraphQL și despre prieteni, asta este un pic din ceea ce se întâmplă aici, este că îți oferă o mulțime de integrări implicite pentru ca React să vorbească cu GraphQL-ul tău. Pentru că acum avem o mulțime de convenții cu privire la modul de utilizare a React, dar preluarea datelor este încă o problemă uriașă.

Drew: Deci, este React configurat cu o grămadă de alte instrumente care funcționează frumos cu React pentru a vă oferi un ecosistem funcțional pentru a face acest stil particular de sarcină. Este o descriere corectă?

Anthony: Da, nu, da, acesta este un mod grozav de a spune. Felul în care Tom a spus este că există toate aceste cele mai bune soluții care există și instrumente și tehnologii cu adevărat sofisticate pe care le putem folosi, dar este foarte greu să le folosiți pentru că aveți un cost de pornire atât de mare și trebuie să le învățați. , trebuind să-și dea seama cum să le integreze. Așadar, au pus sloganul ca „Vă facem configurarea pachetului web pentru dvs.”.

Drew: Cred că este un punct de durere comun pe care îl auziți de la mulți oameni atunci când încearcă să înceapă în cadrul modern de dezvoltare cu aplicații JavaScript pentru client și configurarea pachetului web, configurarea tuturor lucrurilor diferite, procesele de construire, construiți pași. Poate fi un câmp minat, nu-i așa, ca totul să fie legat și să funcționeze? Și mai e mult înainte să ajungi la „Bună, lume!”. Deci, Redwood ne oferă toate acestea preconfigurate?

Anthony: Da, este foarte mult o convenție asupra ideii de tip de configurare, pentru că ai... Tom a fost, așa cum a construit GitHub cu Ruby on Rails și Rob, unul dintre ceilalți contribuitori de bază, a fost un dezvoltator Rails pentru totdeauna. Au o mulțime de idei cu care se aliniază din punct de vedere filozofic în ceea ce privește Rails, dar doresc să preia acele convenții peste ideile de configurare, ideile de cadru complet stiva și să le implementeze cu toată tehnologia modernă pe care o avem acum.

Drew: Deci, ați menționat că Redwood vă oferă un router sau un router, așa cum spunem pe această parte a iazului, vine cu lucruri precum componente implicite și ceva de genul ăsta în React, sau ești chiar atunci? să implementezi singur toate astea?

Anthony: Da, routerul este, este foarte sofisticat. Face majoritatea lucrurilor pe care le-ai obține doar de la routerul React, are idei diferite în ceea ce privește modul în care acestea ar trebui implementate, pentru că Next au și propriul lor router și încă nu s-a dat seama complet cum am vrei să funcționeze rutarea aplicației pe o singură pagină. Din cauza suspansului, aveți o mulțime de astfel de întrebări cu privire la unde vor intra lucrurile asincrone? Avem cu Redwood această idee de celulă și asta este ceea ce preia datele pentru tine.

Drew: Deci, poate am putea intra puțin în asta? Ce este o celulă în termeni de Redwood?

Anthony: Da, deci o celulă este o modalitate implicită de a scrie o interogare GraphQL și apoi de a avea pagina dvs. să vă spună dacă primiți datele înapoi, dacă primiți o eroare înapoi, dacă vă aflați într-o stare de încărcare, sau dacă... Mai există o stare, am uitat. Dar da, așa că vă oferă diferitele stări în care vă puteți afla, în funcție de faptul că obțineți sau nu datele. Este instalat cu Apollo sub huse. Deci, dacă folosești Redwood, folosești Apollo ca client GraphQL, dar nu trebuie să te gândești niciodată la asta. Nu trebuie să scrieți niciodată niciun Apollo sau măcar să vă gândiți la asta, totul este încorporat. Vă permite să scrieți interogări GraphQL, ceea ce a fost într-adevăr visul de ce oamenii au vrut GraphQL, este că acest limbaj de interogare foarte simplu a fost cel care dezvoltatorii front-end. as putea folosi. Dar apoi, a trebuit să vă dați seama cum să configurați un server GraphQL, a trebuit să vă dați seama de toate celelalte lucruri și cum să le conectați. Deci, face toată integrarea GraphQL pentru dvs., astfel încât să puteți scrie GraphQL, nu trebuie să vă gândiți cum să implementez GraphQL.

Drew: Așadar, cred că una dintre sarcinile clasice ale unui cadru este să luați tot codul plăcii cazanului pe care l-ați putea scrie singur și să-l implementați pentru dvs. și să faceți ordine în spatele scenei, astfel încât să nu trebuie să vă uitați niciodată la placa de cazan. din nou și poți doar să scrii codul care este unic pentru situația ta. Cred că asta se întâmplă cu o celulă, nu? Nu este nimic revoluționar aici, este ceva în care ai putea configura o componentă React pentru a avea toate stările astea diferite și ai putea să agățați Apollo și ați putea face toate acestea singur, dar asta este de fapt destul de multă muncă și este un model comun. Așadar, Redwood s-a aranjat într-un model frumos, reutilizabil, pe care îl poți începe să-l folosești fără să te gândești la el. Este o descriere bună?

Anthony: Da, au venit cu numele, dar au recunoscut cu siguranță că aceasta a fost o practică pe care o vedeau frecvent și că au văzut mulți oameni care o codificau ei înșiși și au decis că vor o modalitate declarativă de a vă prelua datele. Deci, de aceea aveți această configurație, deoarece vă permite doar să aveți diferite stări și nu trebuie să faceți dacă/atunci logica pentru a vă da seama, trebuie să faceți acest lucru dacă se întâmplă acest lucru. Deci, este vorba doar de a avea o singură modalitate de a declara toate stările diferite în care ar putea fi datele tale pe măsură ce le încarci.

Drew: Este una dintre caracteristicile lui React, nu-i așa, că React nu încearcă să-ți ofere o arhitectură pentru proiectul tău, te lasă să decizi cum vei structura lucrurile. Asta, desigur, are argumente pro și contra. Dar, se pare că Redwood vă impune o parte din acea structură, astfel încât să nu trebuiască să vă gândiți la asta și astfel încât să vă poată pune instalațiile sanitare și să reia de unde a rămas React în ceea ce privește oferirea dvs. genul ăsta de structură.

Anthony: Da, și cred că este foarte interesant că am văzut mai multe încercări diferite de a soluționa această problemă, pentru că vreau să spun că ai avut oameni care au spus-o dintotdeauna: „De ce nu există șine pentru JavaScript sau un Rails for React?” Există un interviu grozav Full Stack Radio între Michael Chan și Adam Wathan numit React is Not a Rails competitor. Acesta este unul dintre cadrele diferite.

Anthony: Ceilalți sunt BlitzJS, care a obținut o cantitate decentă de zgomot, iar apoi Bison este un fel de nou în curs de dezvoltare. Toate au o stivă similară, dar folosesc piese diferite. Veți avea interogarea React în loc de Apollo sau veți avea Chakra în loc de Tailwind. Oamenii care adună toate aceste piese în stivele lor, toate aceste stive sunt oarecum, se luptă, totul este o competiție foarte prietenoasă. De fapt, acesta este un lucru pe care îl apreciez foarte mult, este că de fapt toți colaborăm și între cadre. Nu există animozitate acolo.

Drew: Deci, am menționat Apollo și GraphQL, Redwood folosește GraphQL destul de mult ca una dintre elementele de bază ale cadrului, nu-i așa? Probabil că putem dedica un întreg episod de podcast doar lui GraphQL, dar pentru cei care nu sunt familiarizați, ce piesă face GraphQL aici, ce problemă rezolvă în acest context?

Anthony: Da, aceasta este o întrebare grozavă. Când le spun oamenilor ce ar trebui să știe pentru a începe bine cu Redwood, le-aș spune că ar fi trebuit să utilizați aplicația Create React, doar dacă ați creat o aplicație Create React și ați implementat-o ​​pe Netlify sau Vercel, asta îți va da un început bun. Apoi, cunoașteți măcar puțin despre GraphQL, deoarece este foarte central. Deci, GraphQL este modul în care front-end-ul tău va vorbi cu back-end-ul tău. Ei spun că este un limbaj de interogare pentru API, ideea fiind că este menit să fie o alternativă la metodele API RESTful și că, în loc să faceți acest lucru RESTful, trimiteți interogări care specifică exact structura ierarhică a datelor de la care doriți să primiți înapoi. baza de date. Deci, este nevoie de puțin mai mult timp de pornire pentru ca serverul dvs. GraphQL să vorbească cu cele două părți. Apoi, odată ce îl aveți acolo, dezvoltatorii front-end au capacitatea de a obține date într-un mod mult mai flexibil. Nu aveți nevoie de toate aceste puncte finale API diferite pe care oamenii de la back-end trebuie să le facă în continuare.

Drew: Deci, dacă există modificări ale cerințelor în front-end, probabil că puteți modifica interogarea GraphQL și nu aveți nevoie de ajutorul cuiva care lucrează la back-end pentru a face acea schimbare pentru dvs.?

Anthony: Vreau să spun, adevăratul vis este că îi poți folosi un client mobil, că ar fi atât de flexibil în cele din urmă încât să devină, poți avea mai mulți clienți care vorbesc cu singurul tău API. API-ul tău GraphQL devine sursa ta de adevăr, acolo este centralizată toată logica ta. Apoi, puteți construi toate aceste straturi de vizualizare diferite deasupra.

Drew: Deci, avem GraphQL acolo, dându-ne posibilitatea de a interoga un fel de back-end. În Redwood, care este partea din spate?

Anthony: Da. Există câteva moduri diferite de a vă crea back-end. Există modul în care veți ieși din cutie cu tutorialul, adică folosiți baza de date Postgres implementată pe Heroku, super ușor, super simplu. Apoi, aplicația Redwood îi vorbește cu Prisma. Nu știu dacă ești deloc familiarizat cu Prisma, dar este ca un O/RM. Ei spun în mod special că nu este un O/RM, este un generator de interogări, care este un nivel puțin mai inferior. Dar, de dragul de a le explica oamenilor, Prisma este lucrul care vă permite să vorbiți cu baza de date. Îți face migrările și îți configurează tabelele. Face toate lucrurile SQL, astfel încât nu trebuie să scrieți SQL. Pentru mine, asta sună ca un O/RM. Nu trebuie neapărat să utilizați Prisma pentru a folosi Redwood.

Anthony: De fapt, am construit o aplicație doar pentru dovada conceptului în care am folosit FaunaDB. FaunaDB, au propriul lor API GraphQL, așa că puteți pur și simplu să trimiteți API-ul GraphQL direct către Fauna și apoi să faceți mutațiile bazei de date în acest fel. Pierzi mult din funcționalitatea CLI-ului Prisma, dar Prisma este într-adevăr un factor de confort pentru a lucra foarte ușor cu baza ta relațională. Dar, într-adevăr, orice te-ai putea gândi, ai putea să-ți dai seama cum să-l conectezi cu Redwood este ceea ce am aflat doar pentru că este construit în jurul GraphQL și ideea este să poți vorbi cu toate aceste piese diferite.

Drew: Deci, Prisma este, în esență, un fel de strat de abstractizare între codul tău și orice depozit de date pe care îl folosești, probabil pe care Prisma îl acceptă, este... sau face lucruri mai inteligente decât atât?

Anthony: Da, deci scrii o schemă, așa că creezi o schemă. Fișier Prisma și ar avea post model, apoi ar avea id și întreg și incrementare automată, cum ar fi titlul, șirul de corp, creat la dată, oră . Deci, ai crea practic ceea ce vrei să fie în baza ta de date cu tipurile, iar apoi face lucrurile din baza de date pentru tine, astfel încât să nu fii nevoit să interacționezi cu baza de date.

Drew: Deci, folosești Prisma pentru a defini, presupun ce fel de bază de date sau ce fel de magazin de date cu care vorbești. Apoi, acolo vă așezați diferitele modele mvc pentru a folosi acest limbaj. Deci, atunci când aplicația dvs. vorbește cu depozitele de date, folosește un fel de instanță a unui client Prisma, nu-i așa? Asta se întâmplă?

Anthony: Da. Da, exact asta este. Deci, în folderul API al back-end-ului, aveți un folder lib cu un db.js și, implicit, care are clientul dvs. Prisma configurat. Deci, acestea sunt toate lucrurile pe care le scoateți din cutie și, așa cum ați spus, Prisma poate lucra cu diferite baze de date. Poate comuta între SQLite pentru dezvoltare și apoi Postgres pentru producție, așa ceva. În cea mai mare parte, sunt relaționale în acest moment, dar foaia de parcurs conține lucruri precum Mongo și Fauna.

Drew: Deci, este destul de util dacă puteți configura și utiliza SQLite în mediul dvs. de dezvoltare local pe măsură ce puneți lucrurile în funcțiune și apoi intrați în producție cu ceva de genul MySQL.

Anthony: Exact așa este configurat tutorialul, acesta este fluxul de lucru pe care ți-l arată.

Drew: Este destul de interesant, nu-i așa, să vezi o abordare foarte modernă a unui cadru, apoi recurgerea la unele dintre aceste baze de date mai tradiționale precum MySQL. Sunt foarte familiarizat cu MySQL. Îl ador pentru stabilitatea sa și îmi place modul relațional de stocare a datelor. Cred că funcționează atât de bine pentru atâtea lucruri. Adesea vezi copilul aruncat, care era apa de la baie atunci când vine vorba de tipurile mai noi de depozit de date, așa că este destul de interesant să vezi că Redwood acceptă implicit aceste baze de date relaționale bune și vechi.

Anthony: Da, nu, ăsta este un punct atât de bun, pentru că eu spun că pentru toate lucrurile noi pe care Redwood le combină, există unele lucruri care spun de fapt că modul vechi, încercat și adevărat este de fapt cel mai bun. Deci, sunt foarte mari în bazele de date relaționale. Asta vine din experiența lui Tom cu utilizarea Rails și având un back end relațional. Active Record a fost stratul O/RM pe care Prisma a vrut să-l aproximeze.

Drew: Cred că vorbim despre o arhitectură fără server aici cu Redwood și am vorbit cu Chris Coyier, cred că două sau trei episoade în urmă, totul despre utilizarea API-urilor fără server și a funcției cloud și altele. Deci, făcând un pas înapoi, dacă ar fi să vă gândiți în termeni de un cadru bazat pe server, așa cum am menționat Ruby on Rails sau ceva de genul Laravel în lumea PHP. Chiar și cu un front end React, solicitarea dvs. API ar rula cod care este codul Rails sau codul Laravel plus apoi codul dvs. de utilizator și configurația. Este același lucru cu Redwood? Există un cod de server Redwood care rulează sau este doar mai multe instrumente, structură și lipici care vă permit să vă implementați propriul dvs.?

Anthony: Da, deci, în partea din spate, există un fișier specific care este o modalitate de a vă prelua SDL-ul, astfel încât aveți limbajul de definire a schemei și apoi aveți ceea ce se numesc serviciile dvs., care sunt ca metodele dvs. de a vorbi cu dvs. capătul din spate. Apoi, toate acestea sunt îmbinate într-un handler GraphQL care este implementat într-o singură funcție Lambda. Deci, este optimizat special pentru Lambda. De fapt, recent am avut pe cineva să o facă cu cadrul fără server și avem unii oameni care lucrează la Azure și Google Cloud ceva. Nu este funcția Google Cloud, este cea construită pe deasupra. Dar da, așa că acum este practic optimizat pentru implementarea back-end-ului ca funcție GraphQL într-un AWS Lambda. Acestea sunt lucrurile magice care se întâmplă în cod pe care nu le înțeleg, dar aceasta este explicația la nivel înalt.

Drew: Deci, există instrumente de implementare, care preiau tot codul pe care l-ai scris, îl comprimă totul într-un fel de minge magică de cod care poate fi executat în cloud și îl plasează pe AWS sau vrei mai trebuie să gestionați singur acest proces?

Anthony: Da, așa că totul se face prin Netlify dacă urmați tutorialul. Nu trebuie să te încurci singur cu niciun fel de funcții fără server. Lucrurile care vă conectează spatele pentru a le introduce în AWS Lambda, toate acestea sunt gestionate, nu trebuie să atingeți niciun cod. Toate acestea sunt generate imediat ca convențiile tale asupra configurațiilor tale, așa că nu trebuie să te gândești prea mult la cum să-l faci fără server. Este implicit fără server. Este într-adevăr un lucru greu să-ți înțelegi capul. Mi-a luat ceva timp să-mi învălui capul în jurul ei.

Drew: Da, pentru că este un punct important, nu pentru că există acum câteva zone diferite pe care le urmărim aici. Cred că avem trei domenii diferite. Avem aplicația noastră frontală React, care rulează în browser și apoi avem un API care se bazează pe GraphQL, rulează ca funcție cloud și care răspunde la interogările noastre, dar care interacționează apoi cu un depozit de date care folosește Prisma. Și acel depozit de date este ce și unde în asta, pentru că nu poți rula un server MySQL pe Netlify, nu-i așa?

Anthony: Da, aici intervine Heroku. Deci, în ultima parte a tutorialului, îți implementezi front-end-ul la Netlify și apoi îți implementezi back-end-ul la Heroku Postgres și iei doar variabilele de configurare din Heroku, îl conectezi. în Netlify. A face front-end-ul tău Netlify să vorbească cu back-end-ul tău Postgres este un lucru foarte, foarte simplu. Au vrut să meargă cu lucrul care urma să fie cel mai ușor pentru oricine, dar totuși să aibă o tehnologie bună, stabilă, testată în luptă. La final, ceea ce scoți din cutie doar urmând instrucțiunile, este cu adevărat incredibil.

Drew: Pasionații de Jamstack vor fi familiarizați cu servicii precum FaunaDB pe care le-ați menționat, care oferă un depozit de date ca API, AWS are DynamoDB, Google are Cloud SQL și așa mai departe. Deci, ați menționat că Redwood urmărește să se integreze sau presupun că Prisma este componenta de aici care urmărește integrarea cu astfel de servicii mai departe?

Anthony: Da, aceasta este o întrebare bună. Acesta este ceva cu care vorbesc cu Ryan Chenkie la Prisma despre cum să ajut, care este genul de poveste de bază de date pentru Redwood pentru lucruri care nu funcționează neapărat cu Prisma? Ar fi mai bine să găsesc o modalitate de a-l face pe Redwood să lucreze direct cu el, așa cum am făcut-o cu Fauna sau ar fi mai logic să implementez un driver pentru Prisma? Deci, există moduri diferite de a-l aborda. În mod evident, există un milion de baze de date diferite acum pe care toată lumea vrea să le folosească, așa că este cât de motivat sunteți să introduceți depozitul de date pe el. Sunt multe contribuții ale comunității acolo.

Drew: Deci, pentru că Prisma vă înțelege modelul și știe cum să le interogheze, este capabilă să genereze un fel de migrări sau lucruri de genul ăsta pentru a vă ajuta să configurați baza de date?

Anthony: Exact lucrul pe care îl pierzi când trebuie să scoți Prisma și să-ți iei datele, este că pierzi toate funcțiile de migrare. Are un CLI foarte avansat, care face o mulțime de lucruri pentru tine, așa că poți parcurge întregul tutorial Redwood și introduce comenzile Prisma și nu trebuie să ai idee ce face, pur și simplu funcționează. Este un instrument cu adevărat grozav pentru a face toate acele lucruri de tip bază de date pe care doriți să vă asigurați că ați făcut bine și că doriți să vă asigurați că sunt făcute corect.

Drew: Se pare că a avea un instrument foarte bun în jurul cadrelor este o tendință destul de modernă, nu-i așa? Pentru a nu spune doar: „Iată toate lucrurile pe care acest cadru le poate face, dar iată, probabil, câteva instrumente CLI care vor face o mulțime de lucruri pentru tine.” Redwood are instrumente pentru lucruri precum generatoarele CLI și chestii pentru a vă pune în funcțiune rapid?

Anthony: Aceasta este probabil cea mai mare caracteristică cheie pe care o obțineți de la Redwood, este că obțineți un set întreg de generatoare foarte sofisticate. Pentru oricine a văzut vreodată demonstrația originală Ruby on Rails, oferită de DHH, el creează un blog în aproximativ 15 minute și face totul cu Rails, iar oamenii spun: „Uau, asta este uimitor”. Acesta este efectul cu care are Redwood. Ei vor ca tu să poți învârti totul foarte repede, astfel încât să poți genera pagini, să poți genera machete, să-ți poți genera celulele, despre care vorbeam și să poți face o comandă de schelă care va crea întregul tău interfață CRUD. Am o întreagă secțiune, partea a patra a seriei de bloguri, care explică tot codul pe care ți-l oferă schela. Îți oferă atât de mult cod. Există un generator oprit, există chiar și un generator Tailwind care vă configurează vântul în spate.

Drew: E uimitor. Îmi amintesc că am văzut demonstrația Rails de la DHH. Vreau să spun, probabil că a fost, acum 15 ani, când a făcut pentru prima dată schela aia și ți-a arătat, și ai un panou de control destul de rudimentar, dar funcțional, în esență, pentru a vă permite să creați elemente noi, să le editați, să le ștergeți etc. . Acest lucru poate fi de neprețuit într-un proiect, mai ales lucrul într-un fel de mediu dinamic în care, bine, poate veți implementa instrumente mai bune în viitor pentru editarea conținutului respectiv, dar înseamnă că puteți învârti ceva rapid, puteți obține testați datele sau le puteți chiar preda unei echipe de conținut care ar putea începe să lucreze în timp ce lucrați la front-end, așa că este foarte util.

Drew: Dacă ai vrut doar să implementezi asta și să-l ai în producție, probabil că îl poți implementa împreună cu codul tău frontal, dar ai avea nevoie de o modalitate de a securiza acel aspect, acele rădăcini în aplicația ta.

Anthony: Da, există câteva opțiuni diferite pentru autentificare. Puteți utiliza identitatea Netlify. Aceasta este valoarea implicită dacă intri în tutorial și apoi poți folosi și Auth0, apoi unul cu care nu sunt familiarizat, numit Magic.Link, și probabil că vor mai fi adăugate câteva în viitor. Dar da, deci există deja câteva soluții încorporate și acesta este ultimul lucru pe care îl faci, așa că ultima parte a întregii mele serii de bloguri din 12 părți este cea Auth. Nu cred că mi-am dat seama vreodată de Auth înainte să folosesc Redwood. Este greu și cu siguranță au făcut o treabă bună cu el.

Drew: Se integrează la nivel de rută sau la nivel de rută, îmi pare rău, cum securizați lucrurile?

Anthony: Da, deci o parte din modul în care au propriul lor router, au și... Puteți face rute private, așa că au o componentă de rută privată. Apoi, formularul dvs. de autentificare real, asta este ceea ce obțineți de la identitatea Netlify, astfel încât să nu trebuie să creați un formular și să faceți managementul statului cu asta, acolo intră în joc multe probleme. Eliminați părțile cu adevărat cheie și apoi puteți implementa doar accesul bazat pe roluri. Avem un control al accesului bazat pe rol, care a fost făcut în ultimele două săptămâni, fie David T. Deci, se lucrează mult pentru a crea alte modalități de a face acest lucru, dar ceea ce au primit acum este deja... funcționează, asta. Te voi face funcțional.

Drew: Oamenii spun întotdeauna despre criptografia de hashing al algoritmului de securitate că nu ar trebui să-ți scrii niciodată propria ta, pentru că nu va fi niciodată la fel de bună ca lucrurile care există acolo. Din ce în ce mai mult, cred că acest lucru este valabil și pentru autentificarea la un nivel superior; autentificarea este o zonă atât de complexă în zilele noastre, încât oamenii vor nu doar să se conecteze la site-ul dvs. cu acreditări unice, ci ar putea dori să se autentifice folosind Google sau ar putea dori să se autentifice folosind un dispozitiv Apple sau ar putea dori autentificarea cu doi factori. , sau ar putea dori să-l integreze cu un serviciu de conectare unică pe care îl utilizează de la o întreprindere. Toate aceste lucruri sunt atât de dureroase de cap dacă încerci să le implementezi singur și atât de multe șanse de a greși ceva și de a expune găurile de securitate în aplicația ta, încât utilizarea unui serviciu de autentificare mi se pare aproape o idee în acest moment. Așadar, a putea introduce ceva în esențial câteva linii de cod și a fi funcțional sună ca un mod cu adevărat productiv de a lucra și de a menține lucrurile în siguranță.

Drew: Se pare că implementarea atât a aspectelor front-end, cât și a serverului, a funcțiilor fără server, este o potrivire naturală pentru implementarea pe Netlify. Ești legat de asta cu Redwood? Adică, am menționat că Tom Preston-Werner este unul dintre principalii susținători ai acestui cadru, el este și în consiliul de administrație la Netlify. Credeți că există potențialul pentru o cuplare prea strânsă acolo dacă ar fi să alegeți Redwood ca bază pentru un proiect?

Anthony: Da, acesta este ceva de care Tom este cu siguranță conștient. A investit în multe companii care plutesc. A investit în Prisma și Fauna. El vrea să facă doar instrumentele pe care vrea să le folosească. Nu este vorba că vrem să te blocăm în acest lucru atât de mult, ci despre ceea ce Netlify a construit consideră că este cea mai bună opțiune, așa că de aceea au construit în jurul ei. Dar, ei nu doresc ca acesta să fie blocat în nicio țintă de implementare și de aceea avem de lucru pe lucruri precum cadrul fără server și unii oameni au vorbit despre Begin. Vrem să fim pragmatici, vrem să funcționeze pentru orice caz de utilizare al cuiva. Așadar, vă obținem 90% din drum și apoi trebuie doar să conectați ultimele două lucruri pentru a-l face să funcționeze cu oricare dintre serverele pe care le alegeți.

Drew: Bănuiesc că chiar și Netlify folosește AWS Lambda pentru funcțiile serverelor, așa că este cu adevărat partea de implementare de care se ocupă Redwood acolo și, de fapt, ai putea să o implementezi în Lambda. Postarea front-end-ului este doar fișiere, nu-i așa, restul se bazează pe CDN? Deci, există destul de multă flexibilitate acolo fără a fi prea legat.

Anthony: Da, există de fapt un termen despre care Tom vorbește ca fiind ideea filozofică de bază din spatele Redwood, și anume că vrem să ajungem la o mașină de implementare universală. Cam asta e ideea, este că poți doar să implementezi lucruri și nu trebuie să te gândești deloc la asta. El a vorbit despre această idee de ani și ani și ani, și despre asta era chiar și Jekyll pe vremuri. Când auzi asta acum, spui: „Oh, vrei să spui ca Netlify?” Practic, asta este Netlify pentru majoritatea oamenilor care lucrează la front-end. Nici nu se mai gândesc la desfășurare, nici măcar nu e un gând.

Drew: Iată aplicația mea într-un Git Repo, acest director este front-end-ul, acest director este back-end-ul, iată baza mea de date, și asta este cam atâta configurație cât poate ai avea nevoie pentru orice serviciu pentru a-l lua și pentru a-l construi și găzduiește-l.

Anthony: Da, și un lucru pe care ar trebui să-l subliniez, tocmai de curând am configurat implementarea implicită Vercel Redwood, așa că atunci când implementați pe o aplicație pe partea serverului puteți spune: „Oh, am aplicația Gatsby” și știe exact cum să creeze o aplicație Gatsby față de o aplicație Next. Avem asta pentru Vercel acum. Deci, există și opțiuni foarte, foarte bune non-Netlify, dacă ești mai interesat de asta.

Drew: Deci, dacă aș vrea să încep și să construiesc o aplicație și să o lansez în producție săptămâna aceasta, este Redwood gata pentru asta? Este matur?

Anthony: Da, avem aproximativ o jumătate de duzină de aplicații care sunt în producție chiar acum. Prima se numea Predict COVID, care a apărut în martie și este ca o aplicație de vizualizare a datelor în timp real. Apoi, avem repeater.dev este realizat de Rob, este ca o lucrare cron ca lucru pentru Jamstack. Apoi, există Tape.sh, Duoflag cred că este altul. Deci, există cel puțin o mână. Dacă mergeți la un depozit minunat Redwood, puteți vedea o listă cu toate. Dacă mergi pe forumurile comunității, poți găsi și scrieri despre acestea, pentru că oamenii le-au pus în producție și au spus cum a mers. Până acum, toți au avut succes și nimeni nu a spus: „Nu mai folosesc niciodată asta”.

Drew: Dar, este foarte nou. Cred că nu se poate scăpa de asta, dar în ceea ce privește maturitatea, Redwood este destul de nou, obține o mulțime de urmăritori.

Anthony: Ei bine, este amuzant, este și nu este. A fost anunțat în martie. În acel moment, Tom și Peter lucrau la el timp de aproximativ un an. 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: Desigur.

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. Ai cuvinte de despărțire?

Anthony: Doar dacă sunteți interesat de oricare dintre aceste lucruri, nu ezitați să contactați. DM-urile mele sunt mereu deschise. Comunitatea este foarte deschisă în general. Voi fi bucuros să vă explic sau să vă fac pregătiri cu orice trebuie să știți pentru a începe.