Smashing Podcast Episodul 29 cu Leslie Cohn-Wein: Cum Netlify Dogfood The Jamstack?

În acest episod, ne întrebăm cum arată testarea Jamstack-ului la Netlify. Puteți implementa o întreagă aplicație pe un CDN? Drew McLellan vorbește cu inginerul personalului Netlify Leslie Cohn-Wein pentru a afla.

Afișați note

• Site-ul personal al lui Leslie
• Leslie pe Twitter
• Netlify

Actualizare săptămânală

• O scufundare în React și Three.js folosind react-three-fiber
  scris de Fortune Ikechi
• Cele mai bune practici pentru designul interfeței de utilizare pentru comerțul electronic
  scris de Suzanne Scacca
• Autentificarea aplicațiilor React cu Auth0
  scris de Nefe Emadamerho-Atori
• De la Experți: Evoluții globale ale accesibilității digitale în timpul COVID-19
  scris de Robin Christopherson
• Ce este nou în Vue 3?
  scris de Timi Omoyeni

Transcriere

Drew McLellan: Ea este un specialist în front-end premiat, originar din Austin, dar acum locuiește în Dallas, Texas, printr-o perioadă în New York. În acea perioadă, lucrând pentru agenții, a construit site-uri pentru clienți, precum Nintendo, WorldPride și Jerry Seinfeld. Acum este inginer front-end personal la Netlify, unde, printre altele, lucrează la construirea aplicației pe care clienții le folosesc pentru a-și gestiona serviciile și implementările. Așadar, știm că este un inginer desăvârșit, dar știai că, când locuia în orașul New York, ea a servit ca judecător asistent pentru gătit chili trei ani la rând. Și acesta este de fapt adevărat. Prietenii mei zdrobitori, vă rog bun venit lui Leslie Cohn-Wein. Bună, Leslie. Ce mai faci?

Leslie Cohn-Wein: Sunt zdrobitoare.

Drew: Am vrut să vă vorbesc astăzi despre cum Netlify își mănâncă hrana pentru câini, pentru a folosi această expresie fermecătoare, când vine vorba de a construi pe Jamstack. Ar trebui să pun acest lucru în context, spunând că până acum câteva luni, am lucrat împreună în aceeași echipă la Netlify. Și când am ajuns acolo, procesul de dezvoltare mi-a fost de fapt străin, chiar și după 20 de ani ca dezvoltator. Am crezut că este cu adevărat fascinant și merită explorat puțin, cu un public mai larg. Probabil ar trebui să subliniez că vorbim despre asta pentru că este un studiu de caz cu adevărat interesant și nu este o reclamă mare sponsorizată pentru Netlify. Toată lumea ar trebui să verifice Vercel. Dar cred că există o mulțime de lucruri valoroase care pot fi învățate din discutarea asta, în special din punctul de vedere al Jamstack. Pentru că Netlify este un mare susținător al abordării Jamstack, iar serviciul este oarecum oferit clientului și este construit în jurul ideii de a construi proiecte Jamstack. Dar serviciul este construit și folosind acele principii în sine. nu-i asa?

Leslie: Este, da. Mulți oameni se gândesc la acea arhitectură Jamstack ca pe site-uri statice, dar noi încercăm cu adevărat ce înseamnă să construiești o aplicație Jamstack cu front-end Netlify. Pentru că este o aplicație React care este o aplicație completă Jamstack pe care o implementăm Netlify pe Netlify, așa că... Da, chiar o încercăm și depășim limitele a ceea ce este posibil.

Drew: Cred că uneori există ideea că Jamstack este grozav doar pentru site-uri statice, așa cum spuneți, și aspectul API intervine dacă doriți să trimiteți un formular la o adresă de e-mail și puteți face ceva ușor de genul acesta, dar dvs. poate construi o întreagă aplicație web în acest fel. Dar, tu faci asta, nu-i așa?

Leslie: Da, absolut. Aplicația noastră, care vorbește în mod specific despre ceea ce vedeți dacă vă conectați la app.netlify.com, este alimentată de... avem un API REST intern, dar interfața, așa cum am spus, este Jamstack pur. Deci, avem propriul nostru pas de construire, urmărim aplicația așa cum se construiește în aplicație și implementăm pe propriul nostru sistem.

Drew: Deci, atunci când este implicat un proces de backend și întotdeauna va exista un fel de nivel de procese de backend, știi, date persistente sau, în cazul Netlify, pornind de la o implementare sau ce ai tu, acel backend doar este un fel de construit ca o serie de API-uri care pot fi apoi consumate de front-end?

Leslie: Da, deci există câteva modele diferite despre cum poți face asta să funcționeze. În cele mai multe cazuri, în aplicația noastră, folosim preluarea din partea clientului cu React, nu? Deci, servim un fel de shell static al aplicației și apoi preluăm informațiile utilizatorului din API-ul nostru intern REST la momentul solicitării. Jamstack este interesant pentru că există unele lucruri pe care le puteți pre-construi, iar noi încercăm să ne bazăm pe acestea când putem. Și atunci când vorbim despre unele dintre datele mai dinamice, vom folosi acea preluare din partea clientului pentru a ne asigura că extragem cele mai noi date.

