Smashing Podcast Episodio 29 con Leslie Cohn-Wein: come funziona Netlify Dogfood The Jamstack?

In questo episodio, ci chiediamo che aspetto abbia il cibo per cani Jamstack su Netlify. È possibile distribuire un'intera app su una rete CDN? Drew McLellan parla con l'ingegnere del personale di Netlify Leslie Cohn-Wein per scoprirlo.

Mostra note

• Il sito personale di Leslie
• Leslie su Twitter
• Netlizzare

Aggiornamento settimanale

• Un tuffo in React e Three.js usando react-three-fiber
  scritto da Fortune Ikechi
• Migliori pratiche per la progettazione dell'interfaccia utente di e-commerce
  scritto da Suzanne Scacca
• Autenticazione delle app React con Auth0
  scritto da Nefe Emadamerho-Atori
• Dagli esperti: sviluppi globali dell'accessibilità digitale durante COVID-19
  scritto da Robin Christopherson
• Cosa c'è di nuovo in Vue 3?
  scritto da Timi Omoyeni

Trascrizione

Drew McLellan: È una pluripremiata specialista di frontend originaria di Austin, ma ora vive a Dallas, in Texas, per un periodo a New York. Durante quel periodo, lavorando per agenzie, ha costruito siti per clienti, come Nintendo, WorldPride e Jerry Seinfeld. Ora è un ingegnere front-end del personale presso Netlify, dove, tra le altre cose, lavora alla creazione dell'applicazione utilizzata dai clienti per gestire i propri servizi e le proprie implementazioni. Quindi, sappiamo che è un'abile ingegnere di frontend, ma lo sapevi che, quando viveva a New York, ha servito come assistente giudice di cucina per chili per tre anni di seguito. E quello è proprio vero. Miei formidabili amici, vi prego di dare il benvenuto a Leslie Cohn-Wein. Ciao, Leslie. Come stai?

Leslie Cohn-Wein: Sto distruggendo.

Drew: Volevo parlarti oggi di come Netlify in qualche modo mangia il proprio cibo per cani, per usare quell'espressione affascinante, quando si tratta di costruire su Jamstack. Dovrei contestualizzare un po' questo dicendo che fino a pochi mesi fa abbiamo lavorato insieme nello stesso team di Netlify. E quando sono arrivato lì, il processo di sviluppo era davvero estraneo a me, anche dopo 20 anni come sviluppatore. Ho pensato che fosse davvero affascinante e valesse la pena esplorarlo un po', con un pubblico più ampio. Probabilmente dovrei sottolineare che stiamo parlando di questo perché è un caso di studio davvero interessante e non è un grande annuncio sponsorizzato per Netlify. Tutti dovrebbero dare un'occhiata a Vercel. Ma penso che ci siano molte cose preziose che si possono imparare dalla discussione, in particolare dal punto di vista di Jamstack. Perché Netlify è un grande sostenitore dell'approccio Jamstack e il servizio è in qualche modo offerto al cliente ed è costruito attorno all'idea di costruire progetti Jamstack. Ma il servizio è anche costruito utilizzando quei principi stessi. Non è vero?

Leslie: Lo è, sì. Molte persone pensano a quell'architettura Jamstack come a siti statici, ma stiamo davvero cercando di capire cosa significhi creare un'app Jamstack con il frontend di Netlify. Perché è un'app React che è un'app Jamstack completa che distribuiamo Netlify su Netlify quindi... Sì, la stiamo davvero provando e spingendo i limiti di ciò che è possibile.

Drew: Penso che a volte ci sia l'idea che Jamstack sia ottimo solo per i siti statici, come dici tu, e l'aspetto API arriva se vuoi inviare un modulo a un indirizzo e-mail e puoi semplicemente fare qualcosa di semplice come quello, ma tu è possibile creare un'intera app Web in questo modo. Ma lo stai facendo, vero?

Leslie: Sì, assolutamente. La nostra app, parlando in particolare di ciò che vedi se accedi a app.netlify.com, è alimentata da... abbiamo un'API REST interna, ma il frontend, come ho detto, è puro Jamstack. Quindi, abbiamo la nostra fase di creazione, osserviamo l'app mentre viene compilata nell'app e la distribuiamo sul nostro sistema.

Drew: Quindi, quando è coinvolto un processo di back-end e ci sarà sempre una sorta di livello di processi di back-end, sai, dati persistenti o, nel caso di Netlify, che iniziano con una distribuzione o cosa hai, quel back-end semplicemente viene costruito come una serie di API che possono quindi essere consumate dal frontend?

