Bene e benvenuti su Gitbar, nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori.

Oggi sono solo, salvo aggiunte all'ultimo momento, non ho nessuno degli ammutinati che viene a farmi compagnia, però ho un ospite, un super ospite, dovete resistere ancora qualche secondo e ve lo svelo.

Indovinate un po' perché qualche secondo? Beh, qualche secondo perché in realtà vi devo ricordare i nostri contatti info-gitbar.it, at BrainRepo su Twitter, ma soprattutto, anche se ma soprattutto non si dice, il nostro gruppo Telegram.

Mi raccomando, iscrivetevi, siamo sempre di più, tra l'altro visto che oggi abbiamo avuto qualche nuovo arrivo tra i quali è venuto a trovarci il nostro amico Luca Mezzalira, anche lui si è unito ai bevitori di Gitbar e nulla, quindi se non vi siete ancora iscritti, perché io so che molti di voi non si sono ancora iscritti, mi raccomando, fatelo, fatelo, ci trovate direttamente nel vostro client, Telegram preferito, cercando semplicemente Gitbar.

Però detto questo, ricordate i contatti, io direi che è arrivato il momento di iniziare.

Benvenuti su Gitbar, il podcast dedicato al mondo dei full stack developer, i mezzo artigiani, i mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.

Bene, bene, bene, oggi sono super felice di presentarvi il nostro ospite, direttore, director della Dev Experience per NX DevTools e anche un Google Developer Expert, un istruttore su Egghead, fa un sacco di cose, abbiamo con noi Yuri, ciao! Ciao, ciao! Come va? Bene, bene, grazie, sono contento di essere su questo podcast.

Fai un botto di cose, mamma, come fai? Sì, ultimamente c'è tanta roba, abbiamo tanta roba da pubblicare, tanto contenuto da creare, c'è tanta richiesta anche, c'è anche nuova, tante nuove idee, siccome la gente ci contatta, ce ne parla, specialmente oggi magari parliamo un po' anche di Monorepo, questo crea un loop continuo di cose da produrre in senso di contenuti e di...

perciò sì, tanto lavoro.

Ti voglio subito fare una domanda a bruciapelo, qual è il ruolo effettivo, proprio fattivo di direttore della Dev Experience? Sì, è molto simile al DevRel in teoria, al Developer Relations, praticamente io quando ho iniziato da Nowall, o mai già quasi tre anni fa, sono entrato come engineer, come software architect, ho fatto consulenza con clienti e dopo un po', siccome siamo diventati più famosi, più famosi, abbiamo avuto bisogno di qualcuno che si occupa prevalentemente solo di interfacciarsi con i sviluppatori, che alla fine per noi sono i clienti, se vuoi.

E perciò il mio ruolo al momento a Nowall è di organizzare tutta sta roba, di produrre contenuto anche, e quando siamo, insomma, diventati più grandi, più grandi, magari aggiungeremo anche altri DevRel in futuro, altre persone anche per il marketing, così via, perciò il mio ruolo come direttore in quel senso è un po' di supervisionare tutta sta cosa e di entrare in questi discorsi.

Però sì, alla fine sono l'interfaccia al momento tra il nostro team di sviluppatori e il mondo esterno di sviluppatori che utilizzano i nostri prodotti.

Quanto in realtà nel tuo lavoro c'entra il marketing e soprattutto come fai a non venire rapito dal mondo super veloce e talvolta, lo dico, siamo soli, anche un po' finto del marketing? Sì, assolutamente.

Sì, diciamo, quello dipende sempre dalla struttura dell'organizzazione anche.

Io, secondo me, sono fortunato siccome io coordino anche il marketing.

Abbiamo delle persone che si occupano solamente del marketing, cioè puro marketing, non developer relations, però nel nostro caso, diciamo, il DevRel è al di sopra, se vuoi, è la cosa principale sulla quale stiamo operando, mentre in certe organizzazioni è viceversa, cioè nel marketing è al top e poi sotto c'è il developer relations e altre ripartizioni.

E il problema è che il developer relations è molto diverso dal marketing.

Cioè noi sviluppatori sappiamo tutti, non vogliamo che gli addi vengano buttati su di noi, cioè che qualcuno c'è che cerca di venderci qualcosa.

Quello è la cosa che odi come sviluppatore e siccome sono sviluppatore anche io, insomma, capisco questa cosa.

Perciò è sempre un avanti e indietro tra se con chi parli è uno sviluppatore o se con chi parli è piuttosto la ditta o il manager all'interno della ditta.

Perché appena che tu parli con il manager all'interno della ditta diventa più marketing, o anche se crei il sito di entry, praticamente di iNX, per esempio, lì ovviamente diventa più marketing, i messaggi sono molto più raffinati in questo senso.

Ma tutto il resto è come se adesso parlo con te o parlo con un altro sviluppatore su conferenze, tutto quello è different.

Lì non cerco di vendere qualcosa, anche perché poi i nostri prodotti sono open source.

Tra l'altro un ragionamento che facevo con un amico è che alla fine vendere prodotti open source suona già una contraddizione in termini, però è maledettamente più difficile che vendere prodotti a pagamento, perché devi essere veramente convincente da far percepire il valore ma non dire «Allora perché è gratis? Allora perché è aperto se non hanno niente di così tanto valevole da mostrare?» Adesso sembra assurdo sentito da me e te che comunque ci viviamo nell'open source e talvolta mangiamo di open source, però ci sono delle altre situazioni dove questa cosa è nascosta.

In questo periodo amo ripetere questa cosa, la sto ripetendo come mantra.

C'è un bellissimo libro che tra l'altro ho qua accanto a me sulle developer relations, che è questo, ve lo metto nelle note dell'episodio, è developer relations how to build and grow a successful developer program, che dice una cosa importantissima, che gli sviluppatori non vogliono comprare un prodotto, adottare un prodotto, lo dicevamo la settimana scorsa con Francesco parlando di backstage, di Spotify, ma vogliono cocreare con qualcuno.

Esatto, vogliono essere coinvolti nel processo.

Cioè se io uso NX, NX non mi sta vendendo per quanto gratis un prodotto, Narval non mi sta vendendo un prodotto, ma sta cocreando con me.

E a quel punto i ruoli si cambiano e l'importanza e la salubrità, mi farebbe da dire così, della relazione è molto migliore.

E questa cosa spesso vedo che conflige con la visione del marketing vecchio stampo, il marketing classico.

Allora la mia domanda è, come si costruisce da DevRel e chi si occupa di developer experience una comunicazione profittevole col marketing? Una comunicazione costruttiva col marketing? Nel mio caso io sono capo del marketing, perciò riesco a dirigere un po' la direzione.

Tra quello dicevo non sono fortunato, no ma scherzi a parte, nel senso secondo me è sempre una specie di, cioè non è una linea fissa, non è un taglio fisso tra uno e l'altro, come dicevo prima, dipende molto di chi hai davanti.

E questo rende anche molto più difficile nel senso come tu mandi il messaggio.

Perché per esempio se io parlo adesso con te, o faccio un talk, una conferenza, o scrivo un tweet su Twitter, o creo un video su Twitter, o una roba così, cioè lì tutta la voce è molto molto diversa, ma con la stessa voce non posso parlare se una ditta mi chiama e dice, ma questa è una presentazione interna di Anix per esempio, di Monorepo.

Lì devi poi trovare l'equilibrio tra, ok, vendo il prodotto, nel senso di faccio anche vedere un paio di slide, com'è veloce, com'è potente, quanti download ne abbiamo, che magari uno sviluppatore sia interessato, sia no, marginalmente ma sì, c'è un'altra parte ovviamente che viene caricato non so quanti milioni di volte, però io sono più interessato a quello che mi aiuta nel mio lavoro in questo momento.

Perciò è una linea molto, non è una linea proprio fissa, cioè va un po' avanti e indietro e devi aggiustarti un po' come con chi parli, che rende difficile il lavoro in certi momenti.