Drew: Cred că m-a surprins, când am început să lucrez la aplicație, cât de mult se realizează în front-end, în special când vine vorba de interacțiunea cu API-uri și lucruri externe. Știu că atunci când Netlify interacționează cu furnizorul tău Git, așa că merge la GitHub și primește o listă de repoziții, toate acestea se întâmplă între browserul tău și GitHub. Și în afară de poate... trecerea printr-o funcție fără server care pune câteva secrete pe cerere sau ceva ușor de genul ăsta, majoritatea se întâmplă într-un fel Jamstack-y. Nu trece printr-un fel de infrastructură de bază de backend Netlify. Deci, este destul de fascinant. Asta într-adevăr merge mult mai departe dincolo de un site static cu câteva apeluri API pentru a face lucruri mărunte. Aceasta este funcționalitatea de bază reală, nu-i așa, care este implementată în browser?

Leslie: Absolut. Chiar împinge, cred, acel concept despre ceea ce este un inginer de dezvoltare frontend, nu? Și este ceva care mă împinge, ca inginer de front-end, să fiu mai bun și să mă gândesc mai mult la acest fel de... stratul API, care nu este ceva de care am fost în mod tradițional atât de aproape. Lucrez mai mult în UI și culori și sisteme de design și, deci, într-adevăr... Am descoperit că lucrul la o aplicație Jamstack la scară m-a împins să fiu un dezvoltator mai bun.

Drew: A fi dezvoltator de front-end nu înseamnă a cunoaște CSS din spate în față, deși asta face parte din asta. Nu este cunoașterea HTML din spate în față, dar deși asta face parte din asta. De asemenea, se rătăcește în acest teritoriu care era în mod tradițional rezerva unui inginer backend, ceea ce este destul de interesant. Utilizează Netlify o nouă redare pe partea serverului pentru-

Leslie: Nu că eu știu.

Drew: Deci, totul este literalmente gata, așa cum spuneți, serviți un shell și apoi este populat cu solicitări înapoi la diferite puncte finale API pentru a le popula într-un fel pe toate.

Leslie: Exact.

Drew: Și spui că este o aplicație React?

Leslie: Da. Da. Reacţiona. Folosim React Redux chiar acum și acum suntem PostCSS, dar experimentăm și arhitectura noastră CSS.

Drew: Nu suntem toți? Deci, construiești aplicația în React și apoi o implementezi pe Netlify?

Leslie: Da. Poate că partea mea preferată din întregul proces este magia Deploy Previews, pe care o obținem prin Netlify. Deci, ceea ce se întâmplă este că vei... vei lucra în GitHub, vei crește PR. Deci, vă deschideți PR în GitHub, iar aceasta va crea automat o versiune a Previzualizării implementării aplicației. Deci, folosim de fapt Deploy Previews ale aplicației în sine pentru a testa, pentru a ne asigura că totul funcționează așa cum ar trebui. Ne rulăm testele. Acesta este ceea ce folosim pentru a verifica manual în timpul examinării codului. Deci, avem un fel de toate acele implementări continue configurate chiar din GitHub.

Leslie: Și apoi unul dintre celelalte lucruri interesante pe care le-am configurat este că avem de fapt câteva site-uri Netlify diferite care extrag din același depozit în care se află aplicația noastră. Deci, avem ambele aplicații noastre, avem o instanță de Storybook care are un fel de componente ale UI pentru aplicație. Deci, avem atât aplicația noastră, cât și componentele Storybook UI și, practic, avem un site Netlify care arată Storybook UI. Și apoi avem și un al treilea site care rulează un analizor de pachete webpack. Deci, este o interfață de utilizare vizuală care vă oferă o hartă arborescentă, vizualizarea tuturor pachetelor de aplicații și le putem măsura dimensiunea și este doar un memento pentru noi să verificăm de două ori. Pe măsură ce fiecare implementare a aplicației se stinge, putem verifica și ne asigură că nu facem nimic ciudat cu dimensiunea pachetului nostru acolo. Așadar, toate aceste trei site-uri sunt generate într-o singură cerere de tragere a aplicației. Așadar, veți primi linkuri către previzualizarea, în esență, Previzualizările dvs. de implementare, atât ale aplicației Storybook, cât și către profilul respectiv al aplicației, pentru ca noi să le verificăm.

Drew: Și odată cu Deploy Previews, acesta devine, în esență, mediul tău de punere în scenă, nu-i așa?

Leslie: Exact. Nu rulăm cu adevărat un mediu tradițional de organizare, pentru că avem încredere că Previzualizările noastre de implementare sunt în esență ceea ce va fi disponibil atunci când apăsăm butonul de îmbinare și lansăm versiunea oficială a sucursalei noastre principale în aplicația noastră principală. Așadar, îmi place că ne putem baza pe Deploy Previews ca mediu de pregătire. Avem cu adevărat încredere că se va potrivi cu producția. Îl construim cu toate variabilele de producție, tot ceea ce... variabilele de mediu, toate aceste lucruri sunt construite în Previzualizarea implementării. Deci, este aproape ca o situație fără griji. Atâta timp cât funcția Deploy Preview funcționează, știți că și aplicația va funcționa.

Drew: Și cred că, ca organizație, dacă Deploy Preview nu se potrivește cu ceea ce este pus live, atunci aceasta este o problemă de serviciu pe care Netlify vrea să o rezolve. Deci, funcționează destul de bine din acest punct de vedere. Deci, ați revizuit o previzualizare a implementării, totul arată grozav, PR este fuzionat. Ce se întâmplă atunci?