Leslie: Sì, quindi ci sono un paio di modelli diversi di come puoi farlo funzionare. Nella maggior parte dei casi, nella nostra app, utilizziamo il recupero lato client con React, giusto? Quindi, serviamo una sorta di shell statica dell'app e quindi recuperiamo le informazioni dell'utente dalla nostra API REST interna al momento della richiesta. Jamstack è interessante perché ci sono alcune cose che puoi pre-costruire e cerchiamo di fare affidamento su questo quando possiamo. E poi, quando parliamo di alcuni dei dati più dinamici, utilizzeremo il recupero lato client per assicurarci di recuperare i dati più recenti.

Drew: Penso che mi abbia sorpreso, quando ho iniziato a lavorare sull'app, quanto viene raggiunto nel frontend, in particolare quando si tratta di interagire con API esterne e cose. So che quando Netlify interagisce con il tuo provider Git, quindi va su GitHub e ottiene un elenco di elenchi di repository, sta accadendo tutto tra il tuo browser e GitHub. E a parte forse il... passare attraverso una funzione senza server che sta nascondendo alcuni segreti sulla richiesta o qualcosa di leggero come quello, la maggior parte di ciò sta accadendo in un modo tipo Jamstack. Non sta attraversando una sorta di infrastruttura di back-end di base di Netlify. Quindi, è piuttosto affascinante. Questo sta davvero andando molto oltre un semplice sito statico con alcune chiamate API per fare piccole cose. Questa è la vera funzionalità di base, vero, che viene implementata nel browser?

Leslie: Assolutamente. Spinge davvero, penso, quel concetto di cosa sia un ingegnere sviluppatore frontend, giusto? Ed è qualcosa che mi spinge, come ingegnere di frontend, a essere migliore ea pensare di più a questo tipo di... il livello API, che non è qualcosa a cui tradizionalmente sono stato così vicino. Lavoro di più sull'interfaccia utente, sui colori e sui sistemi di progettazione, quindi è davvero... ho scoperto che lavorare su un'app Jamstack su larga scala mi ha spinto a diventare uno sviluppatore migliore.

Drew: Essere uno sviluppatore frontend non significa conoscere i CSS alla rovescia, anche se ne fa parte. Non è conoscere l'HTML in primo piano, ma fa parte di esso. Si sta anche allontanando in questo territorio che era tradizionalmente appannaggio di un ingegnere di back-end, il che è piuttosto interessante. Netlify utilizza il nuovo rendering lato server per-

Leslie: Non che io sappia.

Drew: Quindi, è tutto letteralmente fatto, come dici tu, servi una shell, e poi viene popolata con richieste di ritorno a diversi endpoint API per popolarla tutta.

Leslie: Esattamente.

Drew: E dici che è un'app React?

Lelie: Sì. Sì. Reagire. Usiamo React Redux in questo momento, e in questo momento siamo PostCSS, ma stiamo anche sperimentando la nostra architettura CSS.

Drew: Non lo siamo tutti? Quindi, costruisci l'app in React e poi la distribuisci su Netlify?

Lelie: Sì. Forse la mia parte preferita dell'intero processo è la magia delle anteprime di distribuzione, che otteniamo tramite Netlify. Quindi, quello che succede è che tu... lavorerai in GitHub, aumenterai le tue PR. Quindi, apri il tuo PR in GitHub e questo creerà automaticamente una build della tua anteprima di distribuzione dell'app. Quindi, in realtà utilizziamo le anteprime di distribuzione dell'app stessa per testare, per assicurarci che tutto funzioni come dovrebbe. Eseguiamo i nostri test. Questo è ciò che utilizziamo per verificare manualmente durante la revisione del codice. Quindi, abbiamo una sorta di distribuzione continua configurata direttamente da GitHub.

Leslie: E poi una delle altre cose interessanti che abbiamo impostato è che in realtà abbiamo un paio di diversi siti Netlify che stanno prelevando dallo stesso repository in cui risiede la nostra app. Quindi, abbiamo entrambe le nostre app, abbiamo un'istanza di Storybook che ha una sorta di componenti dell'interfaccia utente per l'app. Quindi, abbiamo sia la nostra app stessa, abbiamo i componenti dell'interfaccia utente di Storybook e abbiamo fondamentalmente un sito Netlify che mostra la nostra interfaccia utente di Storybook. E poi abbiamo anche un terzo sito che esegue un analizzatore di pacchetti webpack. Quindi, è un'interfaccia utente visiva che ti offre una mappa ad albero, la visualizzazione di tutti i bundle di app e possiamo in qualche modo misurarne le dimensioni, ed è solo un promemoria per noi di ricontrollare una specie di. Quando ogni distribuzione dell'app si interrompe, possiamo controllare e assicurarci che non stiamo facendo nulla di strano con le dimensioni del nostro pacchetto lì. Quindi, tutti e tre questi siti vengono generati in una richiesta pull dell'app. Quindi, otterrai collegamenti all'anteprima, essenzialmente le tue anteprime di distribuzione, sia dell'app Storybook che a quel profilo dell'app che possiamo controllare.

