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, benvenuti in questa quarantesima puntata di Gitbar.40 episodi iniziano ad essere un bel po', così come iniziate ad essere proprio parecchi gli ascoltatori e questo mi fa particolarmente piacere, iniziamo ad essere un bel po'.E piano piano, con un po' di lentezza, ma insomma siamo partiti la settimana scorsa, quindi cosa pretendiamo, sta iniziando a prendere forma il nostro gruppo Telegram e di questo ne sono super fiero.sono anche già iniziate ad apparire le prime discussioni, i primi confronti.La prima in assoluto è stata quella sull'introduzione, anzi la rimozione della parola "master" dai nomi di default dei branch, dei GitHub.E su questa discussione, etica o non etica, abbiamo ragionato un pochino appunto del ruolo e della posizione che GitHub voleva prendere.Ma non è il core dell'episodio di oggi.infatti partendo da quel ragionamento mi è venuta voglia di raccontarvi il concetto dei monoripo in realtà ci stavo lavorando già da un po' perché sto preparando un talk quindi volevo portare a voi diciamo in versione del tutto sperimentale una puntata un po' un po' particolare voglio raccontarvi i monoripo utilizzando la fiaba di joseph jacobs spero si legga così dei tre purcellini in realtà è una piccola pazzia questo episodio però vuole essere un esperimento voglio vedere se vi piace anzi vi richiederò dei feedback perché sto terminando un talk proprio con questo stile quindi ditemi un po se vi è piaciuta o meno perché ho voluto portare questa fiaba ho voluto portare questo argomento sotto forma di fiaba perché ho trovato una certa conflittualità nell'affrontare l'argomento sulla rete chi è pro che contro e ci si scorna e quindi volevo un po smorzare questo questo questa o questa guerra di fazioni Portando qualcosa di Di morbido devo dire che la versione della fiaba che vi racconto è la versione disneyana un po più Vegana non ci sono mai aletiche che muoiono prima però di iniziare come sempre vi devo raccontare e ricordare i nostri contatti www.gitbar.it è il nostro sito internet, là trovate tutte le info degli episodi, il modo per contattarmi, insomma tutto quello che il mondo di Gitbar ha come casa appunto il nostro sito Il gruppo Telegram che ormai è diventato il perno centrale della nostra comunicazione quindi www.github.me/gitbar e se volete contattarmi con i mezzi tradizionali siamo anche su twitter a @brainrappo o via email a info@gitbar.it.Ci prendiamo una piccola pausa e poi iniziamo con la storia di Joseph Jacobs C'erano una volta i tre porcellini che vivevano con i genitori.I tre porcellini crebbero così in fretta che la loro madre un giorno li chiamò e disse loro "siete troppo grandi per rimanere ancora qui andate a costruirvi la vostra casa prima di andarsene da casa le avviso di non far entrare il lupo vi prenderebbe per mangiarvi disse e così i tre porcellini se ne andarono e la loro strada si divise in tre parti.I tre porcellini vivono a casa con la mamma no? Quindi questa architettura un po' ricorda l'architettura monolitica vivere nella stessa casa dei genitori tutti insieme tutto particolarmente accoppiato una situazione complicata redeploy e continuous integration molto difficile da fare e cambiare le tecnologie impossibile è un deploy non democratico magari fatto solo dal team platform questa situazione tipica dell'architettura monolitica e infatti se noi pensiamo ai porcellini che devono chiedere alla mamma dove sono i calzini vediamo l'accoppiamento tra porcellino e la mamma cioè la dipendenza stretta tra i due elementi l'architettura diventa complicata piuttosto che complessa perché vivendo così in tanti in una casa la casa diventa disordinata le cose stanno dappertutto e quando si cerca qualcosa è difficile trovarla o magari la trovi tra un groviglio di altre cose.Redeploy e continuous integration molto difficili.Immaginate i porcellini che quando devono partire per le vacanze devono aspettare che tutti siano pronti e ognuno vuole portare un sacco di cose nella sua valigia e cosa succede se il porcellino più grande vuole portare lo stesso giocattolo con del porcellino più piccolo? Quindi tutto diventa più complicato così come diventa complicato adottare nuove tecnologie perché una volta che il monolita prende il suo corpo e diventa grosso è molto difficile cambiare la tecnologia che si utilizza così come è molto difficile nel caso appunto di una grande casa con tutti i porcellini dentro fare un trasloco e infatti bisogna spostare tutto di tutti.Poi un altro problema tipico delle architetture monolitiche sono dei deploy non democratici infatti spesso solo il team di platform come vi detto prima può deploiare e questo mi piace immaginarlo come il contesto dove solo la mamma e il papà possono prendere le decisioni che riguardano tutta la famiglia.Quindi un po' l'architettura monolitica si riflette su questo contesto e porta con sé diciamo tutti i problemi tipici appunto che vi ho raccontato.È necessario però cambiare situazione infatti i porcellini vanno via dalla casa della mamma e vanno a trovare un'altra soluzione.Il porcellino più grande spiegò che ognuno di loro avrebbe dovuto scegliere una direzione, le avvisò del lupo e poi andò a sinistra, il porcellino medio andò a destra e quello piccolo via via nella via centrale.Sulla sua strada il porcellino piccolo incontrò un uomo che portava della paglia."Per piacere dammi un po' di paglia" disse voglio costruirmi una casa in poco tempo costruì la sua casa e pensò di essere salvo dal lupo la casa non era molto bella e nemmeno fatta bene ma lui piaceva tanto gli altri due porcellini se ne andarono assieme e presto incontrarono un uomo che portava della legna costruirò la mia casa con legno disse il porcellino medio il legno è più resistente della paglia il porcellino il porcelino mi diò lavoro duramente tutto il giorno per costruire la sua casa.Adesso il lupo non mi prenderà e non mi mangerà, disse.Il porcelino grande camminò per conto suo lungo la via.Presto incontrò un uomo che trasportava mattoni.Per piacere dammi un po' di mattoni, disse il porcelino grande.Voglio costruirmi una casa.Così l'uomo gli diede dei mattoni per costruire una bella casa.Ora il lupo non potrà prendermi per mangiarmi, pensò.In questa situazione dove ogni porcellino costruisce la sua casa con la sua architettura, le sue tecnologie e anche le sue caratteristiche, riconosco fortemente la situazione tipica di un contesto polirepo o multirepo dove ogni repository o repository contiene la sua parte codice della nostra app generale che chiameremo modulo o pacchetto e la gestisce attraverso il suo sistema di versionamento.Un esempio più semplice è quello dove abbiamo una web app che ha due pacchetti uno per il front end e uno per il back end.Ognuno di questi pacchetti sono gestiti in repository differenti.In questo caso andiamo a vivere questa situazione.Mostra due differenti caratteristiche.La prima riguarda la ownership.Ogni team infatti possiede la sua repository e ne stabilisce quali tool si devono utilizzare e come deve strutturarla.Quindi se ne prende anche la responsabilità così come stabilisce il workflow di Continuous Integration e Continuous Delivery all'interno del team stesso quindi di quel pacchetto.Questa autonomia stimola particolarmente la ownership il fatto di dover gestire la responsabilità di quel pacchetto fa sì che il team sia fortemente collegato al pacchetto che vuole gestire.Tra l'altro pacchetto che poi potenzialmente potrà essere deploiato in modo anche indipendente.Per cui la ownership forte è la prima caratteristica di una situazione multi-repo o polirepo come l'andremo a chiamare.la seconda caratteristica è il disaccoppiamento infatti ogni repository contiene il codice coerente o per feature o per tecnologia comunque il codice che sta all'interno della repository ha in qualche modo una coerenza con il resto del codice contenuto nella stessa repo faccio un esempio la divisione front-end e back-end racconta di per sé una coerenza che è una coerenza magari per tecnologia ma se mettiamo caso si utilizzi un approccio che ne so a micro front end il pacchetto conterrà magari un micro front end specifico quindi avrà anche un collegamento per feature questo disaccoppiamento fa sì che la repository sia testabile separatamente avendo quindi la base generale della nostra applicazione divisa in diverse repository e testabile separatamente da anche una sorta di boost di performance alla fase di testing e quindi riduce drasticamente i tempi d'attesa e questo mi viene da immaginarlo nel contesto appunto della nostra storia dei tre porcellini come il fatto che ogni casetta contiene le cose di uno specifico porcellino è solo quello e sarà poi il porcellino a gestire le sue cosine all'interno della sua casa.Un altro elemento di fondo caratteristico di questo tipo di architettura o comunque di questo tipo di gestione del codice è che è la condivisione.Sembra strano raccontare la condivisione in un contesto polirepo dove ogni repository è ben disaccoppiato dagli altri per cui se la condivisione avviene in un modo abbastanza schematico e soprattutto con dei confini molto definiti infatti se un pacchetto che può essere front-end o back-end vuole usare qualcosa di un altro pacchetto ci deve essere un contratto bello esplicito per esempio se parliamo di...che ne so...di javascript ci deve essere indicata una dipendenza col numero di versione nel package.json quindi io sto dicendo io voglio utilizzare qualcosa di quel pacchetto che è esattamente quel pacchetto e voglio utilizzare magari nell'import solo quell'elemento specifico.Naturalmente qua la documentazione la fa da padrona per cui è sempre molto importante in questo caso tenere delle documentazioni precise ed esplicite.Quando si parla di condivisione però viene in mente un concetto molto particolare tipico dei polirepo.Infatti molti sostengono che l'approccio a polirepo non, quindi a multirepository, non stimoli la condivisione.Io credo che invece un approccio che stimola la condivisione sì, ma spesso la condivisione tra più organizzazioni.Questo perché in realtà faccio un esempio molto semplice ma è semplificativo di quello che voglio dirvi è che avendo diviso la mia codebase in tanti pacchetti indipendenti diventa molto semplice prendere un pacchetto rilasciarlo con licenza open source e fargli iniziare la propria vita.Quindi questo è diciamo uno degli esempi appunto della capacità che hanno i pacchetti che vivono in un ecosistema polireppo di essere condivisi tra organizzazioni in modo molto semplice.Naturalmente se noi la portiamo, portiamo questa riflessione all'interno della nostra organizzazione se per ogni pacchetto dobbiamo andare a prenderci npm ogni pacchetto al suo livello di versione tutto diventa molto più prolisso più più lento e più complesso da fare specie se ne abbiamo tanti pacchetti interni che dobbiamo usare per cui sarà necessario trovare un'altra soluzione.Un altro motivo per cui un'altra caratteristica diciamo che rappresenta l'approccio polirepo e la gestione del codice.Infatti ogni repository ha in modo indipendente tracciato la storia dello sviluppo del suo pacchetto e quindi lo stato di sviluppo di un certo pacchetto piuttosto che un altro è diciamo non autonomo e indica specificatamente quel pacchetto quindi se il pacchetto che ne so front-end ha una sua storia il pacchetto back-end ne avrà un'altra quindi saranno due elementi completamente diversi e vedremo poi che questa cosa può diventare un problema quando si vuole tracciare tenere traccia dello stato generale dello sviluppo di un sistema complessivo o quando si vuole diciamo tenere traccia di una modifica che riguarda più ambiti più aspetti e quindi più pacchetti della nostra codebase.L'altra caratteristica è l'accesso.In un sistema polirepo definire l'accesso è semplicissimo essendoci tanti repository separati basterà dare l'autorizzazione a un certo utente per accedere a 1, 2, 3 N repository per definire le caratteristiche d'accesso specifiche di quell'utente.Caratteristiche d'accesso che possono e diventano comunque abbastanza granulari e dettagliate e che permettono una gestione appunto al minimo dettaglio.Il giorno dopo il lupo arrivò alla casetta di paglia.Porcellino, porcellino fami entrare gridò il lupo ma il porcellino piccolo sapeva che era il lupo e non lo lasciò entrare ma il lupo cominciò a sbuffare stizzito e sbuffava sbuffava e buttò giù la casetta del porcellino piccolo il porcellino piccolo corse a casa del porcellino medio e si rifugiò da lui il giorno seguente il lupo andò a casa del porcellino medio e bussò alla sua porta chi è chiese tuo fratello rispose il lupo ma il porcellino medio sapeva che non si trattava del fratello e non aprì al lupo così questi sbuffò stizzito e buttò giù la casetta del porcellino medio la casetta di legno cadde e due porcellini corsero per rifugiarsi a casa del porcellino più grande.E come ben sapete in ogni parte del nostro podcast c'è sempre il momento "non è sempre oro ciò che lucica" ed ecco qua i primi problemi dei polirepo.Infatti i polirepo iniziano a dare problemi quando si scala.Per scalare cosa intendo? Scalare intendo per numeri che vanno da 10 a 100 sviluppatori che magari lavorano su 10, 100 progetti contemporanei con 10 100 release giornaliere e questi non sono neanche numeri astronomici e qui si iniziano a vedere i primi problemi, i problemi di coordinamento se noi pensiamo che il rilascio per esempio deve essere fatto con tutti i pacchetti insieme iniziamo a vedere dei problemi di orchestrazione Un altro problema è che Vanilla Git, quindi l'utilizzo di Git senza tool esterni, non ci basta più.Abbiamo bisogno di strumenti più complessi per avviare magari del testing end-to-end, quindi che gira coinvolgendo più pacchetti che stanno dentro repository diversi.Abbiamo il problema di fare delle build dove le dipendenze sono frammentate in n repository, quindi in n pacchetti e abbiamo delle difficoltà in deploy quando si parla di build abbiamo anche il problema magari di avviare più build separate una in ogni pacchetto contemporaneo così come potremmo avere dei problemi per fare delle fix particolari fix che riguardano magari due o tre pacchetti che stanno in ripositori diverse.Quindi in realtà iniziano, iniziamo a vedere i problemi di coordinamento che possiamo in qualche modo collegare all'interno della nostra storia ai problemi che si hanno quando i tre porcellini vogliono uscire insieme la sera e devono mettersi d'accordo sul luogo, sull'ora ma uno è pronto, uno non è pronto.Insomma ci sono proprio questo tipo di problematiche.Un altro problema è avere chiaro l'idea, come vi anticipavo prima, dello stato generale della nostra applicazione.Infatti, non avendo dei commit atomici, è difficile avere una visione generale di come si è sviluppata l'applicazione.Faccio un esempio.Io creo una modifica che va a incidere sul pacchetto di front-end e di back-end.sto semplificando tantissimo.Questa verifica avviene con commit diversi in stati diversi in momenti diversi nelle due repository.Non ho quindi un unico commit che mi dice ok in questo passaggio io ho modificato questi elementi portando la mia app dallo stato x allo stato y e questo è un po' insomma una difficoltà di comunicazione perché se noi non sappiamo lo stato generale dell'applicazione l'informazione che noi abbiamo rischia di essere frammentata e quindi anche parziale il rischio potrebbe essere quello.Un esempio può essere se i porcellini sono pronti o se tutte le case sono finite dovremmo andare a verificare casa per casa così come dobbiamo andare a verificare i repository per repository se lo stato di quella modifica è stato fatto o non è stato fatto quindi ci manca quel livello di coordinamento.Per ovviare a questo tipo di problemi si è inventato il concetto del monolipo.Il giorno dopo il lupo arrivò alla casa di mattoni e gridò porcellino porcellino fammi entrare ma il porcellino grande disse no non ti farò entrare quindi il lupo cominciò a sbuffare e sbuffare ma non riuscì a buttare giù la cazza.Il lupo era furibondo gridava porcellino porcellino scendere dal camino e ti mangerò.Il porcellino era spaventato ma non rispose.Dentro la casa c'era una grossa pentola sopra il fuoco del camino.L'acqua stava per bollire.Il lupo si calò dal camino.Siccome non c'era il coperchio sulla pentola il lupo vi ruzzolò dentro e finì nell'acqua bollendo.Ecco qua che i nostri porcellini implementano un'architettura monoreppo o monoripo che sia, un'architettura cioè che dentro un unico repository git contiene, git o con un altro sistema di versionamento, contiene più progetti o elementi con responsabilità diverse, linguaggi diversi, progetti e tool completamente diversi, sia di build che di test.Monoripo è una buzzword, se ne parla parecchio questo periodo, in modo anche abbastanza controverso, infatti uno dei motivi per cui ho voluto raccontarvelo usando una fiaba è proprio perché c'è questa conflittualità tipica del nostro mondo, questa faziosità.Io sono da una parte, tu sei da un'altra che secondo me non porta da nessuna delle due parti.L'approccio monolipo non è una cosa che è apparsa ieri sera, c'è già da un bel po' di tempo e tante società tra le quali Microsoft, Uber e tantissime altre lo utilizzano.Lo sforzo però principale da fare quando si parla di monoripo è quello di non confonderlo con l'approccio monolitico e adesso vediamo il perché.Intanto ogni elemento quindi ogni pacchetto ha il suo spazio separato all'interno del monoripo quindi i porcellini se dovessi metterla sotto forma della nostra fiavola, favola, fiaba forse, vivono in una grande casa che è la casa che ha fatto il porcello più grande dove però hanno a disposizione ampie stanze personali e un bello spazio condiviso.Questo fa sì che in realtà si abbia una visione olistica di quella che è la nostra applicazione cioè in un colpo d'occhio solo si ha la visione di tutti i pacchetti che vanno a giocare un ruolo all'interno della nostra applicazione.Solitamente, specie in ambiti javascript, ogni pacchetto ha la sua cartellina dentro la cartella packages e le librerie condivise vengono portate su nella cartella madre quindi viene fatto un "loisting" in modo che tutti questi pacchetti che stanno dentro packages possano accedervi.Questo è molto interessante perché da una parte teniamo l'autonomia di ogni pacchetto, dall'altra abbiamo una certa condivisione.Questo approccio, l'approccio monolipo, porta però un leggero accoppiamento tra progetti o per meglio dire il fatto che il nostro codice sia strettamente accoppiato o disaccoppiato dipende esclusivamente da come lo si scrive e lo strumento che si usa e l'architettura che si usa non aiuta a dividere i due blocchi di codice quando invece col polirepo a copiare è molto difficile perché dovresti avere accesso a quella libreria quindi te la devi mettere che ne so se lavori in javascript nel package.json adesso invece ce l'hai la sta su una cartella quindi tirarla dentro viene molto semplice per cui come vi dicevo prima vanno inseriti dei confini molto netti molto definiti e formalizzati.D'altro canto però c'è un forte incoraggiamento a quello che riguarda la condivisione all'interno non solo all'interno dei team ma all'interno di tutta l'organizzazione che sviluppa quell'applicazione in modo orizzontale.Questa condivisione porta probabilmente anche alla gestione diversa della responsabilità dei pacchetti.Quando però, e questo se volessi raccontarvelo sotto forma di storia dei maialini è che vivendo insieme si sviluppa una certa dipendenza tra maialini ma se le regole sono ferre e se gli spazi personali sono rispettati ci può essere convivenza e poi in fondo la casa è di tutti tutti si sentono responsabili di questa casa.Un altro elemento interessante è il monitoraggio dello stato complessivo dello sviluppo.Cosa vuol dire questo insieme di parole cosa vogliono dire che abbiamo la possibilità di fare dei commit atomici cioè un solo commit che contiene il tracking delle modifiche a tutta la code base dell'applicazione cosa vuol dire che se io sto facendo una modifica sto aggiungendo una feature per fare in modo che che ne so il mio negozio e e-commerce di cd di fiabbe dia la possibilità di ascoltarle anche in streaming svilupperò parte del front end parte del back end in un unico commit posso ottenere traccia delle modifiche che riguardano i due ambiti e quindi quando vado a fare un deploy io posso mantenerne anche lo stato consistente cioè sto deployando la versione che ha anche le funzionalità di streaming senza dover magari fare due deploy e stare attenti a deployare il back end a un certo livello e il front end a un altro insomma diventa un po più complessivo se dovessi raccontarvelo sotto forma di fiaba dei porcellini vi dico che quando i tre porcellini decidono di rifare l'impianto di riscaldamento alla casa del porcellino più grande la rifaranno una sola volta per tutti quindi chiameranno un termo idraulico lo pagheranno una sola volta ed ecco qua che fanno appunto un commit atomico.Un altro elemento particolare dei monorepo è la parte riguardante il coordinamento della fase di building e la fase di deploy.Avere in un unico posto la possibilità di gestire le dipendenze ci mette in condizione di limitare quella cosa che molti chiamano la dependency hell, l'inferno delle dipendenze, spesso caratterizzato appunto dalla difficoltà di gestire pacchetti diversi con dipendenze magari condivise o non condivise con versioni diverse della stessa dipendenza infatti c'è il famoso problema che si chiama daemon the dependency quando un pacchetto ha bisogno di altri due pacchetti i quali usano a loro volta delle dipendenze e questi due pacchetti diciamo utilizzano due versioni diverse della stessa dipendenza, due versioni diverse di React e qua abbiamo un problema invece centralizzando le dipendenze riusciamo a tenere traccia e diciamo ok quando vuoi utilizzare React prenditi questa versione di React sia che tu sia il pacchetto A che tu sia il pacchetto B.Questa cosa è molto interessante perché in realtà con i sistemi moderni abbiamo la possibilità di dire al pacchetto che stiamo sviluppando in ambito monoripo ok prendi questa versione che la versione condivisa oppure tu hai bisogno di una versione specifica perché hai alcune caratteristiche particolari per cui non faccio loisting quindi non faccio risalire il pacchetto di cui ho bisogno alla parte condivisa ma me lo tengo solo per quel sottopacchetto e questo è molto interessante e infatti è un esempio sempre riportando lo sotto forma della nostra fiaba è che quando i maialini vanno a fare la spesa comprano una sola volta la scopa e la paletta.Altra particolarità collaborazione e ownership.L'ownership del codice risulta condivisa quindi non c'è più quel elemento tipico dello scaricabarile "eh ma questo pezzo di codice non è mia responsabilità perché appartiene al team B io non ho accesso suo repo quindi non posso fare quella fix che è magari mettere un punto e virgola o cambiare il nome a una variabile quindi in questo caso invece avendo tutti accesso a tutta la codebase ci si sente un po tutti responsabili e quindi fare questo tipo di operazioni magari non distruttive molto rapide ma che permettono di andare veloci risulta molto semplice in un contesto monoripo e l'esempio esempio sempre riportato al mondo dei tre porcellini può essere che tutti i maialini si sentono e sono padroni di casa e questo incoraggia la collaborazione.Accesso.Vi ricordate quando ho parlato di polidepo e ho detto che era molto semplice accedere a definire delle regole d'accesso granulari per gli utenti per chi ci lavora su quelle codebase? Bene, gestire l'accesso in contesti monoripo diventa complesso perché perché solitamente gli strumenti che noi utilizziamo hanno delle funzioni per gestire le ownership che sono molto limitate.Basti pensare a Github ti permette di accedere in lettura e scrittura un repository ma non dà per esempio un accesso granulare alle cartelle.Per ovviare a questo problema società come Google che da tanti anni utilizzano un approccio monoripo tanto che tutta la code base di Google che se non sbaglio dovrebbe aggirarsi attorno agli 80 terra sta in un unico repository aiuto, dicevo Google ha sviluppato degli strumenti che potessero aiutarli a a gestire l'accesso parziale a questa repository.Il nome di questo strumento è Piper, però qua mi viene da chiedermi, ma allora se tu stai gestendo l'accesso a questa monoripo non inizia a sembrare un poliripo? La domanda che adesso io mi vado a fare è...Ma i porcellini, vivendo nella stessa casa, sono davvero al sicuro da se stessi e dai nuovi lupi? Eh, in realtà probabilmente no.così come i monoripo portano con sé tutta una serie di problemi.In primis problemi relativi al tempo.Un monoripo che contiene una codebase che scala è anche un monoripo che rapidamente diventa grosso.Diventa grosso e se parliamo di google parliamo di 80 tera quindi diventa anche difficile scaricarlo.Immaginate di fare una clone di questo repository.Abbiamo dei problemi di tempo perché appunto la dimensione diventa enorme.Abbiamo quindi anche dei problemi di dimensione.In primis lo spazio su disco.In secondo tempo il problema della ricerca all'interno del codice che poi, era anche il problema che si aveva con i pulli di POM per questo si sono sviluppati una serie di strumenti che potessero aiutare lo sviluppatore a cercare su più codebase su grandi codebase in terza battuta abbiamo sempre riguardante dei problemi di dimensioni problemi di performance della rete nello scaricamento ed ecco perché aziende come google e come microsoft hanno sviluppato degli strumenti mi viene in mente il virtual file system di microsoft che permettono lo scaricamento selettivo queste sono aziende che hanno dei code base enormi spaziali delle code base enormi spaziali e che hanno bisogno di permettere agli ingegneri di lavorare senza doverla scaricare tutta e quindi c'è questo questi strumenti di virtual file system che aiutano a lasciare nella rete alcune parti della code base e a continuare a lavorare in modo abbastanza pratico.Abbiamo dei problemi relativi all'onboarding di nuovi dipendenti immaginate quando arrivano dei nuovi dipendenti si trovano a dover entrare in una società che gli mette in mano una codebase grande.Codebase grande vuol dire tanto codice, codebase grande vuol dire una cosa difficile da imparare a maneggiare senza romperla e quindi c'è un attrito iniziale.Abbiamo dei problemi che riguarda il coordinamento della fase di building, specie se all'interno del monoripo ci sono dei linguaggi e delle tecnologie diverse.Per ovviare a questo problema o quantomeno per superarlo si è pensato di sviluppare Bazel.Bazel è un tool di fatto da casa google che serve appunto che è servito e serve per le building nei monoripo di google e che è stato rilasciato con licenza open source quindi è possibile vederlo ne parleremo tra qualche minuto.Abbiamo dei problemi di accesso come vi dicevo prima quindi siccome la nostra società magari non vuole permettere a tutti di avere l'accesso su tutto beh abbiamo bisogno di sistemi di ACL pochino più evoluti per questo Google ha sviluppato Piper che dà una mano a livello interno proprio a gestire gli ambiti d'accesso.Abbiamo dei problemi di isolamento, l'ho accennato prima, è facile cadere nella trappola dell'accoppiamento quando tu hai a disposizione nella cartella a fianco la libreria che ti serve.Quindi il nostro codice rischia di diventare facilmente un monolita per cui dobbiamo veramente stare molto attenti a non accoppiare.Abbiamo poi dei problemi legati all'ownership.Prima vi ho decantato la ownership in ambito monolipo come una cosa che stimolava la collaborazione aziendale.Verissimo.Però c'è un ownership diluita cosa vuol dire? Che è vero che tutti si sentono un po' responsabili di ogni pacchetto ma il problema è che nessuno sente il padre o il padrone di quel pacchetto quindi si entra nei meccanismi di ok io sono impegnato fallo tu ma spesso quel falluto viene detto a chi non ha le competenze per poterlo fare quindi come vedete anche l'approccio monoripo ha diciamo i suoi punti di debolezza.Ma allora qual è il morale della favola? Il morale della favola me lo suggerisce Mark Klein di Lyft.Lyft è la Uber, l'antagonista principale di Uber americano.Cosa dice? Lyft ha scritto un bellissimo articolo che vi linko nelle note dell'episodio dove dice perché non voglio usare i monolipo fondamentalmente ma in realtà fa una chiusura dell'articolo che è molto molto interessante e molto precisa e puntuale.Quando si scala, questo è quello che dice Mark Klein, quando si scala solitamente tutti i vantaggi che sono decantati per il monoripo vengono diciamo in qualche modo depotenziati da quelli che sono gli svantaggi o le problematiche quelle che vi ho appena elencato che in ambito enterprising in contesti molto grandi si sentono in modo molto forte per cui fondamentalmente il concetto è che la complessità non si elimina la complessità si sposta per cui tutti i problemi che i monoripo devono risolvere quando scali sono esattamente gli stessi problemi che i poliripo devono risolvere quando scali i problemi da risolvere sono per esempio l'accoppiamento l'effort per andare ad andare oltre i limiti dei sistemi di versionamento.Quindi la domanda che si fa Mark Klein e che mi faccio anch'io è allora perché scegliere una soluzione piuttosto che un'altra? Scegli una soluzione piuttosto che un'altra a seconda di come sei magari strutturato a livello aziendale.Scegli una soluzione piuttosto che un'altra perché magari hai una problematica che incide la senti di più rispetto a un'altra per esempio se non hai bisogno di isolare alcune parti di codice gestendo l'accesso probabilmente i monoripo potrebbero essere una soluzione molto pratica da implementare ma se poi ai monoripo ci metti anche la complessità di gestire un accesso parziale o accesso selettivo tutto diventa particolarmente complesso ma questo è un esempio potrei farvene tanti altri per cui allora quello che dice Mark Klein è alla fine non c'è una tecnologia che dice ok adesso ci sono i monoripo i poliripo sono superati no perché tutte le problematiche che abbiamo affrontato riguardano lo scalare in un'azienda e quanto un'azienda riesca a scalare o meno non dipende dai tool che si usano quantomeno non dipende solo dai tool che si usano ma dipende strettamente dalla cultura e dalla leadership aziendale che insomma sono questi elementi che delineano poi quanto l'azienda riesca a scalare o meno per cui monoriipo, poliripo sono solo problemi diversi che gli architetti e gli ingegneri devono affrontare ma sono problemi che raramente riguardano lo scalare quando si scala in termini seri.Quello che invece fa la differenza è la leadership e la cultura aziendale.Io sposo a pieno la posizione di Mark penso che si debbano fare delle valutazioni specifiche e smetterla di fare delle guerre di partito, delle tifoserie da stadio e iniziare magari a ragionare un attimino in più sulle caratteristiche e su che tipo di problematiche vogliamo portarci.Naturalmente non posso terminare qua l'episodio senza dare un qualche minuto al nostro momento paese dei balocchi Tra i giocattoli che vi ho portato questa settimana ci sono quattro elementi io lo so voi siete amanti dei giocattoli e spesso questo tipo di puntate più legate agli approcci e alle tecniche potrebbero non affascinarvi per cui c'è sempre il regalino che in qualche modo ci rende felici.Sono quattro strumenti che servono per gestire prevalentemente la complessità in ambito monoripo.Il primo è Octolinker che un po' si distingue dagli altri perché diciamo che è pensato per essere utilizzato in ambito poliripo quindi con più repository.Cosa fa Octolinker? Octolinker non fa altro che è un'estensione di Chrome che fa sì che nel vostro codice quando fate l'import di certe librerie vi metta direttamente il link ai repository di quella libreria.Funziona con un pacco di linguaggi JS, Docker, Haskell, Ruby, Rust, PHP e chi più è ne ha più ne metta.Quindi è una semplice estensione, una volta installata, quando andate a esplorare il codice su GitHub basta fare click sulla libreria e siete direttamente portati alla pagina, al repository di quella libreria specifica.Il secondo tool di cui voglio parlarvi, questa ragione in ambito monolipo e si chiama Yarn Workspaces.E' integrato nelle ultime versioni di Yarn e serve per portare il concetto di monolipo in ambiente javascript.Come vi dicevo è una funzione nativa di Yarn e permette un facile setup e gestione delle dipendenze in ambito monolipo.Voi create una cartella, lanciate Yarn Workspace, fate il package.json del vostro workspace e a questo punto avete una cartella dove mettere tutti i pacchetti della vostra applicazione.Pacchetti che avranno poi al loro interno il loro package.json specifico, quindi il loro file di dipendenza.Ma quando noi andremo a fare l'install delle dipendenze, diciamo tutte le dipendenze risaliranno in un'unica cartella node modules e all'interno delle cartelle di sottoprogetti ci saranno i sim link che permettono appunto al sottoprogetto di accedere alle dipendenze condivise.Una cosa molto interessante, un tool che io sto provando da un po' ed è particolarmente carino da un po' poco, un po' meno di una settimana, è carino tanto che sto provando a portare alcuni progetti proprio in ambito monolipo.Vediamo se ci riesco perché in realtà ho qualche problema con i progettini lambda di amazon però visto che ci sono dei plugin quindi vedremo un po' come fare.Altro tool che voglio portarvi è Learna probabilmente ne avete sentito parlare Learna è uno strumento che serve a gestire il workflow in ambito monorepo.Learna tra l'altro gestisce anche l'installazione delle dipendenze ma può collaborare con Yarn, lo vediamo dopo.uno dei pacchetti che tutti usiamo e che utilizzano a sua volta l'Erna è Bubble ma oltre a Bubble c'è davvero una pletora di altri repositori che sono gestiti utilizzando l'Erna che ci aiuta a gestire sia le versioni semantiche della nostra applicazione sia che noi vogliamo che ogni pacchetto abbia la sua versione o vogliamo che ogni pacchetto segua un unico numero di versionamento e ci aiuta volendo anche al deploy e all'invio dei pacchetti su npm con un unico comando noi possiamo lanciare i nostri pacchetti su npm tutti in una sola volta questa cosa è molto comoda così come ci permette magari di avviare tutta la parte di building direttamente appunto su tutti i pacchetti.Vi dicevo che Learn di per sé gestisce l'hoisting quindi la condivisione delle dipendenze comuni ma la vedo spesso utilizzato in collaborazione con Yarn Workspaces.Il compito di Yarn Workspaces quindi è quello di gestire l'installazione e il Simlink quindi la possibilità appunto ai pacchettini di accedere alle librerie condivise e delegare quindi a Learn la gestione del versionamento del publishing su NPM.Questa cosa è molto carina, vi metto naturalmente tutti i link nelle note dell'episodio per cui se volete andare a buttarci un occhio ecco trovate tutto là.Per finire un pezzo veramente importante stiamo parlando di Bazel nato come tool interno a google per il building dell'applicazione in multilinguaggio strappato dalle costole di google e rilasciato open source perché necessario ad angular.Tra l'altro è anche uno anzi è anche il sistema di building utilizzato per buildare oltre che angular anche tensorflow dovendolo immaginare dovendogli dare insomma una forma che un po tutti conosciamo immaginate un make on steroids che però permette di fare la building multilinguaggio e la sua vera particolarità è che è super ottimizzato, ha una gestione delle dipendenze eccezionale perché in realtà gestisce sia dipendenze che build in modo riproducibile ispirandosi alla programmazione funzionale quindi cosa vuol dire che da un certo contesto io otterrò sempre la stessa build.Come lo fa? I nostri pacchetti hanno dei numeri di versione però se vogliamo avere una build precisa dobbiamo riferirci a un commit specifico di quella build e con Bazel è possibile indicare appunto il commit hash delle dipendenze per avere esattamente quei file in quel modo.Questo fa sì in realtà che la build possa essere anche incrementale quindi non debba buildare tutto a un cambiamento e questo è uno dei problemi che abbiamo tipici appunto dei monolipo e che la build possa essere fatta in modo parallelo.Tra l'altro ha dei sistemi di DAG quindi di Directed Acyclic Graph che permettono appunto un'ottimizzazione precise e puntuale della fase di building.Ma come funziona Bazel? Bazel carica un build file nel build file viene indicato il target quindi il pacchetto da buildare analizza le dipendenze di questo target crea un grafo aciclico in modo da vedere se ci sono delle dipendenze che dipendono da una dipendenza e che sono dei loop ottimizza questo grafo aciclico e compila solo il codice che in realtà è cambiato.Crea un action graph così ed esegue la build solo degli elementi risultanti e questa cosa è molto molto interessante tanto che è utilizzata, Bazel è utilizzato in tantissimi ambiti e se non mi sbaglio un'applicazione in java che però utilizza nella scrittura dei suoi file di configurazione quindi sui build file un linguaggio molto simile al python.Io ci ho buttato un occhio ma non ho approfondito tantissimo quindi magari se c'è qualche esperto ci facciamo una chiacchierata su Bazel direttamente nel gruppo telegram.Spero che questo episodio vi sia piaciuto è un buon esperimento infatti mi piacerebbe avere i vostri feedback per capire se continuare a svilupparlo e trasformarlo in un talk oppure prendere un'altra direzione per farlo mi raccomando gruppo telegram e ne parliamo di lì prima però di lasciarvi come sempre mi tocca ricordarvi i nostri contatti info@gitbar.it come email oppure www.gitbar.it dove trovate insomma tutte le informazioni puntate trascrizioni e quant'altro.Su twitter l'handle per parlare con me è @brainrepo e naturalmente lo ripeto per l'ennesima volta gruppo telegram dove iniziamo a essere in tanti quindi iscrivetevi, chiacchierate, cresciamo tutti insieme.Fondamentalmente, Gitbar è un bar degli sviluppatori.Diciamo che io sono quello che parla un po' di tutti, parla un po' più di tutti nella committiva.Insomma, quello che spesso dice "No, c'è Mauro, lasciamolo là, parla troppo".Però, Gitbar, diciamo, è il nostro punto di incontro.Quindi, se volete qualcosa in più rispetto all'episodio, se volete approfondire o semplicemente parlare di fesserie, noi siamo là.detto questo io vi ricordo che se l'episodio vi è piaciuto mi raccomando iscrivetevi col vostro client di podcast preferito se vi è piaciuto davvero tanto lasciate una recensione su podcast, apple podcast o itunes insomma.questa recensione ci aiuta a crescere un attimino in termini visibilità e quindi toccare ancora più orecchie.Io vi saluto, vi do appuntamento alla prossima settimana, sempre con Gitbar, sempre qua sul nostro podcast e nulla, alla prossima! Ciao! Ciao! Gitbar, il circolo dei fullstack developer.Una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web, di metodologie ed strumenti immancabili nella cassetta degli attrezzi dei Full Stack Dead.