Leslie: Deci, pentru că Netlify rulează toată implementarea noastră continuă, în esență, avem totul conectat, astfel încât orice îmbinare în filiala noastră principală va demara automat o implementare oficială de producție cu aplicația. Deci, de obicei, dacă sunteți dezvoltatorul care și-a îmbinat propriul PR, veți intra în actualul... trebuie să vă asigurați, să vă verificați filele, deoarece dacă aveți o Previzualizare implementare a aplicației deschisă și aplicația, trebuie să te asiguri... de obicei vrei să urmărești în aplicația reală. Deci, trebuie să vă verificați fila. Dar, da, în aplicație, de obicei intri, poți urmări jurnalele de construire pentru acea îmbinare pe care tocmai ai început-o, așa că totul este automat. Și apoi, de îndată ce acele jurnale de compilare se termină și site-ul este live, tot ce trebuie să faceți este să vă reîmprospătați fereastra browserului și veți vedea că orice ați implementat, ar trebui să fie actualizat în aplicație.

Drew: Și să presupunem că înțelegi o problemă odată ce a fost lansată, ce faci atunci?

Leslie: E o întrebare foarte bună. Și poate că unul dintre lucrurile mele preferate despre utilizarea Netlify, chiar înainte de a lucra la Netlify, asta a fost ca un pic de magie pentru mine, pentru că Netlify a inclus într-un fel, ceea ce numim, rollback-uri. Deci, în esență, fiecare implementare pe Netlify... deoarece folosim această arhitectură Jamstack, fiecare implementare este atomică. Deci, ceea ce înseamnă că aveți acest istoric complet al fiecărui tip de implementare pe care l-ați făcut vreodată pe un site și puteți reveni instantaneu la oricare dintre acestea. Deci, dacă implementăm accidental o eroare sau ceva este rupt, primul lucru pe care îl facem de obicei este să oprim această integrare continuă. Deci, vom intra și este doar un buton din interfața de utilizare Netlify pe care spuneți „Opriți publicarea automată” și ceea ce va face este să oprească acea conexiune cu GitHub. Deci, dacă colegul meu de echipă își unește brusc și PR, nu vom reintroduce bug-ul, nu se va întâmpla așa ceva.

Leslie: Deci, oprim toate aceste implementări automate. Și apoi tot ce trebuie să fac este să mă întorc în lista mea de implementări și să găsesc ultima implementare funcțională, să apăs pe încă un buton care spune „Publică-l pe acesta” și se lansează. Deci, ceea ce înseamnă, este că scapă de presiunea pentru a putea să te întorci cu adevărat, să te uiți la cod, să descoperi ce s-a întâmplat de fapt. Uneori, asta înseamnă să faci o revenire Git pe ramura ta principală și să aduci ramura principală înapoi acolo unde trebuia. Și, uneori, este o soluție fierbinte sau mergi pe o ramură și o rezolvi și nici măcar nu trebuie să-ți faci griji cu privire la revenirea în Git. Și apoi, când sunteți gata să reveniți, vă asigurați că totul funcționează în Previzualizarea implementării aplicației și puteți pur și simplu să resetați toate acele lucruri. Deci, de îndată ce începeți aceste implementări automate, practic vă reveniți în afaceri.

Drew: Deci, am observat o problemă aici.

Leslie: Uh oh.

Drew: Folosiți Netlify pentru a implementa modificări în aplicația Netlify. Ce se întâmplă dacă eroarea pe care ați instalat-o vă împiedică să reveniți? Ce faci atunci?

Leslie: Am coșmaruri. Nu. De fapt, avem câteva moduri care ar putea face față asta. Deci, dacă dezactivăm aplicația și nu putem folosi interfața de utilizare pentru a parcurge acest proces, Previzualizările noastre de implementare rulează de fapt pe API-ul nostru de producție. Deci, ceea ce înseamnă că, chiar dacă aplicația nu funcționează, mai avem acele implementări atomice. Deci, dacă aveți un link de la GitHub, poate de la un PR vechi sau recent, și aveți acea adresă URL a Deploy Preview, puteți accesa Deploy Preview a aplicației și puteți face orice modificare de care aveți nevoie, reveniți și publicați o implementare mai veche. din Previzualizarea implementării. Și încă atinge API-ul nostru de producție, așa că va afecta în continuare aplicația și apoi va aduce aplicația înapoi. Este ca un fel de emoji-uri care explodează acolo, dar este o modalitate de a face acest lucru. De asemenea, am putea publica o implementare mai veche din unele dintre sistemele noastre backend. Am putea determina inginerii noștri backend să publice asta pentru noi. Sau poți folosi oricând Git pentru a reveni și a încerca să împingi asta, dar este puțin înfricoșător pentru că nu poți urmări ce faci.

Drew: Cred că ai nevoie doar de o minte foarte clară pentru a gestiona situația.

Leslie: Da.

Drew: Dar este complet recuperabil, se pare că este.

Leslie: Da. Ei bine, și odată ce ți-ai publicat implementarea de lucru, toată presiunea este oprită. Asta e cu adevărat partea cea mai frumoasă. Și am găsit asta lucrând și în agenții. A putea face înapoi a fost cu adevărat o salvare pentru... De asemenea, te face mai puțin îngrijorat cu privire la publicarea unor noi modificări. Dacă spargi ceva, durează o secundă să-l rotești înapoi, ceea ce se potrivește foarte bine cu tipul de mișcare rapidă și de a scoate lucrurile afară.

Drew: Cu siguranță. Cred că, de obicei, acest tip de întreg flux de lucru funcționează cel mai bine atunci când aveți de-a face cu schimbări foarte mici. Adică, în mod ideal, doriți să creați o sucursală, să implementați o mică schimbare, să ridicați un PR și apoi să o reunați cât mai repede posibil. Ceea ce, evident, funcționează bine pentru ajustări și remedieri de erori și lucruri mărunte, dar nu funcționează atât de bine pentru funcții majore, când această caracteristică ar putea dura săptămâni sau poate chiar luni de când începe până când este gata de implementare. Cum gestionați un astfel de proces?