Drew: E con le anteprime di distribuzione, questo diventa essenzialmente il tuo ambiente di staging, vero?

Leslie: Esattamente. In realtà non gestiamo un ambiente di staging tradizionale, perché confidiamo davvero che le nostre anteprime di distribuzione siano essenzialmente ciò che verrà attivato quando premiamo il pulsante di unione e avviamo la build ufficiale del nostro ramo principale nella nostra app principale. Quindi, adoro il fatto che possiamo fare affidamento su Deploy Previews come ambiente di gestione temporanea. Confidiamo davvero che corrisponda alla produzione. Lo stiamo costruendo con tutte le variabili di produzione, tutto ciò che... le variabili di ambiente, tutta quella roba viene costruita nell'anteprima di distribuzione. Quindi, è più o meno come una situazione senza preoccupazioni. Finché l'anteprima di distribuzione funziona, sai che anche l'app funzionerà.

Drew: E immagino, come organizzazione, se la tua anteprima di distribuzione non corrisponde a ciò che viene pubblicato, allora questo è un problema di servizio che Netlify vuole risolvere. Quindi, in realtà funziona abbastanza bene da quel punto di vista. Quindi, hai esaminato un'anteprima di distribuzione, tutto sembra fantastico, il PR viene unito. Cosa succede allora?

Leslie: Quindi, poiché Netlify esegue tutta la nostra distribuzione continua, essenzialmente abbiamo collegato tutto in modo che qualsiasi unione nel nostro ramo principale avvii automaticamente una distribuzione di produzione ufficiale con l'app. Quindi, in genere, se sei lo sviluppatore che ha unito le tue PR, entrerai nel vero... devi assicurarti, ricontrolla le tue schede, perché se hai un'anteprima di distribuzione dell'app aperta e l'app, devi assicurarti... di solito vuoi seguirlo nell'app reale. Quindi, devi controllare la tua scheda. Ma sì, nell'app, di solito accedi, puoi guardare i registri di compilazione per quell'unione che hai appena avviato, quindi è tutto automatico. E poi, non appena i registri di compilazione vengono completati e il sito è attivo, tutto ciò che devi fare è aggiornare la finestra del browser e vedrai tutto ciò che hai appena distribuito, dovrebbe essere aggiornato nell'app.

Drew: E diciamo che rilevi un problema una volta che è stato pubblicato, cosa fai allora?

Leslie: Questa è un'ottima domanda. E forse una delle cose che preferisco dell'utilizzo di Netlify anche prima di lavorare in Netlify, è stato un po' di magia per me, perché Netlify ha in qualche modo integrato ciò che chiamiamo rollback. Quindi, essenzialmente ogni distribuzione su Netlify... poiché stiamo usando questa architettura Jamstack, ogni distribuzione è atomica. Quindi, ciò significa che hai questa cronologia completa di ogni tipo di distribuzione che hai mai realizzato su un sito e puoi tornare immediatamente a uno qualsiasi di quelli. Quindi, se distribuiamo accidentalmente un bug o qualcosa non funziona, la prima cosa che facciamo di solito è interrompere effettivamente quell'integrazione continua. Quindi, entreremo ed è solo un pulsante nell'interfaccia utente di Netlify che dici "Interrompi pubblicazione automatica" e ciò che farà è interrompere la connessione con GitHub. Quindi, se improvvisamente anche il mio compagno di squadra sta unendo le sue PR, non reintrodurremo il bug, non accadrà nulla del genere.

Leslie: Quindi, fermiamo tutte quelle implementazioni automatiche. E poi tutto quello che devo fare è tornare all'elenco delle distribuzioni e trovare l'ultima distribuzione funzionante, premere un altro pulsante che dice "Pubblica questo", e va online. Quindi, quello che fa, è che toglie quella pressione per essere in grado di tornare davvero indietro, guardare il codice, capire cosa è realmente successo. A volte ciò significa eseguire un ripristino di Git sul ramo principale e riportare il ramo principale dove doveva essere. E a volte è una soluzione rapida o vai su un ramo e lo fai riparare e non devi nemmeno preoccuparti di tornare in Git. E poi, quando sei pronto per tornare indietro, assicurati che tutto funzioni sulla tua anteprima di distribuzione dell'app e puoi semplicemente ripristinare tutte quelle cose. Quindi, non appena inizi quelle implementazioni automatiche, sei praticamente di nuovo in attività.