Però come detto, nel nostro caso noi siamo cresciuti partendo dal DevRel.

Nel senso, siccome facciamo, siccome Nowall fa anche consulenza, abbiamo il marketing per la consulenza, che vende tanti aspetti, ovviamente come siamo esperti nel Monorepo, come abbiamo anche conoscenze dettagliate in React, Value-ad-Angle, quelle cose lì.

Ma la cosa sulla quale ci stiamo basando tantissimo è più il DevRel, cioè il DevRel Developer Experience, tutte queste cose che si interfacciano direttamente con lo sviluppatore.

Perché il punto è, essendo un tool di sviluppo, il cliente principale è lo sviluppatore.

C'è il 90% dei casi com'è che una ditta inizia a utilizzare Next, per esempio.

C'è uno sviluppatore che dice, ma guarda è una bella cosa, l'ho provato anche magari dopo il lavoro, sul mio progettino piccolo, mio personale, ho giocato un po', mi piace un sacco, voglio utilizzarlo tutto il giorno al lavoro.

E così parte la storia, ma è questo sviluppatore, parla con un altro, si mettono insieme, fanno una demo interna e poi dopo solo arriva il marketing talk perché ti chiama il manager e ti dice, beh, com'è questa cosa, com'è il supporto, come possiamo, ci fate consulenza, non ci fate consulenza, potete aiutarci, in quel senso.

Perciò noi ci basiamo tantissimo su questo aspetto di Developer Relations, perché tutto parte un po' da lì.

Assolutamente sì, ed è la leva che fa lo sviluppatore e l'architetto, lo sviluppatore attraverso i legami con l'architetto, poi c'è un passaparola nell'ambito tecnico che fa una certa pressione nell'ufficio acquisti, si fanno tutte le famose rompiscatoli di assessment per capire se si può utilizzare o meno, chi vive nell'ambito enterprise probabilmente queste cose le conosce.

Hai parlato di consulenza, no? E di open source, perché Narwal, sapi che io storpierò il nome della tua azienda lungo tutto l'episodio perché non sono in grado di declinare bene i nomi, gli ascoltatori lo sanno, ma l'italianizzo praticamente tutto pur vivendo in inglese, ma Narwal deve tenere un equilibrio tra consulenza e sviluppo di un prodotto open source.

Come si tiene questo tipo di equilibrio dal tuo punto di vista? Ci sono delle difficoltà che vengono proprio dal bilanciare questi due pesi, che se giustamente bilanciati diventano un amplificatore economico importante, però la ricetta non è poi così semplice.

No, assolutamente, non è sempre facile.

C'è un pro e un contra, una parte difficile e una parte che è molto pro, nel senso di facilità delle cose.

Nel nostro caso è un po' emerso come la strategia della ditta funziona.

Quando Jeff e Victor Lawson sono ex Googler, facevano parte del team di Angola, poi hanno creato Narwal come ditta di consulenza di Angola, principalmente.

Avevano sempre già l'idea di avere questo...

Siccome hanno vissuto l'episodio di Monorepo all'interno di Google, hanno visto il beneficio, perché lo vuoi utilizzare, però anche la complessità.

Avevano sempre in testa di creare quel tool anche per il mondo open source, al di fuori di Google, che funziona però bene e che è facile ad adottare.

Perché Google ha, come tanti sanno, il Bazel, che è l'equivalente di quello che hanno internamente, più o meno.

Il problema è che Bazel non è facile.

Se hai una ditta grande, hai un team dedicato di tecnici che ti mantiene solo quello, puoi utilizzarlo, e tanti lo fanno anche.

Però l'idea loro è sempre di creare qualcosa di facile da utilizzare all'open source.

E all'open source specifico perché tutti e due amano l'open source.

Non solo l'open source, ma anche già prima loro lavoravano in ambiti dove utilizzavano fortemente l'open source, perciò quello era sempre una componente core.

Come partito per on our, siccome se vuoi creare un business devi guadagnare soldi, devi pagare i tuoi dipendenti.

Sì, ma...

Esatto, e principalmente il consulting era quello che facevano.

Con quello partiva il business, non c'era nessun funding esterno, niente, ma la consulenza era la cosa principale.

Quello però che facciamo, che facciamo ancora fino ad oggi, è che la parte open source è il 20% del lavoro, più o meno.

Noi diciamo sempre l'80-20, cioè 80% consulting, 20% lavoro open source, perché poi varia, la media nell'anno varia perché magari per un mese non hai un cliente o sei offline, in senso allora lavori full time open source.

Perciò questo è un po' l'equilibrio.

Alla fine probabilmente sarà più 70-30, una roba così.

Però vuol dire che sì, tanti di noi fanno consulenza a un cliente utilizzando maggiormente o quasi sempre Enix, Enix per lo sviluppo praticamente, e le idee, le difficoltà che vediamo che magari ci rendono difficile il lavoro con questo cliente perché c'è qualche problema che Enix non supporta bene, viene portato poi di nuovo nel prodotto open source in questi 20-30% di tempo nella settimana.

E così praticamente attualmente è, diciamo, quell'equilibrio che facciamo.

Non è facile, come puoi immaginare.

Cioè la parte pro è che per me specialmente era che magari durante la settimana lavori in quel progetto di consulenza, non è sempre super interessante, nel senso tante volte sì, dai una mano di fare il setup di qualche cosa, poi però hai il lavoro open source, magari giovedì-venerdì o venerdì solo, dove praticamente puoi un po' liberarti e lavorare su Enix o queste cose.

E dall'altra parte una cosa però che è molto pro è anche il fatto di vedere i problemi che ci sono.

Perché un problema è che quando tu sviluppi un dev tool lo sviluppi per il sviluppatore.

Il problema è se sviluppi solo un dev tool e quindi tantissime esperienze, lo vedi applicato in modo giornaliero direttamente, diciamo su progetti grandi anche, è difficile vedere praticamente dove sono ancora i problemi, dove magari deve essere aggiustato qualcosa in questo senso nel prodotto open source.

Perciò questo equilibrio è anche al vantaggio e che riusciamo a portarci dentro anche l'esperienza di lavorare con questi edit e vedere dove è una funzione e dove non funziona.

Io vengo da una società con l'approccio simile e quindi riconosco benissimo questa cosa.

E tra l'altro ci tengo ad aggiungere una cosa.

Nel momento in cui tu tieni un prodotto di questo tipo, di questa portata, un dev tool, e lo tieni in casa, tu diventi, adesso passatemi il termine, lo so che non si dovrebbe dire, ma il massimo esperto di quel dev tool.

Questa cosa ti crea un mercato di quella consulenza sana, quella consulenza buona dove tu sei la chiapa fantasmi o il consulente che arriva, capisce la situazione, genera valore e non si addormenta all'interno dell'ecosistema del cliente facendo il mero e sporco e bruttissimo body rental.

Quindi queste sono le dinamiche che si vanno a generare.

Infatti il nostro approccio di consulenza è anche cambiato negli anni.

Quando si partiva con Nowall e anche quando io ho iniziato a lavorare con loro inizialmente, la parte di consulenza spesso era anche lo sviluppo di feature con Angola, con React, quello che era.

Tu eri proprio una specie di body rental in quel senso.

Tu lavoravi e sviluppavi feature.

Adesso, siccome Next è diventato molto più famoso, molto più utilizzato, si cambia pian pianino anche il tipo di consulenza dove facciamo meno sviluppo di feature, ma veniamo proprio a chiamarti come esperti di abbiamo un monorepo, questa è la situazione, sappiamo che voi siete gli esperti di monorepo, avete anche Next, venite, dateci una mano a metterlo su.

Perciò diventa un lavoro molto più, anche challenging, nel senso tu entri in una ditta, vedi una situazione esistente, cerca di dargli una mano e di magari mettere a Next quello che è e trasformare praticamente il loro mondo di lavorare verso la direzione monorepo proprio.

Ma è proprio il lavoro che vorresti anche fare, perché è quello che ti motiva di più.