Leslie: Da, e o întrebare grozavă. Așadar, recent am început să folosim un pic mai mult semnalizatoarele de caracteristici. Înainte de a vorbi mai mult despre cum facem asta, voi vorbi despre ce făceam. Așadar, înainte de a folosi steaguri de caracteristici, cred că toată lumea este familiarizată cu ideea ramurii caracteristice de lungă durată. Cu toții îi urâm, nu? Dar am lucra la PR-urile noastre mai mici. Am îmbina fiecare dintre acestea în mod individual, după revizuirea codului, în această ramură a caracteristicilor care rulează mai lung. Deci, practic, ați avea toate funcțiile noi într-un singur loc, ați putea avea o previzualizare de implementare cu care puteți testa acea nouă funcție. Uneori, acest model necesită implementări coordonate în alte echipe. Așadar, când eram gata să spunem: „Bine, această ramură a caracteristicilor, suntem gata să o îmbinăm și să o punem live”, ocazional asta însemna: „Bine, trebuie să vă asigurați că backend-ul a implementat deja schimbarea lor”, deci orice Activitatea API pe care o desfășurăm în funcția noastră este gata. Dacă există documente pe site-ul nostru de documente care trebuie să fie difuzate în același timp cu funcția, trebuie să vă coordonați și să apăsați butoanele în același timp.

Leslie: Acest model este... a funcționat pentru noi, dar ai dreptate, că poate nu a fost cel mai bun. De fapt, este destul de amuzant, co-fondatorul și CEO-ul nostru la Netlify, Matt Biilmann, a lansat de fapt funcția noastră de analiză folosind acest proces pe scena Jamstack Conf Londra anul trecut. Așadar, a folosit funcția noastră de blocare pentru a lua, practic, Previzualizarea implementării noii funcții de analiză și pentru a o publica live pe scenă. Deci, a fost destul de mișto.

Leslie: Dar, așa cum ai spus, este... ai puțin mai puțină încredere. Totul este încă cam ascuns în această solicitare de tragere. Devine un pic greu de manevrat. Cineva trebuie să aprobe acea cerere de tragere finală care de obicei este destul de mare. E puțin copleșitor. Așadar, în zilele noastre folosim în mare parte steaguri de caracteristici. Folosim un serviciu numit LaunchDarkly, care ne permite practic să împachetăm noua noastră interfață de utilizare cu aceste semnalizatoare, astfel încât să putem continua fuzionarea codului, chiar dacă interfața de utilizare nu este ceva ce ne dorim ca clienții să vadă. Așadar, trebuie doar să vă asigurați că, în mediul de producție, indicatorul caracteristicii dvs. este dezactivat, putem implementa codul, îl putem îmbina și nimeni... presupunând că sunteți un utilizator general, nu veți vedea noua interfață de utilizare.

Drew: Deci, un semnalizator de caracteristică este, practic, la fel ca un comutator al codului care spune: „Dacă această caracteristică este activată, utilizați acest cod nou, altfel utilizați acest cod vechi.”

Leslie: Exact.

Drew: Asta înseamnă că ai o bază de cod dezordonată cu toate aceste furculițe la locul lor? Cum te descurci cu asta?

Leslie: Da, cred că asta e... oricine folosește steaguri de caracteristici probabil că este obișnuit cu acest tip de bătălie de când curățați steaguri de caracteristici? Cât timp îi lași acolo? Am ajuns la aproximativ două săptămâni după lansarea unei funcții majore, este că avem mementouri. Din fericire, LaunchDarkly a configurat recent o funcție care va notifica Slack. Așadar, îl poți conecta cu Slack și îți va spune doar: „Hei, steag-ul tău a fost... Ai fost live în producție de două săptămâni. Este timpul să vă asigurați că vă curățați steagul din cod.”

Leslie: Deci, încercăm și, și curățăm destul de repede, dar este, în acel interval de timp, este plăcut să știm că steagul este încă acolo. Chiar dacă ați lansat caracteristica, înseamnă că din nou, cu un singur clic, puteți intra și dezactiva steag-ul înapoi, există o eroare, dacă apare ceva. Așadar, ne place să le lăsăm puțin, doar în timp ce funcția se coace cu adevărat, în timp ce oamenii se obișnuiesc cu ea, pentru a ne asigura că nu există probleme majore. Dar apoi încercăm să revenim în cod și este un pic de curățare, deci nu este un proces ideal, dar, de obicei, eliminarea steagului nu durează foarte mult, doar ștergeți câteva rânduri de cod.

Drew: Așadar, cred că cea mai simplă abordare pentru implementarea unui semnalizator de caracteristică ar putea fi doar o... ca o variabilă de configurare în aplicația dvs. care spune „Această caracteristică este activată sau dezactivată”, dar atunci aveți nevoie de o modalitate de a vă asigura că este pornit pentru oamenii potriviți și oprit pentru oamenii potriviți. Și cred că acolo intervine un serviciu precum LaunchDarkly, pentru că este nevoie de asta... Adică, este nevoie de practic ceea ce pornește și dezactivează o variabilă la un nivel extrem, nu-i așa?