Drew: Quindi, ho individuato un problema qui.

Leslie: Uh oh.

Drew: stai usando Netlify per distribuire le modifiche all'app Netlify. Cosa succede se il bug che hai distribuito ti impedisce di tornare indietro? Cosa fai allora?

Leslie: Ho degli incubi. No. In realtà, abbiamo un paio di modi per gestirlo. Pertanto, se interrompiamo l'app e non possiamo utilizzare l'interfaccia utente per eseguire questo processo, le nostre anteprime di distribuzione vengono effettivamente eseguite sulla nostra API di produzione. Quindi, ciò significa che, anche se l'app non funziona, abbiamo ancora quelle distribuzioni atomiche. Quindi, se hai un collegamento da GitHub, forse da un PR vecchio o recente, e hai quell'URL di anteprima di distribuzione, potresti effettivamente accedere all'anteprima di distribuzione dell'app e apportare le modifiche necessarie, tornare indietro e pubblicare una distribuzione precedente dall'Anteprima di distribuzione. E sta ancora raggiungendo la nostra API di produzione, quindi ciò influirà ancora sull'app e quindi verrà ripristinata l'app. È come una specie di emoji cerebrale che esplode lì, ma è un modo per farlo. Potremmo anche pubblicare una distribuzione precedente da alcuni dei nostri sistemi back-end. Potremmo convincere i nostri ingegneri di back-end a pubblicarlo per noi. Oppure puoi sempre usare Git per ripristinare e provare a spingerlo verso l'alto, ma è un po' spaventoso perché non puoi guardare quello che stai facendo.

Drew: Immagino che tu abbia solo bisogno di una mente molto chiara per gestire quella situazione.

Leslie: Sì.

Drew: Ma è totalmente recuperabile, sembra proprio così.

Leslie: Sì. Bene, e una volta che hai pubblicato la tua distribuzione di lavoro, tutta la pressione è svanita. Questa è davvero la parte più bella. E l'ho trovato anche nelle agenzie. Essere in grado di tornare indietro è stato davvero un toccasana per... Ti rende anche meno preoccupato di pubblicare nuove modifiche. Se rompi qualcosa, ci vuole un secondo per farlo tornare indietro, il che si adatta molto bene al tipo di movimento rapido e tira fuori le cose dal modello.

Drew: Sicuramente. Penso che in genere questo tipo di intero flusso di lavoro funzioni meglio quando hai a che fare con modifiche davvero piccole. Voglio dire, idealmente vuoi creare un ramo, implementare una piccola modifica, aumentare un PR e poi riunirlo il più rapidamente possibile. Il che ovviamente funziona bene per modifiche e correzioni di bug e piccole cose, ma non funziona così bene per il lavoro di funzionalità principali quando quella funzionalità potrebbe richiedere settimane o forse anche mesi dall'inizio alla sua implementazione. Come gestisci questo tipo di processo?

Leslie: Sì, è un'ottima domanda. Quindi, di recente abbiamo iniziato a utilizzare un po' di più i flag delle funzionalità. Prima di andare a parlare un po' di più su come lo facciamo, parlerò di quello che facevamo prima. Quindi, prima di utilizzare i flag di funzionalità, penso che tutti abbiano familiarità con l'idea del ramo di funzionalità di lunga durata. Tutti li odiamo, giusto? Ma lavoreremo sui nostri PR più piccoli. Uniremmo ciascuno di questi individualmente, dopo la revisione del codice, in questo ramo di funzionalità più lungo. Quindi, praticamente avresti tutte le tue nuove funzionalità in un unico posto, potresti avere un'anteprima di distribuzione con cui puoi testare quella nuova funzionalità. A volte questo modello richiedeva implementazioni coordinate tra altri team. Quindi, quando eravamo pronti a dire "Ok, questo ramo di funzionalità, siamo pronti per unirlo e renderlo attivo", a volte significava: "Ok, devi assicurarti che il back-end abbia già implementato la modifica", quindi qualunque cosa Il lavoro API che stiamo facendo nella nostra funzione è pronto per l'uso. Se ci sono documenti sul nostro sito di documenti che devono essere pubblicati contemporaneamente alla funzione, devi coordinare e premere i pulsanti contemporaneamente.