Esatto, ovviamente sei esperto anche in altri ambiti, però questo è il focus dove vorresti arrivare alla fine.

Sì, poi anche lo sviluppare feature lo puoi fare in stile body rental, oppure arrivare là perché hai due o tre figure che sai che deliverano, che fanno delivery e quindi entri in un team portando della forza di consulenza che genera veramente valore.

Questo è il tipo di approccio che un'azienda sana di consulenza secondo me dovrebbe avere.

Ma potremmo rimanere ore a parlare di questa cosa.

Invece io voglio arrivare a parlare di NX.

Ti voglio fare una domanda un po' da gnubo.

La mia domanda è cosa fa NX a tutti gli effetti in soldoni? Per un developer perché dovrebbe adottare NX nel suo contesto? Quando parliamo di NX normalmente dobbiamo anche mettere il discorso monorepo.

Non necessariamente, possiamo entrare anche un po' al merito di questa cosa, però NX praticamente è conosciuto per funzionare bene nei monorepo ed è quello che lo fa bene.

Poi ci sono diversi casi, nel senso NX, quello che vogliamo noi raggiungere con NX che abbiamo lavorato molto, specialmente in quest'anno, è che si adatta alla tua situazione.

Funziona bene nel caso quando tu magari hai già un monorepo, magari con PNPM Workspaces o NPM Workspace, che adesso ormai i package manager hanno già una specie di monorepo built in.

Infatti spesso vediamo tanti clienti che sono partiti con quello, che va benissimo, hanno lavorato magari anche un paio di anni con questo, adesso sono nel momento dove diventa troppo grande, hanno dei problemi, magari ha problemi di performance, di build, così via, e cercano di una soluzione.

E perciò lì è una modalità dove potresti dire, bene, prendo NX, e NX cosa fa in questo momento? È far sì che i tuoi build, i tuoi test, su un ambito più largo di un monorepo, funzionino perfumante.

Magari dobbiamo dire cos'è un monorepo? A livello molto alto, non è niente che, invece di avere un progetto per repository, hai più progetti in un unico repository.

Normalmente sono progetti correlati, che insomma hanno qualcosa da fare tra di loro, magari nella stessa business area della tua azienda, in senso non sono solo progetti completamente distinti, dove non si parlano tra di loro, hanno qualche relazione tra di loro.

E questo è il monorepo.

E quando tu ovviamente fai il build di un singolo progetto in CI, a una certa velocità, quando tu invece crei un repository con 5, 10, 100 progetti, è un altro discorso adesso far rendere questo performante, diciamo, nel tuo sistema di continuous integration o di dove.

E questo è cosa NX fa nella base.

Cioè ha dei sistemi di parallelizzazione, dove questi task, i build, i test, vengono eseguiti in parallelo al massimo possibile.

Ha dei sistemi dove riesci a capire, guarda, in questo pull request ne hai toccato solo quei tre progetti, perciò non è che vado a rifare il build di tutti i progetti, ma esegui i task su questi tre progetti.

Sempre per, diciamo, il target, il goal, di ridurre la run time nel tuo sistema di continuous integration.

E questo, diciamo, è la base di NX, dove facilita queste cose con questi meccanismi.

Poi c'è un altro lato, che è più quello che chiamiamo noi, diciamo, l'integrated monorepo, dove NX ti fornisce anche dei plugin.

Nel senso di non sei l'esperto te di monorepo, non sai magari come partire, allora ci sono dei plugin che ti facilitano la partenza.

Nel senso che ti generano del codice, ti preconfigurano, diciamo, la tua React app, la tua Angular app, in tal modo che funziona al migliore all'interno di un monorepo.

E queste sono un po', ad alto livello, le cose che abbiamo fatte.

Sì, io ricordo che, insomma, il monorepo, almeno adesso la cosa si è semplificata parecchio, però quattro anni fa, o giù di lì, tre, quattro anni fa, erano veramente un bagno di sangue nell'ecosistema JavaScript.

Dalla tua prospettiva, cosa vedi che è cambiato? E che il trend evolutivo dei monorepo, in cosa è cambiato? E come NX ha seguito questo cambiamento e si è adattato all'evoluzione, insomma, del...

Per esempio, io ricordo quando arrivarono i Yarn Workspaces, eravamo tutti...

Adesso npm-workspaces, npm...

Ecco, come Narval è riuscito a seguire questa evoluzione ancorando le sue feature on top di questi tool? Perché so che sono compatibili.

Sì, sì, concordo.

Nel senso che due, tre anni fa, come sappiamo, non c'erano Yarn Workspaces o npm Workspaces e così via.

Quello che si utilizzava è o sapevi di NX, che già in quei tempi sapeva crearti un monorepo preconfigurato dove gestiva o gestisci anche le dipendenze, i link fra i packages, o l'alternativa era Learn, che era un altro monorepo management tool che ormai noi abbiamo preso anche il stewardship di quello lì, la gestione, perché è stato considerato obsolito in aprile quest'anno, mi sa.

Però a questa parte praticamente erano queste due opzioni.

Il problema nel monorepo, tu vuoi proprio evitare il fatto di dover pubblicare i pacchetti su una registry e poi riutilizzare la registry.

Vuoi avere quel link locale dove tu hai un pacchetto e poi direttamente, a referenze, il punto di entrata di quel pacchetto, lo utilizzi nella tua app.

Questo è quello che vuoi avere.

E come dicevi, Yarn Workspaces non c'erano, npm Workspaces non c'erano, non c'era un modo di fare questa cosa.

E in Enhanced Neuron, sempre con questi plugin, la soluzione dove lo facevamo tramite tipo TypeScript.

TypeScript ha una feature che si chiamano TypeScript Path Mappings, dove tu potevi dire, guarda, add now all slash bla bla bla o add my organization slash bla bla bla, punta su quel file di TypeScript, che era uno dei pacchetti, e questo ti permetteva di non dover utilizzare il sistema di Yarn Workspaces e npm Workspaces, non ne avevi bisogno.

E potevi comunque usufruire di questo vantaggio di poter condividere pacchetti in modo veloce in un monorepo, senza dover pubblicarsi un registry.

E questo tuttora, anche oggi, puoi utilizzarlo.

Cioè, tantissime ditte grandi utilizzano questo sistema di plugin con le Next, e anche noi stessi siamo ancora convinti che questo, diciamo, a lungo termine, ti dà più garanzie, più manutenibilità del tuo monorepo, che è una cosa molto importante, perché partire velocemente è molto facile, abbastanza facile.

Il problema è che in un anno, un anno e mezzo, due anni, sei ancora contento del tuo monorepo.

Questa è spesso la sensazione che vedo.

Posso farti subito una domanda? Perché mi hai messo la pulce sull'orecchio e io adesso sono curioso.

Avendo anche, da una parte, la consulenza, probabilmente ne avrete visto di ogni.

La domanda è, in cosa questo approccio al monorepo è più sostenibile nel lungo periodo rispetto a un NPM o un PNPM, dal tuo punto di vista? Sì, il discorso è piuttosto...

Cioè, nel senso, il sistema di plugin che Next ti dà in un monorepo, il sistema di plugin con Next noi chiamiamo l'integrated monorepo.

Integrated perché è preconfigurato, non devi te occuparti di configurare ogni low level setting del tuo setup, il build e tutto quanto.

Ma hai questi plugin, che tra l'altro puoi crearti anche te abbastanza facilmente, che wrappano i tool sottostanti.

E il discorso è che con questi plugin, se noi abbiamo tipo il React plugin, il Typescript plugin, un plugin per Cypress, per Jest, per Linting, siamo noi, in questo caso, o un community provider che ha creato un plugin Next, che ha messo tutti quei pensieri, tutte queste, diciamo, questa pianificazione di come dovrebbero integrarsi in un monorepo.

Perché un discorso è, mi prendo la Next.js app, mi prendo una Create React app, li butto insieme in un sistema di cartelle, metto su un NPM o yarn PNPM workspaces, solo per avere Linting, ma con quello, sì, ho fatto un monorepo.