Leslie: Da. Da. Exact asta este. Deci, există modalități în care am putea, chiar și fără LaunchDarkly, să setăm noi înșine o variabilă de configurare pe care o gestionăm de la sine. Unul dintre lucrurile pe care le iubesc la LaunchDarkly este că există medii diferite. Deci, ceea ce putem face este, în esență, să activăm un semnalizator de caracteristică pentru Previzualizările noastre de implementare. Deci, oricine vizionează intern la Netlify, o previzualizare de implementare a aplicației poate avea acces la noua funcție, o poate testa, dar, din nou, de îndată ce intră în producție, acel semnal este dezactivat. Deci, este foarte puțin... din nou, trebuie să vă verificați fila și să vă asigurați că știți în ce segment vă aflați, pentru că nu doriți să vă surprindeți și să credeți că ați lansat ceva care nu ai făcut-o, trebuie să fii puțin atent acolo. Dar, în general, funcționează destul de bine, iar LaunchDarkly vă permite să faceți și aceste lansări selective. Deci, puteți implementa o funcție într-un anumit procent din baza de cod sau la un anumit segment de utilizatori, persoane cu un anumit tip de plan sau un anumit tip de utilizator. Așadar, îți permite mult mai mult control asupra cui îi eliberezi.

Drew: Da. Acest lucru poate fi foarte puternic, cred, în special cu funcții sau funcții noi pe care s-ar putea să vă așteptați să rezolvați o problemă. Poate că îmbunătățiți o funcție pentru a o face mai ușor de înțeles, poate o puteți încerca cu 10% dintre utilizatori și să vedeți dacă se confruntă cu aceleași probleme și...

Leslie: Exact. Este o modalitate grozavă de a obține și feedback, da.

Drew: Bănuiesc că folosirea LaunchDarkly în acest fel, mai degrabă decât utilizarea propriei soluții, este un fel de alt aspect al abordării Jamstack, nu-i așa? Folosește doar un API care vă oferă această funcționalitate fără să vă faceți griji cu privire la modul în care implementați aceasta și cum să o dezvoltați și cum să o mențineți și să o păstrați, astfel încât să o puteți externaliza, spuneți: „Corect, suntem Vom folosi acest API și totul este îngrijit.”

Leslie: Da. Da, exact.

Drew: Așadar, această abordare vă permite să implicați în producție porțiuni mici de noi funcții, dar ele sunt doar ascunse în spatele steagului. Și apoi, când totul este gata de plecare, puteți doar să răsturnați steagul și îl puteți schimba rapid înapoi dacă ceva nu merge bine.

Leslie: Da, exact. Face lansările noastre un pic mai puțin interesante. Cândva, apăsați aceste butoane mari și există tot acest cod care se îmbină și vă urmăriți jurnalele de construcție și este acest moment de anticipare. Și acum ești tu la un apel Zoom, dai clic pe un buton și este live.

Drew: Da. Cred că la ultima lansare a funcției, am lucrat la un Netlify, am folosit această abordare. Și au fost săptămâni de muncă pentru o întreagă echipă de oameni și am primit un apel Zoom pentru a coordona lansarea și toată lumea a confirmat că părțile lor erau gata. Și apoi am răsturnat indicatorul de caracteristică și l-am activat pentru toți utilizatorii și asta a fost tot.

Leslie: Gata.

Drew: Și s-a terminat în câteva minute și a fost cu adevărat anticlimatic.

Leslie: Da, e cam trist.

Drew: Nu erau palme transpirate, nu era nimic, ceea ce bineînțeles este exact ceea ce îți dorești, nu-i așa? Așa știi că ai un proces robust, dacă să pornești ceva pentru toată lumea pur și simplu nu este o mare problemă.

Leslie: Exact. Și dacă trebuie să-l derulați înapoi, din nou, este atât de simplu, este acel clic. Ameliorează o parte din această presiune, anxietate.

Drew: Deci, probabil, vreau să spun, nu toate schimbările vor fi doar schimbări de front-end. Uneori vor avea loc modificări ale backend-ului și, probabil, au propriile semne de caracteristică, de asemenea, în majoritatea sistemelor de backend. Deci, ați menționat și documente. Există vreo modalitate de a coordona toate acestea împreună? Toată lumea își întoarce steagurile în același timp? Sau cum funcționează?

Leslie: Da. Așadar, acesta este un domeniu la care lucrăm în mod activ în cadrul echipelor chiar acum la Netlify, lucrăm la o soluție care ne-ar permite, probabil, să legăm totul de un singur steag în LaunchDarkly, pe care îl folosesc toate sistemele noastre. , toate bazele noastre de cod sunt folosite. Deci, într-o lume ideală, am fi capabili să răsturnăm un steag și să spunem: „Bine, aceasta este comutarea la noul punct final API care este, de asemenea, consumat pe front-end cu această nouă interfață de utilizare care este înfășurată într-un steag de caracteristică, precum și această porțiune a site-ului documentar, care conține informații noi despre această nouă funcție.” Și răsturnați acel steag din el afectează toate aceste depozite. Nu suntem încă acolo. Lucrăm la asta, dar sunt încântat să văd dacă reușim să coordonăm și să funcționăm.

Drew: Netlify, ca serviciu, este foarte mult adaptat șantierelor în acest fel. Munca pe care dumneavoastră și echipa dumneavoastră o faceți folosind produsul a influențat într-adevăr dezvoltarea produsului?