Leslie: Questo modello è... ha funzionato per noi, ma hai ragione, forse non era il più fluido. In realtà è piuttosto divertente, il nostro co-fondatore e CEO di Netlify, Matt Biilmann, ha effettivamente lanciato la nostra funzione di analisi utilizzando questo processo sul palco della Jamstack Conf London l'anno scorso. Quindi, ha utilizzato la nostra funzione di distribuzione dei blocchi per prendere fondamentalmente l'anteprima di distribuzione della nuova funzionalità di analisi e pubblicarla dal vivo sul palco. Quindi, è stato abbastanza bello.

Leslie: Ma, come hai detto, è... hai un po' meno di fiducia. Tutto è ancora nascosto in questa Pull Request. Diventa un po' ingombrante. Qualcuno deve approvare quella richiesta pull finale che di solito è piuttosto grande. È un po' opprimente. Quindi, al giorno d'oggi utilizziamo principalmente flag di funzionalità. Utilizziamo un servizio chiamato LaunchDarkly, che ci consente sostanzialmente di racchiudere la nostra nuova interfaccia utente delle funzionalità con questi flag, in modo da poter continuare a unire continuamente il codice, anche se l'interfaccia utente non è qualcosa che vogliamo che i clienti vedano. Quindi, assicurati solo che nell'ambiente di produzione che il tuo flag di funzionalità sia disattivato, possiamo distribuire il codice, unirlo e nessuno... supponendo che tu sia un utente generico, non vedrai quella nuova interfaccia utente.

Drew: Quindi, un flag di funzionalità è fondamentalmente come un interruttore nel codice che dice: "Se questa funzione è abilitata, usa questo nuovo codice, altrimenti usa questo vecchio codice".

Leslie: Esattamente.

Drew: Questo significa che hai una base di codice disordinata con tutti questi fork in atto? Come lo affronti?

Leslie: Sì, penso che sia... chiunque usi i flag delle funzionalità probabilmente è abituato a questo tipo di battaglia su quando ripulisci i flag delle funzionalità? Quanto tempo li lasci lì? Siamo arrivati ​​a circa due settimane dopo il rilascio di una funzionalità importante, abbiamo dei promemoria. Fortunatamente, LaunchDarkly ha recentemente impostato una funzione che avviserà Slack. Quindi, puoi collegarlo a Slack e ti dirà semplicemente: "Ehi, il tuo flag per il lungometraggio è stato... Sei stato in produzione dal vivo per due settimane. È giunto il momento di assicurarti di ripulire la tua bandiera nel codice. "

Leslie: Quindi, proviamo a ripulirlo abbastanza velocemente, ma è, in quel lasso di tempo, che è bello sapere che la bandiera è ancora lì. Anche se hai rilasciato la funzione, significa che di nuovo, con un clic, puoi entrare e disattivare quel flag se c'è un bug, se c'è qualcosa che si apre. Quindi, ci piace lasciarli dentro per un po', proprio mentre la funzione è davvero in cottura, mentre le persone si stanno abituando, per assicurarci che non ci siano problemi importanti. Ma poi proviamo a tornare nel codice ed è un po' di pulizia, quindi non è un processo ideale, ma di solito la rimozione del flag non richiede molto tempo, stai solo eliminando un paio di righe di codice.

Drew: Quindi, suppongo che l'approccio più semplice all'implementazione di un flag di funzionalità potrebbe essere semplicemente una... come una variabile di configurazione nella tua app che dice "Questa funzione è attiva o disattiva", ma poi tu, hai bisogno di un modo per assicurarti che è acceso per le persone giuste e spento per le persone giuste. E immagino che sia qui che entra in gioco un servizio come LaunchDarkly, perché ci vuole questo... Voglio dire, ci vuole fondamentalmente ciò che sta accendendo e spegnendo una variabile a un livello estremo, vero?

Lelie: Sì. Sì. È proprio così. Quindi, ci sono modi in cui potremmo, anche senza LaunchDarkly, in pratica impostare noi stessi una variabile di configurazione che in qualche modo gestiamo da parte nostra. Una delle cose che amo di LaunchDarkly è che ci sono diversi ambienti. Quindi, ciò che possiamo fare è essenzialmente attivare un flag di funzionalità per le nostre anteprime di distribuzione. Quindi, chiunque stia visualizzando internamente su Netlify, un'anteprima di distribuzione dell'app può avere accesso alla nuova funzionalità, può testarla, ma poi di nuovo, non appena entra in produzione, quel flag è disattivato. Quindi, c'è davvero poco... di nuovo, devi controllare la tua scheda e assicurarti di essere consapevole del segmento in cui ti trovi, perché non vuoi sorprenderti e pensare di aver lanciato qualcosa che non l'hai fatto, devi stare un po' attento lì. Ma, in generale, funziona abbastanza bene e LaunchDarkly ti consente anche di eseguire queste implementazioni selettive. Quindi, puoi implementare una funzionalità in una certa percentuale della tua base di codice o in un segmento di utenti specifico, persone con un tipo specifico di piano o un tipo specifico di utente. Quindi, ti consente molto più controllo su chi stai rilasciando.