Riesco anche a condividere pacchetti in modo locale, Linting, tutto questo funziona.

Però poi succede, beh, uno ha la Typescript versione 8, cioè 8, 5, no? L'altro ha la Typescript versione più vecchia, l'altro ha React 17, l'altro React 18, e allora praticamente io devo occuparmi, come sviluppatore, di metter sì che tutti questi si interfacciano in modo, diciamo, fatto bene, così che si connettano in modo bene.

E questo, diciamo, è un problema che spesso vediamo, che anche in aziende grandi, e c'hai tanti sviluppatori, questo diventa un problema a un certo punto, no? Dove, ah, vedi quel pacchetto che è quello che vorresti utilizzare, però non ha la Typescript versione giusta, perciò ti dà runtime qualche problema quando esegui il prodotto, no? In più, praticamente quello che ho messo su questi plugin, inoltre, sono una serie di altre feature, nel senso che, non so, hai...

abbiamo clienti che hanno, diciamo, due, tre, cento, quattrocento progetti all'interno di un monoreaper, no? Dove sono diversi team che lavorano in questo monoreaper, e allora hai una certa struttura anche di pacchetti, no? Di...

che è riutilizzabile e non riutilizzabile.

E quello che avevamo messo, quello che avevamo visto, per esempio, noi che spesso diventa un problema, è che come controlli chi può utilizzare cosa, importare cosa nei loro progetti, no? Che non lo puoi, cioè sì, con delle regole, in qualche modo riesci a, diciamo, dire, guarda, questa è la struttura delle cartelle, perciò solo all'interno di quella cartella puoi importare, non al di fuori di quella...

cioè con regole di questo tipo, che metti nella documentazione, blablabla, no? Sappiamo tutti come funziona con...

scrivo nella documentazione cosa dovresti fare, cosa no, no? E poi anche con tipo Visual Studio Code, o questi sistemi che abbiamo oggi, l'auto-import lo mappa su un altro utility, che però non è nel tuo pacchetto, ma è nell'altro pacchetto.

Non te ne accorgi neanche, no? E subito iniziano a avere delle cross-dependencies strane, che poi diventa veramente un casino, specialmente con queste grandezze, no? E lì, per esempio, con i plugin abbiamo dei sistemi su che con delle lintool tu puoi dire, guarda, questi progetti li dai come un label, dove dici questo è il tipo feature di questo tipo di progetto, e poi puoi definire quale label può dipendere da quale altro label, per dire, no? E in modo molto semplice puoi definire una specie di regole che però vengono automaticamente eseguiti in CI, per esempio, no? E sono tutte cose così, no? Che i plugin ti permettono anche fare.

Ti permettono perciò ad agevolare, diciamo, monorepo grandi, e far sì che non diventa un casino, e dopo diciamo un anno dici, splitiamo di nuovo, facciamo un po' di repo, dimentica il discorso del monorepo, no? Sì, vai, vai, scusami.

No, ma giusto per ritornare alla domanda che avevi fatto, come però vi adottate anche ai nuovi sistemi come gli Unworkspaces, no? Che è un sistema valido, tra l'altro, no? Perché se tu hai già le conoscenze, o hai già un monorepo, non vuoi magari direttamente migrare sul sistema di NX plugin, quello sarebbe troppo complicato, no? Se magari hai già un monorepo di 50 e più librerie con PMP Workspace o Unworkspaces, vorresti solo avere qualcosa che ti magari gestisce e ti esegue i task in modo efficace, no? Quello è l'unico che vuoi, però non vuoi magari il plugin che ti gestisci tutto il build, non so cosa, no? E per quello, diciamo, noi ci siamo, anche siamo evoluti, abbiamo evoluto NX in quella direzione, in tal modo di poter anche essere una soluzione in questi casi.

Questo, diciamo, è stato un po' l'obiettivo.

Chiaro.

Domanda giusto per stare nei monorepo.

Secondo te...

Allora, qua prendo in prestito una frase detta scherzando da un mio amico che, insomma, è una battuta.

Sì, sì, sì.

Ma secondo me un po' ha senso, no? Il monorepo è...

è...

Usare la parola monorepo è come usare la parola monolita a head of time, no? Nel senso che uno dei problemi dei monorepo, dei rischi del monorepo è l'accoppiamento.

Un po', tu l'hai detto, ci sono dei lean tools che ti permettono di mettere delle regole, cose che magari con npm workspaces io non c'ho.

Non ce l'hai.

Sì, sì.

Oltre all'inting esistono una serie di altri tool e soprattutto questa cosa si presta a un approccio un pochino più verticale rispetto a che orizzontale dove non ci sono solo gli sviluppatori ma magari c'è un'organizzazione un po' più articolata con una forma che fa un po' da piramide, ecco, anche se poco ci piace.

Sì, sì.

No, no, è assolutamente valido.

E per quello dico sempre, noi abbiamo sempre due goal in testa come Now or Like o come an ex core team members.

Cioè nel senso di, sì, darti la possibilità di facilmente avere un monorepo in un'istituzione dove ti trovi, però sempre puntando su quell'aspetto di manutenzione a lungo termine, no? Perché come dici te, su un yarn workspace sì, parti velocemente, però sì, se lì non sei attento, dopo un po' c'hai un accoppiamento fra i vari parti che è fortissimo e quello che crei alla fine è un monolith.

Perché a un certo punto se non riesci più a muoverti perché hai troppe referenze fra i vari pacchetti, no? E vengono utilizzati anche se non dovevano e poi ovviamente dopo staccarli di nuovo è un gran lavoro.

Per quello dico, i monorepo come noi li mettiamo e come noi facciamo il setup anche spesso nelle aziende questo è un aspetto molto importante di far la suddivisione e se questa la pianifichi per bene e la fai per bene, metti in passo già delle regole automatizzate in CI e così via allora praticamente riesci veramente ad avere dei benefici.

Perché lì quello che spesso invece vediamo anziché avere un monolith vedi che la gente inizia a creare più applicativi a un certo punto.

Entrando in quella direzione per esempio spesso abbiamo uno che dice noi abbiamo una creator act app o anche una next-gen app o in mondo angolo abbiamo un angolo CLI app che è un'applicazione con varie cartelle e così suddividiamo i nostri feature.