Leslie: Aș spune că cu siguranță da. Toată lumea spune întotdeauna că nu ești utilizatorul tău, ceea ce cred că este adevărat de cele mai multe ori, cu excepția uneori când ești utilizatorul tău. Ceea ce este amuzant la Netlify, deoarece cred că majoritatea oamenilor din echipa de front-end, în special, sunt oameni care au folosit Netlify înainte ca produs. Și cu siguranță, pentru că folosim Netlify pentru a implementa Netlify, ne confruntăm cu aceleași provocări pe care cred că le fac unii dintre utilizatorii noștri. Așa că, în anumite privințe, dacă ne confruntăm cu o problemă, vom încerca să o aducem restului companiei. Vom menționa acest lucru într-un apel de inginerie sau ne vom retrage CTO și vom spune: „Hei, asta este ceva cu care ne luptăm. Există ceva ce am putea integra în produs care ar face acest lucru mai ușor pentru noi și pentru toți utilizatorii noștri care implementează lucruri similare cu cele ale noastre?” Deci, este un fel de poziție unică în care să te afli, dar este distractiv să vezi cum se dezvoltă foaia de parcurs al produsului.

Drew: Cred că probabil că sunt puțini oameni care folosesc Netlify la fel de intens ca Netlify în sine.

Leslie: Da. Da. Cred că este corect. Mă uit la Netlify atât când îl construiesc, cât și când îl instalez, așa că sunt destul de familiarizat cu el.

Drew: Și apoi, în weekend, lucrezi la un proiect secundar și te regăsești din nou în Netlify.

Leslie: Da. Asta este de fapt foarte adevărat. Da. Da. da, întradevăr.

Drew: Aveți exemple de felul în care direcția produsului a fost influențată de munca depusă de echipă?

Leslie: Da. Așadar, am lansat destul de recent un nou tip de tablou de bord de aterizare pentru aplicația pe care o numim The Team Overview. Așadar, când te autentificai la Netlify, ajungeai pe pagina site-ului, care ar fi, practic, o listă lungă a site-urilor tale. Și am vrut să oferim oamenilor o zonă de control al misiunii în care să poată vedea o mulțime de informații importante dintr-o privire, să aibă acces la lucrurile care le vor fi cele mai utile. Și așa, aceasta a fost o nouă caracteristică pe care am construit-o. În iterația inițială, încercăm să-l scoatem rapid, avem un mic card pe acea interfață de utilizare care face link la cele mai recente versiuni ale tale. Îți arată orice construcție din întreaga ta echipă, ar trebui să apară pe acel card.

Leslie: Și la început, de fapt, nu le-am conectat la versiunea... jurnalul de afișare în sine. Așadar, era doar o listă pe care o puteai verifica. Puteți face clic pe pagina de versiuni pentru a obține un fel de vizualizare similară. Dar, de fapt, lucram la ceva în weekend, un site personal și aveam activată această prezentare generală a echipei și am fost enervat pentru că mi-am dat seama că m-am conectat la Netlify și am vrut să verific această construcție care se întâmpla în proiectul meu, și nu puteam să dau clic pe el și să ajung direct la el. A trebuit să dau clic pe pagina de versiuni și apoi să dau din nou. Așa că, a doua zi la serviciu, am intrat și am adăugat acea schimbare și am legat acele versiuni pentru că mă deranja. Așadar, acesta a fost un exemplu de a realiza doar prin utilizarea produsului, că a existat o oportunitate foarte mică de a-l îmbunătăți. Și noi am luat asta.

Leslie: Dar avem și alte exemple. Probabil un pic mai de impact. Una este că am adăugat într-un fel această funcție de detectare a formularelor. Deci, puțin de fond, dacă nu sunteți familiarizat, formularele Netlify este o caracteristică din Netlify care vă permite să construiți un formular frontend. Și Netlify face într-un fel toată munca de backend de gestionare a trimiterilor. Este un fel ca baza de date pentru formularul pe care l-ați construit pe front-end. Înseamnă că nu trebuie să scrieți niciun cod pe server sau o mulțime de JavaScript suplimentar pentru a gestiona trimiterile de formulare. Într-adevăr, orice site pe care l-ați implementat pe Netlify, pe măsură ce construirea dvs. are loc, roboții noștri de compilare analizează HTML-ul site-ului dvs. în momentul implementării pentru a detecta practic dacă aveți un formular Netlify căruia Netlify trebuie să-i acorde atenție și să-l gestioneze. Și această detectare a formularului, botul de compilare îl caută, este activată în mod implicit.

Leslie: Dar asta înseamnă că, după cum vă puteți imagina, asta vă consumă puțin din timpul de construcție, deoarece roboții trebuie să caute acest pas suplimentar. Deci, aplicația Netlify în sine, de fapt, nu o folosim, nu avem niciun formular Netlify în aplicație în acest moment. Deci, acesta este un pas care practic adaugă puțin timpului nostru de construcție, dar nu trebuie neapărat să se întâmple. Deci, Netlify a creat de fapt o nouă caracteristică care permite oricărui utilizator să dezactiveze detectarea formei respective. Ceea ce înseamnă că puteți dezactiva această setare în setările site-ului dvs., roboții de compilare își dau seama că nu trebuie să caute nimic, astfel încât să economisiți puțin timp de procesare suplimentar în versiuni.

Drew: Cred că este grozav în ceea ce privește productivitatea, pentru că lucrurile se termină puțin mai repede.

Leslie: Exact.

Drew: Dar, de asemenea, ca serviciu cu contorizare, vă permite să obțineți mai mult din tipul de alocații pe care le aveți.

Leslie: Da. Exact. Așadar, acesta a fost ceva ce am auzit și de la unii dintre utilizatorii și clienții noștri și a fost ceva ce am observat și noi. A fost: „Ei bine, nu avem nevoie de acest pas suplimentar în propriul nostru produs. Deci, există o modalitate, ceva pe care le-am putea oferi tuturor utilizatorilor noștri pentru a face viața tuturor un pic mai ușoară, pentru a face construirea tuturor un pic mai rapidă dacă nu folosesc această funcție?”