Drew: Sì. Questo può essere davvero potente, immagino, in particolare con nuove funzionalità o funzionalità che potresti aspettarti per risolvere un problema. Forse stai migliorando una funzionalità per renderla più comprensibile, puoi magari provarla con il 10% degli utenti e vedere se stanno riscontrando gli stessi problemi e...

Leslie: Esattamente. È anche un ottimo modo per ricevere feedback, sì.

Drew: Immagino che usare LaunchDarkly in questo modo, invece di lanciare la propria soluzione, sia un altro aspetto dell'approccio Jamstack, vero? Sta solo usando un'API che ti offre questa funzionalità senza doversi preoccupare di come implementarla e come svilupparla e come mantenerla e mantenerla in modo da poterla semplicemente esternalizzare, dì: "Bene, siamo utilizzerà questa API e tutto il resto sarà risolto."

Leslie: Sì. Sì, esatto.

Drew: Quindi, questo approccio ti consente di impegnare essenzialmente piccole parti di nuove funzionalità nella produzione, ma sono semplicemente nascoste dietro la bandiera. E poi, quando tutto è pronto, puoi semplicemente capovolgere la bandiera e puoi ripristinarla rapidamente se qualcosa va storto.

Leslie: Sì, esatto. Rende i nostri lanci un po' meno eccitanti. Una volta premevi questi grandi pulsanti e c'è tutto questo codice che viene unito e stai guardando i tuoi registri di build ed è questo momento di anticipazione. E ora sei tu che salti su una chiamata Zoom, fai clic su un pulsante ed è live.

Drew: Sì. Penso che l'ultimo lancio di funzionalità, ho lavorato su un Netlify, abbiamo usato questo approccio. E sono state settimane di lavoro per un intero team di persone, abbiamo ricevuto una chiamata Zoom per coordinare il rilascio e tutti hanno confermato che le loro parti erano pronte. E poi ho capovolto il flag della funzione e l'ho attivato per tutti gli utenti, e basta.

Leslie: Fatto.

Drew: Ed è finita in pochi minuti ed è stato davvero deludente.

Leslie: Sì, è un po' triste.

Drew: Non c'erano palmi sudati, non c'era niente, che ovviamente è esattamente quello che vuoi, vero? È così che sai di avere un processo solido, se accendere qualcosa per tutti non è un grosso problema.

Leslie: Esattamente. E se devi ripristinarlo, di nuovo, è così semplice, è un clic. Allevia un po' di quella pressione, l'ansia.

Drew: Quindi, presumibilmente, voglio dire, non tutti i cambiamenti saranno solo cambiamenti di frontend. A volte ci saranno modifiche al back-end e presumibilmente hanno i propri flag di funzionalità anche nella maggior parte dei sistemi di back-end. Quindi, hai menzionato anche i documenti. C'è un modo per coordinare tutto questo insieme? Tutti lanciano le loro bandiere allo stesso tempo? O come funziona?

Leslie: Sì. Quindi, questa è un'area su cui stiamo lavorando attivamente tra i team in questo momento in Netlify, stiamo lavorando per una soluzione che ci permetterebbe forse di legare tutto a un singolo flag in LaunchDarkly, che tutti i nostri sistemi stanno utilizzando , vengono utilizzate tutte le nostre basi di codice. Quindi, in un mondo ideale, saremmo in grado di capovolgere una bandiera e dire: "Ok, questo è attivare il nuovo punto finale dell'API che viene consumato anche sul frontend con questa nuova interfaccia utente che è racchiusa in un flag di funzionalità, così come questa parte del sito di documentazione, che contiene nuove informazioni su questa nuova funzionalità. E capovolgi quella bandiera che ha un impatto su tutti quei repository. Non siamo ancora arrivati. Ci stiamo lavorando, ma sono entusiasta di vedere se saremo in grado di ottenere tutto ciò coordinato e funzionante.

Drew: Netlify, come servizio, è molto simile a quello dei cantieri in questo modo. Il lavoro che tu e il tuo team state facendo utilizzando il prodotto, ha effettivamente influenzato lo sviluppo del prodotto?