E spesso noi diciamo anche quando prendi a next non devi immediatamente pensare a un monorepo ma semplicemente prendi la struttura di un monorepo nel senso che taglia la tua app in pezzi più piccoli prendendo tutte queste cartelle che rappresentano una feature area, una domain area o quello che è e lo estrai in uno o più librerie che saranno sempre specifiche di questo applicativo nel senso non sono pensate per essere riutilizzabili in altri aspetti no no, sono sempre le stesse librerie poi il fatto di staccarle dall'applicativo già ti dà una modularità più alta perché te devi iniziare a pensare ok, qual è l'API pubblica di questa libreria c'è qualche cosa che all'interno può essere utilizzata o no? Cioè ho solo queste tre metodi dove posso attaccarmi all'applicativo o questo è? Cioè quello che vediamo noi spesso è che lo sviluppatore in quel momento inizia già a pensare diversamente anziché quando è solo una cartella all'interno di il CLI tool, quello che vuoi il creator act app o angolo CLI e poi avendo questa struttura diventa più pulito perché quando tu non so hai più team e devi allocarti, allocarli in quell'app gigante no? Allora già è più facile perché lì poi adesso c'è il team della product list del shopping app, non so quelli lavorano su quelle sottocortelle perché questa è tutta l'afficina, la main area per le shopping list, per la product list e così via, tu puoi staccarle in questa maniera e poi ti arriva la mobile app e già hai una situazione pronta per poterli utilizzare in modo più facile delle cose perché lì hai già praticamente modularizzate se vuoi fino a un certo punto no? Anche se all'inizio avevi solo un'app singola Questo è interessante, mentre parlavi mi hai fatto venire in mente una domanda bastardella quindi mandami a quel paese se non ti piace la domanda No, perché quello che fa fondamentalmente Nix è in qualche modo dare la possibilità di abbracciare una serie di buone pratiche tra le altre feature che poi andremo a vedere perché ce ne sono di altre altrettanto interessanti secondo me Suggerire, proporre delle buone pratiche per l'utilizzo dei monoripo con degli strumenti che semplificano strumenti che in realtà da quello che ho visto sono adattati in contesti molto diversi e allora la mia domanda è in qualità di responsabile dell'area Dx e in qualche modo completamente immerso nel progetto Nix come fate a bilanciare il trade-off di una feature request? Ti faccio un esempio ogni vostro utente ogni utente è un utente diverso talvolta con esigenze differenti in un ecosistema, in un contesto diverso arriva una feature request ho percepito un'esigenza come fate a trasformare quell'esigenza in feature senza che questa trasformazione genere un impatto negli strumenti che sono adottati anche da un ventaglio di altre aziende che quella esigenza non ce l'hanno come si trova il balance tra questi elementi? Sì, allora normalmente tutte le feature request le distinguiamo in due cose principalmente nel senso che la parte che finisce in NX Core che è quello che puoi utilizzare anche con Young Workspace per esempio è la parte centrale di NX e normalmente quelle sono cose di o performance o di caching o tutte queste cose di base di come si vengono gestite il monoreapon da parte della speed principalmente e o se questa feature ha a che fare con qualche plugin che praticamente vengono attaccati on top di questo NX Core e lì poi si distingue cioè noi abbiamo i plugins che sono abbastanza piccoli fra di loro nel senso abbiamo un plugin verticale per solo la gestione dei Jest test plugin solo per i Cypress test per React, per Angular per React Native e così via perciò sono molto canalizzate e questo ci permette di ridurre anche l'impatto che hanno cioè nel senso non è un unico NX dove adesso cambi qui qualche cosa e poi magari ti esplode tutt'altro su un'altra cosa su un altro plugin di Angular magari cambiando quella parte di React perché riutilizza una parte riutilizza una parte comune ci sono ovviamente per quello abbiamo un massivo numero di end-to-end test che girano ogni volta che cambiamo qualche cosa però normalmente si canalizza veramente su uno dei plugin e maggiormente sono delle cose come non so, sarebbe ideale avere un altro code generator per generare, non so i componenti React in una certa maniera cioè sono cose normalmente più specifiche di un certo plugin e per quello l'impatto è normalmente solo locale all'interno di questo plugin cosa da dire però ovviamente è che per esempio, non so noi al momento utilizziamo React con Webpack c'è gente che dice beh, noi vogliamo avere Vite vogliamo avere YesBuild e tutti quei nuovi sistemi più veloci e così via di cerchiamo veramente di sicuramente anche frenare un po' perché noi cerchiamo di valutare cosa viene utilizzato maggiormente al momento nelle aziende grandi che sono un grande target dell'utilizzo di Annex e in base a questo diciamo facciamo un po' una priorizzazione come andiamo avanti però stiamo sempre diciamo dando un'occhiata su questi nuovi tool infatti ultimamente abbiamo aggiunto adesso YesBuild e andremo avanti in questa direzione di bilanciare quello che ci arriva dalla community quello che vediamo lavorando con i nostri clienti enterprise anche grandi e un po' fare il match lì in mezzo il grande vantaggio secondo me è che abbiamo da quando abbiamo introdotto i community extensions che vuol dire che non dobbiamo fare il tutto il lavoro noi nel senso per React con Vite per esempio o anche Annex con Svelte Vue.js ci sono dei community plugins che sono veramente buoni e fatti bene che praticamente uno potrebbe utilizzare se uno dice bene Now all React plugin non mi piace non soddisfa quello che voglio utilizzare mi riferisco a uno dei community plugin e parto da questo è come un npm package alla fine che aggiungo al mio workspace chiaro, quindi abbiamo detto che questi plugin ti permettono di fare delle cose e ne hai citato alcuni per esempio Jest in realtà rispetto a npm, install, Jest e React Testing Library se sto lavorando con React cosa ho in più nell'utilizzo di un plugin in questo caso per esempio quello di Jest ma può essere quello di Cypress può essere quello di Cypress anche di React o qualsiasi cosa alla fine è che ti toglie tutto il discorso della configurazione da te c'è il senso configurare una React app per esempio un Cypress all'interno di un monolibro può essere diverso nel senso che vuoi integrarlo con quella versione che esiste già vuoi far sì che magari utilizzino una configurazione comune così che non per ogni app devi riconfigurare cioè cose di questo tipo i plugin già cioè chi sviluppa i plugin o c'è la community o noi in questo caso pensiamo a queste cose lo testiamo, lo integriamo con le varie modalità diverse di monolibro e facciamo sì che funzionino bene tra l'altro stiamo anche collaborando spesso o molto con il team di Cypress team di Jest team di Storybook che li chiediamo, li cooperiamo con loro anche se loro hanno una vicenda nel loro repo e viceversa e sono tutte queste cose che noi stiamo occupando con questi plugin che te non devi praticamente pensare a come configurare in modo giusto Jest nel tuo workspace perché è fatto in automatico per te quello che fai te è semplicemente aggiustarlo e quello ovviamente devi farlo e puoi farlo nel senso però lì non vai necessariamente a toccare il low level webpack ma vai in un che si chiama Project Json o vai in una serie di opzioni dove dici voglio avere gli external compilati all'interno del mio vendor file o no cioè sono delle properties che puoi andare a configurare altro vantaggio che non è da poco secondo me sempre anche parlando della manutenzione è l'upgrade automatico cioè nel senso quei plugin quello che ho ha un comando di migrate che praticamente da una versione all'altra mi fa la migrazione automatica di NX stesso delle file di configurazione di webpack di cypress cioè completamente in automatico cioè cambia il tuo call sorgente cambia i tuoi file di configurazione e così ti porta da una versione all'altra e questo specialmente anche di nuovo se tu hai un monorepo abbastanza grande può essere estremamente utile perché almeno io quando lavoravo con dei clienti se tu devi dire o anche in generale se tu lavori all'interno di un progetto se nel sprint planning devi dire ah dobbiamo fare l'upgrade di webpack da 4 a 5 per essere importante e poi normalmente dicono ah sì ma cos'è che implica ma non funziona più l'applicativo no funziona però è importante perché cioè cioè il nuovo feature che vogliamo usufruire del non so modification che arriva in webpack 5 sì sì capisco lo facciamo il Q3 non abbiamo tempo e sappiamo tutti come funziona i tech ticket incroda il backlog esatto sempre sì sì esatto e con questo comando che è molto diciamo è stato un po' preso dall'angola CLI che ce l'aveva già dall'inizio l'abbiamo trasformato e abbiamo sviluppato un sistema di code migration all'interno di NX che ti permette a fare queste cose e lo utilizziamo anche cioè noi abbiamo fatto i migrations tipo anche di workspace angular grandi dove abbiamo migrato tutti gli applicativi da angular 13 a 14 da webpack 4 a webpack 5 mentre 300 sviluppatori stavano sviluppando sul main branch in continuo cioè non puoi dire in queste grandezze affermiamo tutto uno si occupa adesso di tre settimane a fare la migrate o quello che serve e poi migriamo tutto e perciò abbiamo proprio sviluppato questi code migrations che puoi eseguire più volte sono come alla fine come se conosci database migration scripts dove puoi fare un upgrade da una versione all'altra che ti fa poi gli alter table gli alter descript e così via solo che si ha sulla codice base sì sì super super interessante e adesso un'altra domanda negativa però che secondo me fa capire l'inquadramento di Enhex lo sviluppo di questi dev tools in qualche modo genera astrazione tu hai detto ci allontaniamo per un attimo da quello che Git chiama plumbing da low level astraiamo i concetti in modo che possono essere rapidamente configurati perché non ho bisogno di tunare fare tuning sul dettaglio ogni volta e poi io ti ho fatto un'altra domanda prima in merito a quanto una feature impatta su un altro utente che non ne ha bisogno perché venendo dal mondo business a me è capitato di over modellare dei software cercando di riprodurre la realtà creando una complessità allucinante che non permetteva di funzionare anche alle feature base è una cosa che capita spesso ognuno di noi l'ha fatto un'esperienza di questo tipo e tu hai detto no, con la pluggabilità quindi la possibilità di lavorare a plug in io risolvo il problema che è un po' la stessa cosa che mi ha detto Francesco la settimana scorsa mentre parlavamo di backstage il developer portal è creato e mantenuto da Spotify la mia domanda è affinché un software sia pluggabile deve necessariamente astrarre delle cose alla base di queste astrazioni da quello che mi è sembrato di capire ci sono due concetti importanti in NX i generator e gli executor mi sbaglio? sì, giusto che sono un po' il core che permette questa estendibilità cosa fanno questi due elementi? qual è il loro ruolo? sì, loro sono praticamente la parte core di ogni plug in alla fine cioè il plug in stesso non fa niente di...