Drew: Există vreun pericol... Adică, spui că nu ești utilizatorul tău, dar cu Netlify ești deseori utilizatorul tău. Există pericolul ca, odată cu intensitatea în care utilizați produsul, să treceți cu vederea tipul de utilizatori care îl folosesc doar foarte ușor și totul ar putea deveni prea complex și prea avansat și să devină foarte greu de obținut a inceput cu?

Leslie: Asta e o întrebare grozavă. De asemenea, ne-am construit cu adevărat funcția de cercetare a utilizatorilor la Netlify și funcția noastră de știință a datelor și cred că, în general, avem mult mai multă încredere în ei decât experiența mea anecdotică de utilizare și implementare a aplicației. Dar cred că toate aceste date se reunesc pentru a ne permite să facem o imagine mai bună despre cine folosește Netlify, cu ce tip de utilizator vorbim? Sunt oameni cu diferite tipuri de nevoi. Avem oameni în echipele noastre inițiale care gestionează bloguri și site-uri personale și avem, de asemenea, întreprinderi uriașe, care lansează mari campanii de marketing și aplicații web mari, nu atât de diferite de Netlify în sine. Așadar, este interesant să vedem cum crește baza de utilizatori și să ne gândim la toate aceste cazuri de utilizare și să ne dăm seama cum îi putem satisface pe toți acești utilizatori. Și, cu siguranță, folosim mai mult din funcționalitatea noastră de cercetare pentru a ne baza pe înțelegerea cine sunt acești utilizatori, nu doar experiența noastră internă.

Drew: Spune-mi, Leslie, despre serviciul de capturi de ecran pe care Netlify îl are? Pentru că mi s-a părut foarte interesant.

Leslie: Da. În UI avem... când implementați un site pe Netlify, în UI, avem o mică captură de ecran care vă arată de obicei cum arată pagina de pornire a site-ului pe care ați simțit-o. De fapt, este amuzant că am adus în discuție acest lucru, pentru că nu cu mult timp în urmă îl ascultam pe Chris Coyier episodul său pe Serverless și vorbea despre modul în care fac capturi de ecran și în CodePen, ceea ce de fapt nu este atât de diferit de modul în care face Netlify. Dar, practic, rulăm Puppeteer pentru a captura acea captură de ecran a site-ului utilizatorului, iar modul în care rulează totul este că este configurat cu o funcție Netlify. Deci, acesta este, din nou, un exemplu în care ne testăm propriul produs. Deci, în esență, folosim acest punct final care este o funcție Netlify în cadrul propriei noastre aplicații pentru a returna adresa URL a acelei imagini a capturii de ecran, pe care apoi să o putem difuza în aplicație.

Drew: Deci, funcțiile Netlify sunt implementarea de către Netlify a unei funcții Serverless, nu-i așa? În cazul în care, practic, aruncați un fișier JavaScript într-un folder desemnat ca parte a sursei dvs. și apoi acesta devine disponibil pentru a fi executat ca funcție cloud.

Leslie: Da, exact.

Drew: Super inteligent, nu-i așa?

Leslie: Da. E genial. This is one of those areas where it really pushes me as a frontend engineer to really be more of this JavaScript or Serverless engineer, and think a little bit more about how you're basically writing like an internal API end point for yourself when you create one of these Serverless functions. So, it's exciting because there's so much you can do, but that can make it a little intimidating also because there's so much you can do.

Drew: I sort of find it funny how it's like… that's seemingly a core piece of functionality for Netlify, displaying images alongside your site of what it looks like, yet, it's just implemented with another Netlify feature. And you wonder how far you go before it all disappears in on itself in a big cloud of smoke.

Leslie: Yeah. Da.

Drew: This sounds like a really nice way to be working, and a very modern way to we're working, but it can't be without its challenges, can it?

Leslie: Absolutely not. I think I've spoken a little bit about what it means sort of as a frontend engineer pushing into sort of some new areas just for me to be thinking about in terms of Serverless and how can we leverage this in the product? I think for me, mastering that sort of back of the frontend side has been an exciting challenge, but certainly there's a lot to learn there. An example of that in our app right now, is that we use Cypress for end-to-end testing of some of the critical flows in our app, and right now we have that set up so that the Cypress end-to-end tests are running on our Deploy Previews in Pull Requests using a GitHub action. So, we use the GitHub action to run those Cyprus tests against the Deploy Previews of the app.

Leslie: Which is really cool, but there's probably a better way to do this than actually using a GitHub action. I actually think that we could use a Netlify Serverless function because those can be triggered on certain events, like a deploy succeeded event. So, there's an opportunity there for us to actually leverage again, Netlify, a little bit more, instead of relying on some of these other tools that maybe we're more familiar with or more comfortable using. So, in terms of challenges, I think it's opening our minds to what this sort of new model of development allows us to do and trying to leverage it.

Drew: Yes, there's so many different ways on there to… with the tooling that's available, to be able to attack a particular problem. At Smashing, we probably shouldn't say there's more than one way to skin a cat.

Leslie: Yikes.

Drew: What's interesting about the workflow as well, is that it's really intensively Git based, which I think suits… it's really developer friendly, isn't it? As a frontend engineer, something that's Git based kind of just feels like home. So, is that all great or are there any problems that come in with that?