Leslie: Direi che lo fa sicuramente. Tutti dicono sempre che non sei il tuo utente, il che penso sia vero per la maggior parte del tempo, tranne a volte quando sei il tuo utente. Il che è divertente in Netlify perché penso che la maggior parte delle persone nel team di frontend in particolare siano persone che hanno già utilizzato Netlify come prodotto. E certamente poiché stiamo usando Netlify per distribuire Netlify, ci imbattiamo nelle stesse sfide che penso facciano alcuni dei nostri utenti. Quindi, in un certo senso, se incontriamo un problema, cercheremo di portarlo al resto dell'azienda. Ne parleremo in una chiamata di ingegneria o inseriamo il nostro CTO e diremo: "Ehi, questo è qualcosa con cui stiamo lottando. C'è qualcosa che potremmo integrare nel prodotto che lo renda più facile per noi e per tutti i nostri utenti che stanno implementando cose simili a noi?" Quindi, è una posizione unica in cui trovarsi, ma è divertente vedere come viene sviluppata la roadmap del prodotto.

Drew: Immagino che probabilmente ci siano poche persone là fuori che usano Netlify così intensamente come fa Netlify stesso.

Leslie: Sì. Sì. Penso che sia giusto. Fisso Netlify sia quando lo costruisco che quando lo distribuisco, quindi ne ho abbastanza familiarità.

Drew: E poi durante il fine settimana lavori su un progetto parallelo e ti ritrovi di nuovo in Netlify.

Leslie: Sì. In realtà è molto vero. Sì. Sì. si Certamente.

Drew: Hai qualche esempio di come la direzione del prodotto sia stata influenzata dal lavoro svolto dal team?

Leslie: Sì. Quindi, abbiamo recentemente lanciato un nuovo tipo di dashboard di atterraggio per l'app che chiamiamo Panoramica del team. Quindi, quando accedevi a Netlify arrivavi sulla pagina del sito, che sarebbe fondamentalmente solo un lungo elenco dei tuoi siti. E volevamo dare alle persone un po' più di un'area di controllo della missione in cui possono vedere molte informazioni importanti a colpo d'occhio, avere accesso a cose che saranno loro più utili. E quindi, questa è stata una nuova funzionalità che abbiamo creato. Nell'iterazione iniziale, stiamo cercando di farlo uscire rapidamente, abbiamo una piccola scheda sull'interfaccia utente che si collega alle tue ultime build. Ti mostra qualsiasi build in tutta la tua squadra, dovrebbe apparire in quella carta.

Leslie: E all'inizio, in realtà non li avevamo collegati alla build... il log del display stesso. Quindi, era solo un elenco in cui potevi controllarlo. Puoi fare clic nella pagina delle build per ottenere una sorta di vista simile. Ma in realtà stavo lavorando a qualcosa durante il fine settimana, un sito personale, e avevo attivato questa panoramica del team ed ero infastidito perché mi sono reso conto di aver effettuato l'accesso a Netlify e volevo andare a dare un'occhiata a questa build che stava accadendo al mio progetto, e non potevo semplicemente fare clic su di esso e arrivarci direttamente. Ho dovuto fare clic nella pagina delle build e quindi fare nuovamente clic. Quindi, il giorno successivo al lavoro, sono entrato e ho aggiunto quella modifica e ho collegato quelle build perché mi dava fastidio. Quindi, questo è stato un esempio di come ci si rendesse conto semplicemente usando il prodotto che c'era una piccolissima opportunità per migliorarlo. E l'abbiamo preso.

Leslie: Ma abbiamo anche altri esempi. Probabilmente un po' più d'impatto. Uno è che abbiamo aggiunto questa funzione di rilevamento dei moduli. Quindi, un po' di background, se non hai familiarità, Netlify Forms è una funzionalità di Netlify che ti consente di creare un modulo frontend. E Netlify fa quasi tutto il lavoro di back-end per la gestione degli invii. È un po' come il tuo database per il tuo modulo che hai costruito sul tuo frontend. Significa che non devi scrivere alcun codice lato server o un sacco di JavaScript extra per gestire gli invii dei moduli. In realtà qualsiasi sito che hai distribuito su Netlify, mentre la tua build sta avvenendo, i nostri bot di build stanno analizzando l'HTML del tuo sito al momento della distribuzione per rilevare sostanzialmente se hai un modulo Netlify a cui Netlify deve prestare attenzione e gestire. E questo rilevamento dei moduli, che il bot di build lo sta cercando, è abilitato per impostazione predefinita.