cioè normalmente ogni plug in fa da esecuzione del codice cioè che è il wrapping di un npm script se vuoi quello serve l'executor anziché eseguire un monorepo npm workspace dove tu hai un npm script che ti fa da, non so tsc per typescript compiler e poi ti dà tutti gli argomenti e i parametri c'hai un executor addnow, allora il tuo addmyorg slash tsc che praticamente wrap questo processo che sotto le quinte alla fine il codice fa nient'altro che eseguire il stesso cioè fare un spawn sync di un processo qualche cosa in node e esegue il typescript compiler ma prima di farlo magari sapendo che si trova all'interno di un monorepo magari legge la typescript config file e la root per fare delle ottimizzazioni roba di questo tipo e poi esegue questo processo l'altra parte del plug in sono i generator e quelli fanno nient'altro che generare del codice cioè in senso per react può essere generare il setup di un nuovo applicativo setup di un nuovo libreria o anche solo setup di un piccolo componentino nel modo come tu vorresti averlo per avere anche l'uniformità fra i vari development team così che ogni libreria, ogni componente sia più o meno una forma simile questo è un po' lo scopo agevolare lo sviluppo alla fine se vuoi l'intenzione dietro le quinte e questo può essere semplice come si, genero un nuovo componente ma anche, si, genero questo componente ma voglio che questo è un rooted component e si integra in questo applicativo e lo puoi dare come un parametro questo è l'app dove si dovrebbe agganciare e NX poi ha anche certi generatori dipende come complessi sono fatti che ti inserisce persino anche il rooted component direttamente nell'app così che si connette la storia cioè alla fine sono delle utility i generator che aiutano lo sviluppo al sviluppatore questo, si chiaro naturalmente però altra domanda cattiva vai oggi ti sto torturando, è una mia colpa alla fine questi tool tendono ad allontanare un pochino lo sviluppatore dal basso livello che in un contesto enterprise non è sempre poi così male nel senso che c'è qualcuno che si prende le responsabilità decide crea una strazione omologa la decisione e così si va in contesti un po' più piccoli dove c'è questo tipo di elasticità la cosa si presta bene o ci sono degli attritti si è nuovo direi perché il discorso è che questi plugin sono abbastanza cioè si ti astragono l'npm script per dire o il webpack low level dove ti confili completamente il tuo webpack o rollup o quel che è però è un strato sottile direi sopra quel layer che vuol dire che potresti toglierlo o molto facilmente anche crearti il tuo plugin locale per configurare in quel modo come vorresti te e comunque poi hai questo vantaggio di averlo uniformato e questo per esempio per parlare delle aziende più grandi dell'e-enterprise spesso è proprio quello che vediamo cioè questi, noi li facciamo magari anche il setup iniziale o gli diamo una mano e poi loro si customizzano e next proprio come lo vogliono loro cioè nel senso customizzano come vengono generati i libri e hanno proprio loro set di plugin spesso anche solo locali che possono anche vivere all'interno del monoreapp non è necessario pubblicare per esempio plugin su npm o qualche parte ma li puoi tenere locali per avere una forma di automatizzazione del tuo monoreapp parlando dei scenari diciamo elastici, piccoli startup, quei scenari lì lì dipende molto c'è chi che dice ah mi è molto utile per così specialmente se in uno startup deve essere veloce nel senso voglio fare un shipping di nuove feature molto velocemente così so già che mi serve un monoreapp creo direttamente il setup predefinito che mi da inhex quindi parto in modo rapido non devo pensare a tutti i dettagli del monoreapp di quel setup lì e poi dopo ritorno e magari me lo aggiusto me lo configuro però nello stesso momento poi c'è anche chi dice no no voglio avere lo setup completamente sotto controllo voglio configurarmi tutto io voglio creare il mio webpack voglio creare il mio rollup o quel che sto utilizzando e poi aggiungere nexolo per il caching, per il CI e quelle cose lì ed è proprio quello il motivo perché abbiamo introdotto quel secondo modello di utilizzare nex senza i plugin è assolutamente solo per questo appoggio lì e quindi la domanda mi viene poi spontanea e automatica pensiamo a react per un attimo alla create react app arriva un certo punto dove tu fai l'eject dell'applicazione esiste qualcosa di simile per nex noi abbiamo parlato di adozione quindi abbracciarlo ma se io invece volessi eliminare quella sovrastruttura quella struttura, quei livelli di astrazione esiste un eject che mi butta il webpack nudo e crudo quelle tre righe di script direttamente nel package json e ciccia o sto semplificando un po' troppo per quando utilizzi i plugin non esiste perché sarebbe anche abbastanza complicato realizzare un eject perché non sono tutte le tre righe di webpack che dovrebbe fare l'eject.