Leslie: I think as a developer Git is wonderful. I think in general it solves big, big problems and I'm very happy to have it. But, because we rely on it so heavily and as our internal team has grown as well, you end up having the same problems that Git has when you're talking about Netlify in this workflow, right? So, you end up with a bug on your main branch, yes, it's really easy to roll back the app itself, we talked through what that looks like, and then go in the code and fix it. But what if someone else on your team is working from a broken version of that main branch? Everyone's going to have to rebase, everyone's going to have to communicate, or at least be aware of what happened. And so, it's not so much a Jamstack problem or a Netlify problem, but more of just the age old, how do you coordinate on a team of human beings and how do you use the technology to do that properly?

Drew: And of course, as you add more tools and infrastructure in around what you're doing, then you've got the problem of everything taking a long time to run. I mean, you mentioned Cypress is one thing. I know Cypress is a real headache with the amount of time those end-to-end tests can take to run. Is there other challenges around that growing build time?

Leslie: Yeah, I think that's one of the other things that Jamstack… You're introducing this build time, which for developers is not great. I always try and think about it as what I sort of eat up in that build time, my users are saving in the performance of what they're getting. So, I always try to keep that in mind when I'm frustrated about how long something is taking to build, but certainly I think that's an area of opportunity and a challenge, is figuring out how to keep those build times fast, how to make sure that we can deploy as quickly as possible. Some of it is this sort of tension between wanting to run all your tests, wanting to make sure that you don't deploy a build if a test fails, but at the same time, then you've got to run all those tests.

Leslie: So, it's this constant sort of back and forth between wanting to keep the build times fast, while also making sure that you feel like you're doing your due diligence before you actually deploy something. And we're playing around with some ideas here as well about potentially moving our Cypress tests to be running against production and having some alerting setup that would let us know after the fact, if something had failed. Which is sort of an interesting model, too. So yeah, stay tuned.

Drew: I certainly know that, yes, the dangers of growing build times, just from a developer point of view, from productivity point of view, that if something takes too long to run, you context switch, you start working on something else, and then it just… you lose all the momentum, and maybe you forget to go back and find out whether the build succeeded because you're then so far into the next task.

Leslie: Yeah, definitely.

Drew: So, I guess this isn't the ultimate workflow as it stands at the moment. There must be further we can take it. What sort of opportunities might lie ahead for this way of working?

Leslie: Yeah. So, I think for me, and Netlify in particular, is sort of the thought of collaboration for larger teams. I mean, I know a lot of developers are sort of… have used Netlify for side projects and other things that they're working on, on their own, but thinking about how it can be leveraged on larger teams, like mine. As we get larger and we're growing, more of us are in the app, more of us are using Netlify to deploy our own services, and so everything from even more robust audit logs so that you can go and see who changed this site setting, or who was the last person to deploy something. I think having the ability to organize your sites within your Netlify dashboard, even knowing… assigning someone to a build is sort of an interesting idea to me. Could that be helpful if I knew that my teammate had worked on this build, but then I realized they had to roll it back? And maybe I'm just aware of who's managing that process could be a really useful thing within Netlify itself.

Leslie: And one thing that I've seen sort of thrown around a little bit is perhaps the ability to link to a specific log line in build log. So, for debugging, if you have your build log of your Deploy Preview, and there's an error that got thrown, either from Netlify or from your own code, it'd be nice to be able to link directly to that log line. So, that's sort of a fun, small improvement that I've been thinking about a bit. And that's not even to say we have some new features at Netlify as well, that are pretty exciting. Edge handlers and background functions. I'm still trying to wrap my head around what they all do and exactly how they work, but I know that edge handlers are going to give us the opportunity to do some things with localized content, which could be… have some interesting implications for features we could build in the Netlify app as well.

Drew: Yeah, it's really exciting. I think there are all sorts of people within the Jamstack community who are pushing this the whole thing forward. But I think Netlify, as a service, is one that is really behind it and doing exciting things. And, as I say, I didn't want this to be a big ad for Netlify, but I think you and I both really love the service, so it is exciting to talk about isn't it? If listeners want to get more engaged with learning how to build Jamstack sites or want to get more into this ecosystem, is there a good place to go to learn this stuff?

Leslie: I feel like it's exploding right now. I would certainly point you to the Netlify blog. We try and post some tips and tricks there and announce new features as well. I would give a shout out too, to Learn With Jason. My coworker, Jason Lengstorf does sort of a live stream show, and he does cover… he covers a range of topics, but does some Jamstack specific ones as well. And it's a fun hour of live coding and picking that out. Twitter, I think, is huge, too. So check out Jamstack hashtag.

Drew: Good advice. So, we've been learning all about how Netlify builds Netlify on Netlify. What have you been learning about, Leslie?

Leslie: Oh, that's always a big question. I mentioned Cypress before, we've been working through some of our processes around exactly how we want to run our end-to-end tests, and so I would say that, in general, I've been thinking a lot about that workflow. So, less about the technology itself, but more about what workflows exist for end-to-end testing on the frontend, and what makes sense sort of in this Jamstack model. So, that's been a fun sort of side tangent. And then, on the CSS side of things, we talked a bit about CSS architecture, and I'm starting to get my hands dirty with Tailwind, which has been a fun and exciting and lots to learn and lots of class names to memorize and… Yeah.

Drew: That's exciting stuff. If you, dear listener, would like to hear more from Leslie, you can find her on Twitter where she's @lesliecdubs, and her personal site is leslie.dev. Thanks for joining us today, Leslie, did you have any parting words?

Leslie: Have a great day?