Leslie: Ma ciò significa che, come puoi immaginare, consuma un po' del tuo tempo di costruzione perché i robot devono andare a cercare questo passaggio in più. Quindi, l'app Netlify stessa, in realtà, non stiamo usando, non abbiamo alcun modulo Netlify sull'app in questo momento. Quindi, questo è un passaggio che fondamentalmente sta aggiungendo un po' al nostro tempo di costruzione, ma non è necessario che avvenga. Quindi, Netlify ha effettivamente creato una nuova funzionalità che consente a qualsiasi utente di disabilitare il rilevamento dei moduli. Ciò significa che puoi disattivare questa impostazione nelle impostazioni del tuo sito, i robot di build si rendono conto che non c'è nulla che devono cercare, quindi risparmi un po 'di tempo di elaborazione extra nelle build.

Drew: Immagino che sia fantastico in termini di produttività, perché le cose si completano un po' più velocemente.

Leslie: Esattamente.

Drew: Ma anche, come servizio misurato, ti consente di ottenere di più dal tipo di indennità che hai.

Leslie: Sì. Esattamente. E quindi, questo è stato qualcosa che abbiamo sentito anche da alcuni dei nostri utenti e clienti, ed è stato anche qualcosa che abbiamo notato. Era: "Beh, non abbiamo bisogno di questo passaggio in più nel nostro prodotto. Quindi, c'è un modo, qualcosa che potremmo dare a tutti i nostri utenti per rendere la vita di tutti un po' più semplice, rendere la costruzione di tutti un po' più veloce se non usano questa funzione?"

Drew: C'è un pericolo... Voglio dire, dici che non sei il tuo utente, ma con Netlify spesso sei il tuo utente. C'è il pericolo che, con l'intensità con cui si utilizza il prodotto, si possa trascurare il tipo di utenti che lo utilizzano solo in modo molto leggero e tutto potrebbe diventare troppo complesso e troppo avanzato, e diventerebbe molto difficile da ottenere iniziato con?

Leslie: Questa è un'ottima domanda. Abbiamo anche sviluppato la nostra funzione di ricerca degli utenti su Netlify e la nostra funzione di scienza dei dati e penso che nel complesso ci fidiamo di loro molto più della mia esperienza aneddotica nell'utilizzo e nella distribuzione dell'app. Ma penso che tutti questi dati si uniscano per permetterci di avere un quadro migliore di chi sta usando Netlify, con che tipo di utente stiamo parlando? Ci sono persone con diversi tipi di bisogni. Abbiamo persone nei nostri team iniziali che gestiscono blog e siti personali, e abbiamo anche grandi aziende, che stanno lanciando grandi campagne di marketing e grandi app Web, non così dissimili da Netlify stesso. Quindi, è emozionante vedere crescere la base di utenti e pensare a tutti questi casi d'uso e capire come possiamo soddisfare tutti quegli utenti. E certamente utilizzando più delle nostre funzionalità di ricerca per basarsi sulla comprensione di chi sono quegli utenti, non solo della nostra esperienza interna.

Drew: Mi parli, Leslie, del servizio di screenshot che Netlify ha in atto? Perché l'ho trovato davvero interessante.

Leslie: Sì. Nell'interfaccia utente abbiamo... quando distribuisci un sito su Netlify, nell'interfaccia utente, abbiamo un piccolo screenshot che ti mostra in genere come appare la home page del sito che ritieni. In realtà è divertente che ne abbiamo parlato, perché stavo ascoltando il suo episodio su Serverless di Chris Coyier non molto tempo fa, e stava parlando di come fanno gli screenshot anche in CodePen, che in realtà non è così dissimile da come lo fa Netlify. Ma fondamentalmente eseguiamo Puppeteer per catturare quello screenshot del sito dell'utente, e il modo in cui viene eseguito è che è impostato con una funzione Netlify. Quindi, questo è ancora una volta, un esempio di come alimentiamo il nostro stesso prodotto. Quindi, essenzialmente utilizziamo questo punto finale che è una funzione Netlify all'interno della nostra app per restituire l'URL di quell'immagine dello screenshot, che quindi possiamo servirlo nell'app.

Drew: Quindi le funzioni Netlify sono l'implementazione di Netlify di una funzione Serverless, vero? Dove fondamentalmente rilasci un file JavaScript in una cartella designata come parte della tua fonte, e quindi diventa disponibile per essere eseguito come funzione cloud.

Leslie: Sì, esattamente.

Drew: Super intelligente, vero?

Leslie: Sì. È brillante. 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. Sì.

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?