Per l'approccio package based dove tu praticamente solo utilizzi nex on top, lì ovviamente si perché lì non hai mai utilizzato uno dei plugin praticamente cancelli la nex package nella root del npm e fine perché già utilizzi il monoreapon in modo tutto tuo tutto sotto controllo è proprio il motivo anche per il quale noi ci riferiamo a quel tipo di setup come full control a te tu esigisci tutto, vuol dire anche che te devi preoccuparti però di tutte le cose come fai il setup del linking local devi conoscere npm, nvworkspace, nvworkspace però se lo fai e spesso quando hai già una struttura esistente è molto più semplice di partire e quello che puoi fare in quel momento è sì, parti con quello e poi aggiungi dopo solo un plugin per un unico applicativo all'interno di quel setup e parti da questo però no, per il plugin react per esempio di nex non c'è una funzionalità di eject ci avevamo pensato a quella cosa però non è così facile realizzarlo non è solo una cosa e poi non era super alta priorità a livello delle richieste chiarissimo in realtà la domanda mi veniva mi portava nel ragionamento a un altro punto, noi abbiamo fortemente parlato di nex e monolipo in questo momento però immaginiamo facciamo questo esercizio immaginiamo il caso d'uso POC Proof of Concept o pet project della situazione ognuno di noi ne ha 70 che probabilmente giacciono sul cassetto non abbiamo una struttura per cui potrebbe non essere utile potrebbe esserlo ma anche potrebbe non essere utile avere un approccio a monolipo ok per questo però allo stesso tempo potrebbe essere utile per esempio un code generator, un sistema di plugin, a quel punto la mia domanda è quanto nex si presta ad essere utilizzato al di là del concetto di monolipo no assolutamente lo puoi quello all'inizio avevo detto normalmente dobbiamo introdurre il discorso monolipo se parliamo di nex, però non solo cioè nel senso tu potresti utilizzare nex oggi anche come alternativa a create react app che non è proprio diciamo super up to date e così via, ma utilizzi solamente nex con un'unica cartella app dove metti la tua app, non dovresti neanche utilizzare i libri e tutte quelle funzionalità ma utilizzi solo il code generator alla fine perciò lì non hai veramente un monolipo perché ne hai solo un unico applicativo all'interno di quel monolipo, che non è una cartella praticamente con un'app e usufruisci solo dei generatori di nex, sì sì assolutamente puoi farlo cioè io mi immagino l'agenzia di comunicazione che ha bisogno di di shippare tante app react angular o vgs che siano però vuole in qualche modo siccome ne fa tante e le fa al ritmo molto sostenuto vuole in qualche modo darsi una linea, cioè i componenti devono essere in questo modo lo scaffolding dell'applicazione deve essere in questo modo i components, container e quant'altro gli stili devono essere, cosa ne so è un caso comune che vengo chiesto è un caso molto comune dove, come dici te, devono produrre più app velocemente comunque avendo un simile look and feel alla fine o anche magari solo avendolo parametrizzato in modo diverso che però cioè parametrizzato nel senso che averne più shell che sono già preconfigurati in certa maniera e che poi vengono deployati in modo diverso per tipologia di cliente che spesso esiste però lì spesso ho proprio il caso di monorepo nel senso che questi si creano la loro libreria design system dove hanno i componenti riutilizzabili la loro libreria teams quel chi è e li compongono i vari applicativi all'interno di quel repo che sono preconfigurati per i vari casi d'uso che hanno e li compongono semplicemente utilizzando questo design system che si trova all'interno del monorepo però lì ho veramente spesso il caso dove la gente va in quella direzione chiaro e tra l'altro là, credetemi il vantaggio è altissimo del monorepo un po' di progetti fa lavoravo in un progetto che non usavo i monorepo ma gli servivano nel senso che avevo bisogno di fare, c'era un bug nella UIKit dovevo fare la PR, attendere che il team responsabile della UIKit approvasse la PR, che buildasse il modulo, che lo shippasse su NPM per potermelo vedere oppure facevo in modo molto vichingo molto vichingo come ha scritto Matteo Collinacqua un tempo fa, sostituio, facevo hot replace nel node modules e almeno ecco qua sono stato anche io ecco qua un caso d'uso per chi non utilizza i monorepo già solo la visibilità del codice perché spesso se tu lavori in repo singoli, poli repo, non monorepo diciamo in aziende grandi te sei responsabile del design system per esempio, sviluppi componenti utilizzabili del design system non sai neanche dove viene utilizzato perciò non hai neanche modo di dire adesso provo velocemente se quel bottone effettivamente funziona in quell'app o se non dà problemi e già il fatto di essendo in un monorepo, il codice sorgente ce l'hai sulla tua macchina tu puoi anche utilizzare sistemi di Visual Studio Code per fare final references di quel componente e lo trovi in un vecchio search con una regex o qualche cosa e lo trovi il componente e siccome e questo è un altro vantaggio dei plugin, siccome il setup è uniforme in quel momento, te sai anche come far partire quell'applicativo perché sarà lo stesso comando come utilizzi per la tua demo app del tuo design system perciò questi sono tutti vantaggi dove tu già puoi dare un'occhiata, vedi come viene utilizzato e puoi anche fare cose di breaking change diventa molto più facile ma sì, ha dei vantaggi e svantaggi siccome hai detto una cosa molto bella in realtà cioè hai visibilità su cosa stai usando e come lo stai usando e qua si apre tutto il capitolo di discoverability come Enhex abbraccia questo argomento? nel senso di non far vedere per esempio una cosa che ho visto, una feature interessante è tutto il lavoro che fa sul dependency graph mh mh sì questo è sì molto sì sì esatto, cioè questo è il dependency graph alla fine è la base di Enhex cioè viene calcolato in un thread a parte dietro le quinte, però viene utilizzato per tutti i processi che fa cioè quando fa partire diciamo cerca di parallelizzare più task guarda dependency graph per capire cosa deve essere fatto prima e quale lavoro deve essere fatto dopo perché ovviamente conoscendo tutte le dipendenze conosce come utilizzarlo però dall'altra parte quello che dici te è la visualizzazione di quel dependency graph quella è la cosa secondo me molto forte, è anche il poter cioè poter farlo vedere in una finestra del browser dove tu, anche non conoscendo la situazione del monoreap, puoi aprirlo puoi vedere come i pacchetti dipendono fra di loro puoi andare anche nel dettaglio dire guarda, voglio vedere clicco su un nodo, c'è anche interattivo ultimamente abbiamo fatto interattivo nel senso che puoi cliccare su un nodo e dire, parto da questo nodo so che voglio arrivare a quell'altro nodo fammi vedere tutte le vie come arrivo a questo nodo, fra questi due e c'è un strumento di debugging alla fine di esplorazione del monoreap o anche di debugging per capire ma perché c'è quella dipendenza che non dovebbe essere sì, è molto molto, diciamo, utile guarda, questa cosa da molti è sottovalutata per me ha un'importanza allucinante se attorno a questa feature mettiamo il frame di sai molti dicono, scriviamo il codice per rifattorializzarlo ok, quindi prepara il codice quando lo scrivi in modo che sia facile stenderlo, ok c'è un'altra scuola di pensiero che si affianca a questa che dice, tu prepara il tuo codice affinché sia facile eliminarlo che è una cosa è una cosa ancora più intelligente per chi lavora sul refactoring se vuole fare del vero cioè per chi scrive il codice se vuole avere del codice veramente disaccoppiato deve ragionare in questo modo avere una visualizzazione del dependency graph in quel modo assume un'importanza allucinante in quell'ottica e spesso è una cosa che non ci fermiamo a ragionare, per esempio io oggi ho perso tre ore per cercare di purgare una cacchio di libreria che era accoppiata in tutti i modi possibili e immaginabili al codice cerca e rimuovi, cerca e sostituisci spesso, non si presta bene alla creazione di un modello mentale, qua potremmo rimanere ore a parlare di carico cognitivo e di quello che facciamo quanto invece si presta bene avere un grafo un chart un grafico che lo mostra, quindi questa cosa mi aggasa tantissimo, devo dire è probabilmente la feature più amata dei nostri sviluppatori, anche perché è una delle poche feature visuali essendo un dev tool che il 99% lo utilizzi tramite la command line è un po' fresco avere qualcosa di visuale ma è molto potente, anche perché questo che si vede nelle visualizzazioni del browser è anche solo una parte se lo stiamo sviluppando continuamente, anche se stiamo pensando già ad aggiungere feature più avanzati nel poter scriptare quel graph perché tante volte quello che fai anche è quello che non viene visualizzato totalmente, è che questo dependency graph ha anche l'informazione di pacchetti npm che ogni di questi pacchetti utilizza perciò tu puoi anche a livello node script, ti fai un piccolo script dove puoi direttamente tramite un API farti dare il dependency graph che è un oggetto alla fine javascript con tutte queste informazioni e poi ti crei i tuoi loop, il tuo algoritmo che lavora su questo, perciò questo graph praticamente puoi utilizzare in mille modi diversi che possono essere utili per il tuo caso, per esempio io avevo un caso in un'azienda dove facevamo consulenza che era, mi sa che era Angola mi sa, e volevano ottimizzare la startup time dell'applicativo, che con lazy loading è uno dei modi che puoi farlo ma esendo un applicativo gigante che tra l'altro io non conoscevo neanche andare lì a trovare tutti i possibili paths ai componenti che non sono lazy loaded e perché non sono lazy loaded è quasi impossibile, però scrivendo per esempio un piccolo node script su NxMonorepo, che lo utilizzavano Nx, riuscivo a dire, bene, trovami tutti i node finali e da quelli parti e vai su finché arrivi a un app seguendo semplicemente il path del dependency graph e se non è lazy loaded, cioè se tutto il path è direttamente incluso tramite un import nell'applicativo, elencami praticamente queste librerie e il percorso come arrivi da un nodo all'altro, cioè mi faceva proprio vedere il file, la riga nel file dove viene fatto l'import che non era lazy che potevo poi andare a sostituire e questo si permette per dire prendere conoscenze di una codebase gigante magari dove non sai com'è strutturata però utilizzando questo strumento puoi ragionarsi su, no? E questo è solo un caso d'uso, c'è le possibilità che è veramente una afficcia bella, sì assolutamente.

È di lì la consulenza ben fatta, nel senso che arrivi là e gli deduci...

Certo, lo fai in qualche giorno o in alto magari a lì mesi a fare un lavoro all'alto che non è piacevole Esatto Parliamo a proposito di velocità io prima di fare questa chiacchierata NX l'ho solo visto, non l'ho mai provato ma mi ripropongo devo...

c'è un POC da far partire a breve mi ripropongo di utilizzarlo però una cosa che ho letto spesso è che si parla di velocità a build time ma cosa è data questa velocità nel buildare grandi monolipo? Quali sono le feature che permettono di farlo in modo così velocemente? Sì, allora lì si parla sempre di ridurre la build time o test time alla fine l'esecuzione di un certo task qualsiasi task sia, poi alla fine a livello di un monolipo, cioè dove hai più progetti perché ovviamente il singolo build di un React Hub o Angular Hub dipende come lo fai il build se utilizzi Webpack o se utilizzi ESBuild o quel che è l'ESBuild in quel caso ti dà la velocità di quel singolo build specifico il problema è ovviamente se tu ne hai anche un build veloce di un progetto, appena che aggiungi i progetti nel suo repository quando tu fai il build sul tuo build server quello aumenterà ovviamente cioè è un'addizione dove aggiungi i progetti, i progetti si vogliono a un certo punto ovviamente una time che ti va su, che magari ti dura anche un'ora a fare il build o il test run strumenti che praticamente per quello, alla fine un monolipo ti servono dei tool che applicano delle pratiche per ridurre questo e per tenerlo abbastanza costante, nel senso di non avere quell'aumento e tecniche di, sono per prima il discorso di capire quale progetto è stato toccato sempre utilizzando quello del dependency graph cioè utilizzando una combinazione fra git commit, uno riesce a vedere tutti i file che sono stati toccati e poi questi file next se li prende se li mappa sui nodi che hanno il dependency graph e poi capisce ok, è stato cambiato quel progetto di mezzo quale altro progetto dipende da questo progetto e poi va ovviamente a rieseguire i task su quelli che idealmente è un subset di tutto il monolipo se praticamente hai sfiga è l'ultimo nodo nel tool graph ovviamente il build è molto più lungo perché deve ricomputare tutto quanto ma idealmente è un subset e già questo aiuta tanto.

L'altro poi è il caching il fatto di non rieseguire il stesso calcolo quando non sono state cambiate i parametri cruciali cioè nel senso col sorgente il comando che è stato eseguito gli environment variables o qualcosa che magari aggiungi anche te praticamente permette di fare un caching di una computazione cioè ogni volta che fai nx build quel progetto, nx test quel progetto, nx salva il risultato su una cartella locale e poi se questo viene rieseguito verifica se quel progetto esiste già se esiste già il cache di questo progetto che fa il ristorno che vuol dire anziché se il test run è veloce di mezzo secondo dopo saranno tipo 8 millisecondi è una roba molto molto più velocemente e idealmente ovviamente replichi questo cache poi lo distribuisci anche nella cloud in tal modo che non è locale sul tuo computer sulla tua macchina ma è proprio distribuito anche condiviso con altri per il tuo course o il tuo sistema di CI chiaro ed ecco che entra in gioco appunto quell'ottimizzazione è sempre il ruolo del dependency graph che è presente mi senti qua? sì, mi senti? io intanto guardavo l'orologio potrei rimanere altre 3 ore con te a chiamare ma so che dobbiamo andare a riposare che domani si lavora però prima di salutarti abbiamo due momenti il primo è quello di ringraziare chi ci supporta è arrivato il momento di ringraziare chi ci prende sulle spalle e fa sì che ogni settimana Gitbar possa raggiungere le vostre orecchie questa settimana abbiamo una donazione da FIAC RAID, spero si legga così anche se sono quasi sicuro che non si legge così e vi voglio leggere il messaggio ho appena fatto una donazione per supportarvi e dire un grandissimo grazie per il podcast sono irlandese, ho vissuto in Italia per 3 anni in un paese vicino a Ferrara, ho passato le lunghe giornate di lockdown in bici ascoltando il vostro podcast adesso vedendo che la mia esperienza di vita italiana sta per finire mi viene un po' di malinconia e volevo fare questo piccolo gesto per dire un grandissimo grazie nel cuore godetevi un bel Guinness al pub per me, come si dicono in Irlanda io ringrazio FIAC perché grazie appunto a FIAC e a tutti i donatori noi possiamo veramente pagare le bollette e quindi alziamo la nostra Guinness per brindare Cin Cin eccoci qua Yuri, abbiamo ringraziato FIAC ma adesso è arrivato il momento tipico e topico del nostro podcast, il momento del Paese dei Balocchi, momento in cui sia i guest che gli host condividono un libro, un talk un post, qualunque cosa valga davvero la pena essere shareato nella nostra community quindi adesso facciamo partire la sigletta e poi ti chiederò hai qualcosa da condividere? Quel fottografi è in mezzo all'ombra e conduco nel Paese dei Balocchi Ah, il Paese dei Balocchi Allora Yuri cosa ci porti da scoprire oggi? Ma stavo pensando e uno che mi è rimasto abbastanza è un libro che si chiama A Non Orthodox Guide to Making Things Worth Making che è scritto da Tony Fadel e lui è il co-creatore dell'iPhone cioè per primo dell'iPod poi dell'iPhone conseguentemente e così via e lui parla un po' di tutta la storia, come è partito come è fatto l'iPod come poi è sviluppato l'iPhone e dopo mi sa che ha anche creato il Nest il Google Nest che poi è stato comprato da Google però quello che mi è rimasto è perché lui parla molto di product development cioè nel senso cosa dovresti stare attento quando sviluppi un prodotto cioè guardi ai pain points del prodotto anziché magari solo le finezze ultime che poi aggiungi man mano e così via e quello mi è rimasto abbastanza bello bello, bello lo aggiungo alla mia libreria Amazon e sono sicuro che molti dei nostri ascoltatori lo faranno io ho un sito in questo periodo sto dando un occhiato un po' agli algoritmi cercando di rinfrescare un po' di lezioni dell'università di tanti anni fa e ho trovato un tool carino che in realtà da un lato mostra il codice dall'altra genera un grafo che insomma fa vedere il comportamento dell'algoritmo il sito è algorithm-visualizer.org insomma è carino per spenderci qualche minuto e dare un'occhiata e fare un po' di ripasso Yuri è stata una super chiacchierata sono davvero felice che sei venuto a trovarci si grazie mille dell'invito è stato piacevole tra l'altro so che tu non parli spessissimo in italiano giusto? esatto è stato un esercizio per di nuovo parlare un po' di più è ultimamente col lavoro per una vita americana parlo praticamente esclusivamente l'inglese è stata una buona occasione guarda sappi che è un po' il mio stesso problema Gitbar nasce per cercare di di parlare un po' di italiano perché da italiano che lavora in inglese e vive in Francia insomma anch'io ho quel problema e tra l'altro non sa parlare nessuna delle tre lingue l'italiano, l'inglese e il francese io ti ringrazio davvero tanto e come dico sempre da oggi Gitbar è un po' anche casa tua per cui quando avete qualcosa in Harwell o su NX di nuovo che vuoi condividere con la nostra community c'è sempre una birra fresca per te cool, sì, bello sapersi io ti ringrazio di nuovo e prima di salutarvi vi ricordo rapidamente i nostri contatti info.gitbar.it e atbrainrepo su Twitter sono i modi classici per contattarci oppure c'è il nostro gruppo Telegram se non l'avete ancora fatto mi raccomando iscrivetevi detto questo io direi che a questo punto vi saluto alla prossima settimana ciao ciao di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei Full Stack Dev.