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 e benvenuti su Gitbar, nuova settimana e nuovo episodio e in questa line up super super concitata non ci fermiamo e insieme a noi abbiamo un nuovo ospite più che ospite direi che è quasi un coinquilino di questo podcast perché è venuto già a trovarci un'altra volta ma prima di svelarvi il nome voi lo sapete tanto questa parte sono sicuro che la schippate direttamente dal vostro client di podcast ma io ve li devo ricordare quindi un minuto per ricordarvi rapidamente i nostri contatti.Info@gitbar.it per contattarmi via mail oppure @brainrapper su twitter oppure il nostro gruppo telegram che trovate semplicemente cercando @gitbar.Ma bando alle ciance una piccola pausa e iniziamo subito il nostro episodio.Eccoci qua, eccoci qua.Oggi si parla di Laravel, il framework più controverso, credo, dell'universo.Subito dopo CakePHP c'è Laravel.E questa chiacchierata la facciamo con Leonardo Rossi.Ciao Leo, come stai? Ciao, ciao Mauro, sto bene, ciao a tutti.E come stai? Diciamo che alla grande, tra l'altro ci stiamo preparando per fare la live di celebrazione del primo compleanno di Gitbar che sarà tra i primi giorni del 2021.Tu ci sarai? Ci sarò, sicuramente, di sicuro non sarò fuori casa, non posso esserci quindi.Ok, Leo però noi ti vediamo nel nostro gruppo telegram anche abbastanza attivo ma chi è Leonardo Rossi? Chi è Leonardo Rossi? Bella domanda.Io sono uno sviluppatore anche se dire solo sviluppatore ormai non si usa più quindi sono un software ingegnero o qualcos'altro.Sono di Firenze, lavoro per NearForm che non so se te conosci lavoro per NearForm dove noi diciamo facciamo sviluppiamo software per aziende medio grandi o governi eccetera.Lavoriamo in Node.js, io faccio un po' sviluppatore, un po' faccio il DevOps e infatti sono qua a parlare di Laravel.Cosa ci fa uno sviluppatore Laravel su NearForm che è una società che usa tantissime tecnologie ma Laravel non è una di queste? Faccio, dato che chiunque quando smette di lavorare poi fa altro e io quando smetto di lavorare lavoro su Laravel per i miei progetti.Diciamo che io ho dei progetti personali, dei side project, che quando devo sviluppare qualcosa full stack io uso l'Aramel.L'ho conosciuto qualche anno fa, c'era stato 2015-2016, mi è piaciuto subito il modo, seguito chiaramente di tutorial, mi è piaciuto il modo in cui veniva portato lo sviluppatore a sviluppare velocemente un'applicazione.Avendo provato altri framework prima in una maniera più per lavoro che per altro, quando ho visto Laravel ho detto "quà si riesce a sviluppare molto velocemente, da subito" e quindi ho cominciato a interessarmi e da lì ho iniziato poi a fare anche dei corsi, ho fatto lo speaker a Laravel Day, quindi ho cominciato a conoscerlo meglio ed è per questo che appena smetto di lavorare mi metto a lavorare su Laravel Day.Il tuo lavoro di tutti i giorni tu fai DevOps, Ingenieur, ma trovi tra questi due mondi, il mondo dello sviluppo su Laravel e il mondo che ti vede coinvolto tutti i giorni dal punto di vista lavorativo, quindi nell'ambiente DevOps, trovi dei punti di contatto tra questi due mondi? Sicuramente il codice dell'Aravel da qualche parte deve girare, ne ho parlato già recentemente con un fiorentinissimo ospite, che ora non mi ricordo.E quindi sì, io trovo quel punto di contatto, nel senso che secondo me sono mondi molto separati, anche le tecnologie che si sviluppano per scrivere codice per l'infrastruttura non hanno niente a che fare con l'Aravel o comunque con dei framework per lo sviluppo web, per per cui io mi sento molto separato tra le cose che faccio.Poi in realtà in NearForm si sviluppa moltissimo Node.js, anzi diciamo la nostra tecnologia principale è Node.js, siamo anche...pare che il 70% dei commit che entrano in Node.js hanno subito una review da parte di qualcuno di NearForm, non so se è vero o se è un clip, però immagino di sì.Per cui per me sono proprio mondi separati, non credo l'Arable potrà mai entrare in NearForm perché non è una tecnologia che forse è adatta, magari ci arriviamo poi durante il discorso, ai progetti che facciamo all'interno di Miracle.Secondo te cos'è che ha dato un boost così forte all'adozione di Laravel? Perché se ci guardiamo in giro secondo me dovremmo fare una nuova linea di magliette "Laravel is the new WordPress", nel senso che ha un livello d'adozione altissimo.Cos'è che spinge questo livello d'adozione di larva e specie in contesti come agency? Allora io ti racconto un po' la mia la mia esperienza.Io uno dei primi lavori che ho fatto ancora, che erano ancora all'università, era un lavoro su Rails.Io non avevo mai visto framework eccetera.Mi metto a fare questa cosa qua e cominciò insomma a documentarmi, a guardare e vedevo tutta questa questa magia, queste cose che succedevano scrivi tre righe a fare una pagina, il router, non lo so io andavo avanti perché comunque c'era da portare a casa il lavoro e non mi sono mai interessato però mi rimaneva sempre e ho avuto sempre un po' questo questo bias del usare un framework mi nasconde tante cose sotto che per me era quasi un problema che poi sono uno molto curioso che vuole capire come funzionano le cose però non c'era tempo per fare per fare entrambe cose.L'Aravel è stato il primo dove io ho cominciato a guardare dentro perché le cose funzionavano, c'era molta magia però ho detto ora ho anche esperienza di altri framework, andiamo a vedere cosa c'è sotto e ho avuto una specie di illuminazione ma non perché si tratta di l'Aravel, probabilmente avessi usato Symfony, mi sarebbe successo con Symfony, però in quel momento stavo usando l'Aravel e ho cominciato a guardarci dentro, ho capito come funziona, ho capito alla fine sono solo file PHP che vengono caricati e eseguiti, come quelli che scrivevo io, però scritti meglio, scritti parecchio meglio.Allora io ho detto "ok, si riesce a scrivere applicazioni velocemente?" Mi sono legato a questa tecnologia.Cioè a quel punto ho detto "creo una expertise su Laravel e faccio tutto in Laravel".E devo dire non mi sono mai pentito, forse perché non ho mai raggiunto i limiti che Laravel magari raggiunge, ma perché Laravel è studiato per chi si approccia inizialmente a un framework per farlo lavorare subito.È vero che c'è tanto magic dentro, poi magari ne approfondiamo, però per me è stato il primo in cui ho cominciato a capire, ho cominciato a seguire il percorso del codice e ho detto "ah, ecco perché funziona", perché poi alla fine della fiera in fondo c'è un eco, cioè quando te vedi, fai un avvio, ho fatto un talk sul il request cycle di Laravel.L'ultima riga è un echo, ecco dell'output che ha generato prima, quindi non è che succedono cose particolarmente ganze, semplicemente è un echo, però è tutto quello che succede prima che ti aiuta a arrivare velocemente alla tua pagina.Per ecco da programmatore PHP dobbiamo immaginare una print line, una print di qualcosa.Scusa se faccio questo inciso ma perché potrebbe...Devo dire che condivido in buona parte quello che hai detto e credo che in realtà molto di questa scoperta fondamentalmente è data dal fatto che si è cercato di utilizzare un framework con un approccio un pelino consapevole che può essere l'Aravel che per me poteva essere Symfony, il mio grande amore con Symfony ormai è risaputo però allo stesso tempo l'Aravel porta con l'elemento che tu hai detto molto chiaramente che l'elemento della produttività e da ex manager o comunque da persona che si è occupata di management questa produttività non posso nasconderla.È vero è però anche che una volta che hai sviluppato qualcosa la produttività iniziale rischia di portare con sé anche un certo debito tecnico quindi alcuni limiti che in realtà il framework porta.C'è un momento nel momento in cui la produttività cessa iniziano a mostrarsi, a facersi alla finestra tutta una serie di limiti ma spesso come bene hai detto tu questo punto è talmente avanti nel ciclo di sviluppo che probabilmente per come è concepito il prodotto che stiamo andando a realizzare non lo toccheremo mai.Voi perché quello che stiamo siamo un agency per esempio io vedo che l'Aravel è utilizzato tantissimo dalle web agency che piano piano si stanno e si sono liberate dell'amico WordPress che devo dire sta cercando di svecchiarsi questo lo ammetto e per la dinamicità che un framework rispetto a un CMS può dare insomma l'Aravel può essere la scelta migliore in quel contesto.Naturalmente se io devo fare il sito di...adesso sto banalizzando...la web application per il booking di un hotel è solo di quell'hotel, io con l'Aravel me la faccio alla velocità della luce facendo un lavoro ben fatto e che probabilmente non toccherà mai i limiti.Se devo invece avviare una startup che dopo un X di tempo cresce e alla fine ci metto dentro 40 backender che lavorano sulla Ravel, forse questo limite lo vado a toccare se la mia applicazione cresce anche perché la Ravel porta con sé un approccio che è quello monolitico poi l'andremo a vedere no? è monolith by design come si suol dire che noi siamo tutti fighetti no? ci diciamo monolith a brutto monolith a brutto monolith sta producendo reddito come vedremo poi parlando del del fondatore di laravel.E poi i microservizi sono monolith piccolini Comunque l'esempio che hai fatto te della startup è vero che a un certo punto deve raggiungere, però proprio nel concetto della startup è produci velocemente qualcosa, fai vedere qualcosa agli investitori e se usi l'Arvel lo fai vedere prima, poi hai tutto il tempo, una volta che hai il budget visto che poi lo devi far vedere per prendere più soldi a quel punto puoi prendere alcune decisioni e non usare tutto l'Arvel ma da quello che ho visto non ho esperienza diretta però ci sono tantissimi business che girano sull'Arvel con tante visite con tanto fatturato quindi bisogna diciamo bisogna vedere l'Arvel va bene per parecchi di noi secondo me.Eh sì è stato da noi ospite Marco Risi di Everly supermercato 24 loro non sono una piccola startup hanno un parametro di crescita molto alto, il loro back end si basa sull'Aravel.Il vero è che a certi livelli poi o ci butti giù di customizzazioni oppure inizi a staccargli le costole a trasformare le microservizi oppure trovi delle soluzioni.Però è un'ottima base di partenza.Ma il vero valore, ne parlavamo in privato con con Leonardo, è quello dell'ecosistema.Ad oggi Laravel ci mette a disposizione un pacco di roba, no? Servizi tra l'altro molto diversi tra di loro perché si passa da fare login con i social a hostare un'applicazione Laravel serverless su lambda.Tutto all'interno, oppure avere degli admin panel, oppure avere un back-end per la fatturazione, non lo so.Quindi ci sono tantissimi progetti che girano intorno all'Aravel che dovrebbe rimanere diciamo nell'intenzione almeno, nel mio intenzione dovrebbe rimanere un framework per lo sviluppo applicazioni web più questo ecosistema in realtà poi secondo me ci stiamo spostando verso un'altra cosa poi ne parliamo.Esatto io credo che l'ecosistema di l'Aravel sia una cosa fighissima è una cosa che pochissimi altri framework riescono a mettere a disposizione, forse Rails, ma pochi altri credetemi.Il fatto di Laravel difregarse quasi di molti pattern, molte buone pratiche, ha permesso di creare una serie di elementi fortemente accoppiati con un pacco di magia ma che davvero con pochissime righe di configurazione che bisogna scrivere direttamente in php senza tirarci dentro xml, yaml, json o quant'altro tu hai un'autenticazione che può essere vuoi fare le cose complesse ok hai tutto un sistema che ti mette a disposizione l'out2 vuoi fare le cose semplici hai un'altra cosa che con due righe ti dà un token, l'emissione di un token, sanctum no? ti dà l'emissione di un token come sullo stile github che poi puoi integrare direttamente col tuo frontend che lo richiede attraverso una chiamata Ajax.Hai tutto un sistema di notifiche out of the box, cioè veramente con tre righe di configurazione tu puoi mandare un sms un email oppure una notifica push perché ci sono i driver di tutto e li configuri davvero in un modo stupidissimo.La ricerca, scout.Cioè è bellissimo.Quattro righe sul tuo model, cioè sulla tua struttura del dato che devi andare a salvare sul tuo database e tu c'hai quel dato già cercabile magari con sistemi come elastic search.Indicizzato.Con Algolia.Ancora meglio non ti devi sbattere a tirare su Laravel, questa è la cosa figa di Laravel, ma prendi direttamente al Golia, lo paghi x euro al mese o gratis e hai la ricerca out of the box.Ma potremmo rimanere quarti d'ora.Tu hai avuto modo di vedere nova invece il sistema per la generazione dei pannelli di controllo? L'ho visto, non ci ho lavorato, ma l'ho visto, ne ho sentito parlare bene, molto bene.Effettivamente quello è un problema comune a tutti perché alla fine quando hai dei modelli di utenti, diciamo, tu hai una lista di utenti, per fare un esempio che tutti possono capire, è chiaro che il pannello di amministrazione dell'utente tendenzialmente sarà sempre quello, soprattutto all'inizio, c'è la lista di utenti, crea, modifica, cancella.Quindi Nova ci aiuta semplicemente dicendogli "guarda, questo è un modello" e lui si va a prendere già tutte le informazioni per darti quella tabella paginata, ricercabile.È chiaro che quello è un aiuto per tutti fondamentalmente, perché tutti vanno a scrivere poi la stessa tabella.Quello che...volevo un attimo inserirmi nel discorso dell'ecosistema.Hai perfettamente ragione, il problema nasce quando c'è una barriera di ingresso molto bassa per sviluppare sull'Arable e questo porta tante persone a usarlo in una maniera magari non corretta perché diciamo guarda è facilissimo usare elastic search utilizzando scout.Sì poi magari la query di elastic search non è ottimizzata ma questo è un problema che uno se lo deve levare dalla testa quando usa l'arabel nel senso che l'arabel ti permette di averlo intanto.C'è una grossa diatriba, probabilmente ne parliamo dopo, di eloquent.Eloquent ha lo stesso approccio, cose semplici che funzionano non ottimizzate non omitire quasi non ottimizzate by design perché se le ottimizzi vai a complicarle e quindi levi il diciamo il punto cardine di sviluppare con l'arabe.Tu hai una serie di mattoncini che veramente puoi incastrare l'uno con l'altro con la minima frizione assoluta c'è da dire che però questo è un trucchetto vecchio secondo me Taylor Orwell all'inizio della sua vita era un marketer non me lo leva nessuno dalla testa.Anche in questo periodo.Ha avuto una parentesi come sviluppatore piuttosto redditizia.No sai perché? Perché stiamo parlando di ecosistema no? E io vedo che in realtà Laravel funziona così.Dimmi se l'esperienza che hai avuto tu con Laravel, io ho un paio d'anni che lo uso in alcuni progetti in produzione, anche abbastanza grossi con delle discrete soddisfazioni l'ho già detto nel podcast ci ho tirato su un business che sta funzionando fatto completamente su Laravel e dopo un po di tempo non ho ancora avuto il ben che minimo problema devo dire la verità pur avendolo fatto con la supponenza di chi diceva sto usando una schifezza Però la Ravel nella mia esperienza all'interno dell'ecosistema è stato così cioè è la prima confezione delle Lego che è le famoso Lego City dove hai i mattoncini base e tu puoi costruire questo elemento super veloce poi hai lo scaffale del negozio con le altre Lego e ti dicono ok al posto di costruirti che ne so la casetta, cioè la casetta già pronta tu le incastri ancora più velocemente e hai un boost di produttività.Al posto di costruire l'omino coi mattoncini prendi direttamente l'omino lego e quello è il secondo livello dato appunto dai servizi e dagli strumenti avanzati come Nova per generare lo scaffolding di un sistema crude avanzato e poi sul crude mi piacerebbe fare un ragionamento con te sapere come la pensi ma anche Spark io mi sono innamorato di Spark cosa fa Spark? Spark ti permette di andare a creare una struttura lo scaffolding di un'applicazione per offrire servizi online dove hai già configurato il sistema di utenti il sistema di abbonamenti con i metodi di pagamento già pronti tu devi mettere la tua API, la chiave di Stripe ed è già tutto configurato.I gruppi, l'autenticazione delle app è tutto pronto e ci devi mettere dentro solo la logica di business con l'unica cosa è che in realtà è che questo non è gratis ma devi pagare un upfront che ha senso funziona perché ci stai tirando su il tuo business però ecco la struttura dell'ecosistema di Laravel rispetto ad altri ecosistemi, ad altri framework è così, cioè un bel playground alberato con le papperelle di gomma super figo, quando però vuoi entrare nella sala giochi apri il portafoglio.Hai percepito la stessa situazione? Sì, è anche un...diciamo non un punto di discordia, però la community si scontra un un po' su questa cosa, sul fatto che Taylor Oatwell alla fine ci fa i soldi con l'Aravel fondamentalmente, il che io non ci vedo niente di male perché lui fornisce dei servizi, lavora sull'Aravel, dà praticamente tutto gratis perché il suo framework è tutto gratis e se fa dei servizi a pagamento, beh, che problema c'è? Nel senso, ottimo Spark per esempio per gestire la subscription, te lo puoi fare in casa, sì, quante ore ci perdi farlo oppure uso in servizi esterno che potrebbe essere charge bi per esempio mi sembra comunque ci sono dei servizi che tramite via gli dici guarda fammi una nuova subscription che vengano pagati o magari prendono la percentuale sul transato e alla fine che differenza c'è pagare un servizio a un ora perché perché magari qualcuno ce l'ha con Taylor per varie varie questioni e allora diciamo non ti voglio dare i soldi anche per questa cosa fammelo gratis così come ha fatto Laravel.Ma onestamente io se il servizio funziona lo pago volentieri.Se è integrata all'interno di Laravel, parliamone, perché comunque hai un lock-in molto forte, cioè questo ecosistema porta dei vantaggi, però poi alla fine quando cominci a dire "ok adesso dobbiamo passare a un altro sistema di fatturazione invece di usare Spark" e devi sganciarti da quella cosa che ha inserito così bene e levarsi a volte può essere più doloroso però quella è una scelta che deve essere fatta prima.Ripeto la scelta la semplicità nel attivare una cosa ha sicuramente dei disvantaggi da un altro punto di vista.Sì, sempre il concetto della coperta corta.Esatto.Però dal mio punto di vista adesso sono un po' fissato questo periodo su Spark e sulla possibilità di lanciare dei software SAS così alla velocità della luce e credimi difficilmente ho trovato se non dei servizi proprio degli scaffolding già pronti per fare questo e secondo me il vero valore per chi come me viene dal management che magari ha 100 euro in più in tasca e 50 ore in meno da dedicare alla cosa.Avere queste cose rischia di affascinarti talmente tanto che metti in secondo piano tutto quello che dicevamo prima di complessità di debito tecnico di quant'altro che potresti portarti appresso.Vero è che però questo debito tecnico esiste e che molti parlano di antipattern, cioè di Laravel come diciamo il covo degli antipattern.Dal tuo punto di vista com'è oggi la situazione su Laravel? Allora, fondamentalmente si parla di tre problemi.Uno è Eloquent, che sarebbe l'ORM, cioè quella parte di codice che si occupa di scrivere sul database i tuoi modelli in una maniera ovviamente alla laravel quindi molto frictionless fai save e viene salvato in qualche maniera nel database quindi eloquent è un punto di discorso alle facade merita un discorso a parte e le macro questi sono da quello che ho visto cioè anche usando le effettivamente quando vado a parlare delle facade ai corsi dico ragazzi io io ve le spiego però ci sono grossi problemi con questo.Partiamo da Eloquent.Il problema principale è che, anche per delle query abbastanza semplici, non è ottimizzato.Nel senso che gestisce molto bene le relazioni e tutto, però faccio un esempio banale.Uno ha gli utenti con i post fatti da quell'utente.Se uno vuole stampare in una tabella l'utente, il nome dell'utente e i post, Eloquent fa due query, cioè non fa la classica join, col count che uno potrebbe fare.Qual è il punto? Eloquent per stessa missione di Taylor è fatto per funzionare in una maniera semplice e risolve problemi semplici.Se uno deve andare a fare delle join complicate o comunque andare a prendere dati da più, Eloquent non fa per lui.O meglio, deve cominciare a scriversi le SQL, cosa che si fa tranquillamente con Eloquent, cioè invece di usare i modelli dice guarda fammi questa query e tirami fuori questo oggetto, si può fare.Hello Quint aiuta nella stragrande maggioranza dei problemi che ci sono all'inizio, cioè non ha bisogno di sapere quali sono i campi del tuo modello, basta che te lo metti e lui prova a salvarlo e al limite ti ritorna l'errore SQL.Gestisce le relazioni, se te rispetti i nomi che lui si aspetta, delle tabelle, con due righe gli dici guarda questo utente ha anche i post, questo utente anche i commenti, il post a un autore che è un utente, lo fai in tre righe e tutto funziona in una maniera un po' magica, però funziona e funziona piuttosto bene quando te devi mostrare una cosa velocemente queste cose funzionano.Le relazioni molti a molti con la tabella pivot già out of the box sono sempre a tire.aperta, chiusa.Ora facciamo la smr su questo.Prendere tag dell'utente che fa i sync e lui guarda quelli che ci sono, aggiunge quelli che non ci sono, leva quelli che hai levato e aggiorna i timestamp nella tabella pivot.Quante volte l'abbiamo scritta prima di di Lara per queste cose questa cosa questa cosa aiuta.Il problema altro di Eloquent è che il modello comincia a diventare una god class, nel senso il modello utente dove rischia di avere un sacco di metodi perché alla fine è sempre l'utente a fare qualcosa, l'utente che clicca, l'utente che salva, l'utente che modifica, quindi c'è questo rischio, cioè il rischio di scrivere tanta roba e soprattutto il il modello si porta dietro un, diciamo, una conoscenza di quello che sta sotto, cioè il modello sa di essere salvato in un database fondamentalmente, cosa che in realtà non dovrebbe sapere, però bisogna vedere se si vuole fare puristi del codice e della Gang of Four si può essere d'accordo, se si vuole sviluppare qualche cosa e mostrarla bisogna qualche parte mollare un attimo le redini.Io l'ho usato, lo uso con soddisfazione, non ho mai raggiunto il punto se c'è una query complessa che occupa un po' di tempo, mi metto i log sulle query che occupano tanto e poi ci penserò quando devo ottimizzarle, però intanto ce ho c'è lo che funziona.E' vero, come posso dire, questo fatto che non sia così separato il modello della persistenza, per me che non sono così purista, mi sta anche bene.Ecco, i vantaggi che mi porto a casa sono molto di più di questi vantaggi in questo momento, perché ancora non è entrato il debito tecnico.Io ho avuto un'esperienza abbastanza grossa con symphony cioè abbiamo sviluppato un software dove per riuscire a terminarlo abbiamo dovuto utilizzare un approccio ddd perché aveva una certa complessità nelle logiche di business no? ad oggi se dovessi pensare di svilupparlo usando eloquent è con l'aravel ma comunque usando eloquent perché l'aravel mettiamolo per un attimo da parte perché l'aravel non è eloquent questa è una cosa da sottolineare cioè HelloQuantity ti viene dato out of the box però occhio perché tu potresti usarci Doctrine che è un altro strumento per la gestione della persistenza dei dati però quello che voglio dire io è che se oggi dovessi immaginare lo sviluppo di quell'applicazione complessa e grossa quattro anni di sviluppo su Laravel probabilmente mi verrebbero i capelli bianchi specie se utilizzando eloquent usando ma quante di queste applicazioni facciamo nella nostra vita perché la mia domanda parte da questo invece quanto il nostro tempo è speso a creare applicazioni che fanno il crude leggi dal database scrivi nel database dai la cera togli la cera Quanto i problemi veri delle nostre applicazioni sono semplicemente "tu sei pippo puoi vedere solo questo record" o "tu sei plutto puoi vedere quest'altro" tutte queste cose Laravel te le dà gratis fondamentalmente e col minimo sforzo ecco dov'è il punto di vista principale di Laravel ed ecco perché ci contentiamo di utilizzare alle volte.È eloquente pur sapendo che tu hai un'unica classe per fare le query e per definire l'oggetto con le sue proprietà che è una cosa che ti manda davvero in mind blowing.Sembra quasi la trinità.Il modello è la lista degli elementi ma anche l'elemento e questa cosa a me devo dire venendo da symphony ha confuso e non poco però devo dire che dopo che lo usi dici ho già fatto ho già fatto quelle operazioni che sono quelli ricorrenti cioè quel maledetto crude.Non so quanto si può ottimizzare la cancellazione di un modello di una riga da un database per cui secondo me quelle cose vanno bene la complessità che può arrivare arrivare per il tuo specifico progetto che è diverso dal mio, è chiaro non lo puoi trovare in un framework che è general purpose, perché sono proprio i concetti, proprio per definizione se è una cosa particolare che ho solo io, nessuno me la verrà a sviluppare, me la devo sviluppare io, però è solamente una parte rispetto a tutto quello che c'è all'interno di un framework.Perché io devo fare l'escape dei caratteri che mi arrivano da una post? Io voglio che mi vengano già fatte, quello è un problema comune a tutti e voglio che sia risolto dal framework.Al resto cerco di pensarcio alle cose che sono particolari per il mio progetto.Per cui questo approccio secondo me l'ho trovato all'interno di Laravel.Mi porta a fare questo ragionamento.Noi siamo degli ingegneri però spesso i livelli di complessità che affrontiamo, dobbiamo ammetterlo, veramente bassi.Cioè quanta complessità da esame di programmazione oggetti hai nella tua vita? Fondamentalmente io il 90% dei software che ho sviluppato lato back end erano dei crude avanzati quanto ti pare ma dei crude era salvo un paio di progetti veramente complessi con parecchie classi orchestrate e logica di business articolata ma era un crude quindi se il crude e questo da sviluppatori dovremmo saperlo è un approccio che può essere diciamo replicato cioè può essere fatto in automatico o in automagico visto che stiamo parlando di Laravel e ben venga vero è che però questa magia ha un costo E un altro costo, come dicevi prima, è quella delle fassade, no? È arrivato la rosina! Ah, le fassade...Sì, allora, qual è il problema delle fassade? Intanto definiamolo.La fassade è in Laravel, perché non si parla del pattern fassade della Gang of Four, che è una cosa simile ma diversa.cioè in Laravel per stessa missione del trailer la facade è una cosa per...è una struttura per chiamare staticamente una classe che non è statica cioè per dire...diciamo...facciamo un esempio route, c'è la facade route che rappresenta il router io faccio route, due punti, due punti, quindi metto lo statico get slash e scrivo la...quella è la mia rotta slash che viene gestita da qualcosa, ok? Quella route è una façade, cosa vuol dire? Sto chiamando staticamente la classe route? No, perché se uno va a cercare nel codice non esiste una route.php intanto, quindi dice "come viene caricata questa classe?" In realtà c'è tutto un sistema per cui, che sarebbe il service container di Laravel, route è associato a un'istanza di un'altra classe, chiamata route, e chiama, non staticamente, ma quindi genera l'istanza, su quell'oggetto la classe get.Ma perché? Perché si vuole dare l'idea di utilizzare una specie di variabile globale che però globale non è, ma in realtà lo è perché all'interno del service container una volta istanziata è sempre quella.Ora lo chiamiamo singleton, ma vent'anni fa era la variabile globale.Perché si fa così? Perché è più carino da leggere.Perché te vedi Route con queste maiuscole, con queste minuscole, i due punti, dici "ah, guarda, guarda bello, c'è questo oggetto Route magico che fa qualcosa".Io per capire come funzionava mi sono guardato i tutorial, sono dovuto...perché incasina anche il tuo editor, perché ti dice "ok, ci sarà da qualche parte una classe Route, andiamo a vedere in Composer se c'è una classe...non c'è".Come fa? Alcuni editor hanno dei plugin per Laravel per ritrovare dov'è questa definizione.O ci devi mettere un file PHP in modo che l'editor sappia di cosa si tratta.Esatto, per cui questo perché si fa così? Solo per una questione tra virgolette estetica che è molto presente in Laravel.Io ho scoperto due settimane fa ascoltando un podcast una cosa chiamata "Neurotic Laravel" è un post del 2005 dove questo sviluppatore aveva scoperto una cosa che io non ci avevo mai fatto caso.Tutti i commenti all'interno di Laravel, del codice di laravel sono fatti da tre righe e ognuna di queste tre righe ha tre caratteri in meno di quella prima per cui graficamente non si riesce a capire però si appare una scala intorno perché è fatto così perché è più piacevole da leggere in tre righe la definizione quindi è più facile qualcuno vada a leggere cosa fa quel metodo ora taylor può essere una capra come programmatore può essere un marchettaro può avere tutti i difetti del mondo però uno che c'è una testa del genere sicuramente va a scrivere "cerca l'esteticità" anche nel codice.E cosa si porta dietro? Questa fasade si porta dietro problemi per cui te, una volta che usi la fasade, devi stare dentro l'aravent perché non puoi creare un pacchetto che usa una fasade e poi metterlo su un symphony perché non c'è tutto questo discorso di collegare la classe "statica" all'oggetto in realtà istanziato.Quindi si porta dietro un lock-in, quindi non va bene, non va bene, va bene sempre per il discorso dei puristi.Può andare bene, però il problema è che per creare una façade, quindi per farla usare a qualcuno in una maniera così carina, devi agire su quattro punti diversi del framework, diciamo della parte del framework che è...cioè non del framework dentro la cartella vendor, quello non si tocca, però devi scrivere quattro cose per fare funzionare questo ciclo.Ne vale la pena? Per me tendenzialmente no, io non penso di aver mai mai scritto una fasad per me perché alla fine fai tutto direttamente col service container e non ho grossi problemi.C'è stato un tweet recentemente di Taylor che diceva su mi pare su Vapor dice allora in Laravel ci sono 33 fasad ok? Noi non le ho contate però ci sta che ci sia anche se lo dice lui ci fidiamo.Vapor ne usa 9.Non è come dire non è che se non le usi allora non puoi sviluppare nulla.Vapor è un servizio, un software scritto in Laravel avanzato, sviluppato sempre da Taylor Hortwell.No, assolutamente sì, è una roba che ce l'hai e soprattutto quando stai collegando i mattoncini è molto comoda da avere perché vuoi l'utente, usa il 2.2 o auto 2.2 e c'è tutto il contesto d'autenticazione già bello pronto.Io sai come l'immagino la facade? Come la mamma.Tu hai 17 anni e c'hai mamma vestiti puliti e mamma ti dà i vestiti puliti però sotto quei vestiti puliti c'è l'istanza mamma che aziona la lavatrice, stira, li mette nel mobile.Quando poi parti all'università e il parte all'università è la tua applicazione si complica, hai bisogno di un controllo a livello più basso della tua applicazione, la mamma non c'è più.E' là che diventa difficile la situazione.Se sei abituato a usare le façade, quando ti sposi e fai moglie, vestiti puliti, non funziona.Hai un situazion error, un exception, per cui va usato.Se sai che rimarrai con la mamma tutta la vita, allora si può comportarsi in quella maniera.Però ecco, è un'analogia che calza.Sì, e il problema è davvero che queste façade piano piano le disperdiamo un po qua un po là nel codice quasi ne perdiamo il controllo invece il controllo di quello che noi scriviamo deve essere mantenuto.Esatto anche perché appunto ci sono modi usando il service container di Laravel per non usare le façade, semplicemente dire e fai la stessa cosa cioè chiedi all'app, al container mi dai questa classe e lui te la istanzia però almeno ce l'è scritta lì.L'app ha un suo helper e il nome della classe è scritto lì, per cui se te lo vuoi cercare banalmente, se vuoi cercarlo nel net per vedere cosa fa, ti cerchi quel nome di classe, c'è scritto.Invece la facade può avere un nome che non c'entra nulla.Route e router è un esempio, però io ho detto "ok, c'è scritto route da qualche parte c'è una classe route", invece no, poteva chiamarsi Pippo.Io faccio, quando faccio ai corsi, faccio vedere come si fa una facade, metto spesso il nome Pippo per far capire che non c'è nessun file che si chiama PIPO, però la classe alla fine si chiama PIPO per far vedere come si collegano le cose.Però ecco, anche lì va usato in una maniera corretta, ma questo non è un problema di Laravel.Qualsiasi framework o linguaggio si usa ha delle regole, bisogna attenersi.È facilissimo scrivere brutto codice su Laravel, è facilissimo scrivere brutto codice procedurale in un singolo file php non è quello non è un problema del primo sì è spesso quello che si dimentica quando si critica l'arabel è sempre il suo fine cioè rad esatto infatti io questa è questa lotta questo tutto questo gossip lascia un po il tempo che trova non lo vuoi usare usa qualcos'altro scrivete lo da solo un framework c'è una vignetta non so se xk cd o qualcosa simile dove ci sono 100 framework javascript, ma nessuno mi piace, ne scriverò il mio framework javascript e dopo un tempo abbiamo 101 framework javascript.Perché alla fine uno che dice no ma io mi sono fatto il mio framework da solo, ne avete già parlato in altre puntate, però ok va bene, io mi fido di più di una community di migliaia di sviluppatori che mi dicono che questa stringa che mi arriva è già stata già stato fatto l'escape e e non ci sono dentro caratteristiche strani.Non me lo voglio strascrivere io.Quindi su questi problemi secondo me io ho un approccio più orientato a usare il framework quanto serve.Diciamo che non vorrei che l'arabia sta prendendo una certa strada.Ora poi ci arriviamo.Sai una cosa? Che anch'io in parte condividevo quello che dicevi tu.Oggi però qualcosa mi sta facendo cambiare idea.Credo che Libraries is the new framework.Nel senso che è diventato così facile mettere un collante tra i vari pezzettini e puoi farlo anche fatto bene dove i pezzettini sono le varie librerie una libreria di routing, una libreria per la persistenza, una libreria per quest, una libreria per i log, cioè monologue è bellissimo però magari io voglio usare doctrine per la persistenza e il router di un fantastic packages non lo so c'è un team che sviluppa dei pacchetti bellissimi per php spati è legato alla ravel poi vi metto il link nelle note dell'episodio però di scrivere il collante tra questi elementi è abbastanza facile.Certo è che comunque ci deve mettere del tempo, tempo che l'Aravel ti risparmia.Devo dire una cosa, l'Aravel utilizza a sua volta un sacco di pacchetti tra cui quelli di Symphony, Request e Response sono quelli di Symphony.Il problema è che scrivere un pacchetto per l'Aravel ti porta a un certo punto a...cioè rischi di farlo solo per l'Aravel, nel senso che vuoi usare una fasada nel tuo pacchetto e distribuirlo e quel pacchetto funzionerà solo su Laravel.Se non usi queste cose e vuoi fare una cosa più generica che si possa collegare a qualsiasi framework, semplicemente una libreria, chiama queste funzioni per accedere alla libreria, se utilizzi tutte le cose di Laravel ti viene fuori una cosa che funziona solo su Laravel.Ma ecco, io la vedo normale una cosa, cioè vuoi utilizzare tanti pezzi di un framework nel tuo pacchetto? Questo legame per forza di cose ci deve essere.Se no astrai! E' arrivato la rovina! Ci siamo concentrati molto sugli antipattern ma adesso dovrebbe venire il bello giusto? Dovrebbe, dovrebbe! Parliamo di community di Laravel.Allora noi abbiamo parlato di Taylor Hortwell, no? Il Il creatore di Laravel, una personalità molto particolare, molto particolare, io non sopporto l'oppulenza mostrata da Taylor Hortwell, veramente non lo reggo.Dal tuo punto di vista, cosa sta riuscendo a dare ad oggi all'ecosistema Laravel e secondo te cosa limita o quanto limita l'arabel.Allora più che Taylor in se per sé è il fatto di avere una sola persona al comando che se viene messo sotto con la macchina non c'è più e chi porta avanti il progetto? Diciamo non c'è c'è sicuramente una comunità però la sua la sua presenza è molto forte lui pone il veto su diversi aspetti perché appunto essendo così un esteta come si diceva prima del codice è chiaro che è molto molto pignolo su quello che entra all'interno del proprio codice.Ha delle posizioni a volte un po' estreme.Recentemente si è cancellato da Reddit per un diciamo sul subreddit di Laravel, c'era una discussione su Jetstream e a un certo punto lui ha proprio cancellato l'account, un po' come quello che non buca il pallone perché alla fine poi Reddit è rimasto.Però è uno che accetta poche critiche e il suo discorso è "io vi faccio una cosa, ve la faccio gratis, ve la faccio per come serve a me" perché ho ascoltato un'intervista recentemente, dice "a me Laravel mi è servito per portare avanti dei business, scrivere delle cose che servivano a me e poi ho deciso di darlo a tutti" nel senso che è open source e uno lo può usare, quindi cosa ha dato? Ha dato tutto il framework, ha dato questa impostazione e il vantaggio di avere una sola persona è che se a te ti allinei con quella con quella linea di pensiero, te vai daddio perché ti trovi tutto già fatto, fatto bene e chiudi un occhio quando qualcosa non va bene, però ce l'hai di gratis.Avere una community che magari, o una commissione che decide tutte le cose, sicuramente rallenta un po' lo sviluppo, ma mifica sicuramente le grosse divergenze che ci possono essere bisogna vedere una cosa cosa cerca symphony è gestito da una da una senza l'abbiamo insomma da un'azienda ci sono varie persone che gestiscono fabian ecco ci sono tante persone però poi tutti si ricordano di lui sono persone molto diverse te loro da fabian e famiglia non lo conosco però sicuramente non c'ha se cerchi insomma te loro felta in google immagini trovi quasi solo foto di lamborghini chiaramente sono leggiate perché sono troppi colori va bene fare i soldi col php ma non esageriamo.Ma io ho visto che sono un milione di dollari che sta tirando su.Sta tirando su ma perché se li ha tirati su, posso dirlo, ma perché io e te non l'abbiamo tirato su? Forse lui è bravo e sicuramente ha fatto un prodotto di successo, con tutto il rispetto per le centinaia di migliaia di euro però se uno è così bravo evidentemente qualcosa c'ha, non gli cascano dal cielo.Quindi secondo me lui sbaglia, per quanto la mia opinione valere, sicuramente lui ci ascolta, ciao Taylor, sbaglia magari avere queste posizioni, però se lui è fatto così e dice "ragazzi io ve lo do gratis, avete anche da lamentarvi, chiudo l'account" e va bene, è fatto così, lo sappiamo, io smetto di usare l'Aravel per questo, no, io dietro questi gossip non ci sto nemmeno dietro perché a me interessa sviluppare se c'è una cosa che poi inizia a non piacermi e ne uso un'altra.Fortunatamente siamo in un modo dove c'è tantissime tantissime alternative.Non mi sento legato a Taylor o all'Arable.Diciamo che ho sviluppato una certa esperienza per cui mi riescono più facile le cose, ma se l'Arable viene abbandonato, perché non è detto anche lei Taylor, dico sapete cosa? Io l'Arable non lo sviluppo più.Questo sistema rimane lì, ciao.E che fa uno? Da qualche parte il progetto va.Se muore, vuol dire che non non c'era nemmeno dietro tutta questa community così...come dire...cioè che vuole mettere le mani...non le mani in pasta, però dire che si vuole prendere la briga di fare quello che Taylor fa da solo.Sì, però non sono d'accordo con te e questa cosa mi piace tantissimo.Finalmente sono a disaccordo.Allora, partiamo da una premessa che la community di Laravel è per il 90% una community di utilizzatori.Ok e questa premessa è chiara.A me è dell'opulenza adesso scherzi a parte dell'opulenza e della ricchezza di Taylor Hortwell poco mi importa di Taylor Hortwell poco mi importa.Buon per lui.Però io oggi devo lanciare un business.Io lo faccio utilizzando l'Aravel.Io mi sto mettendo nelle mani di Taylor Orwell.E questo a me non piace.Poi l'ho fatto.L'ho fatto, no? Perché la produttività, tutto quello che ci siamo detti prima.Però questo non piace.Perché? Perché è vero che avere un uomo forte alla guida di un progetto ti permette di andare veloce.La stessa cosa sta succedendo sull'Aravel a livello di progetto? Cioè io ieri ho sacrificato me stessa e ho guardato più di due ore e spiccioli di video di Taylor Hortwell che risponde alla community.Dopo la prima ora io stavo per sbattere il computer per terra.Perché? Perché lui dice una cosa semplice.Io l'Aravel l'ho fatto per me queste nuove introduzioni poi spieghiamo che cos'è Jetstream però queste nuove cose che sto portando che stravolgono il modo di vedere le cose sono utili a me quindi Laravel fa così.Nel momento in cui hai un pacco di persone che basano il loro business sul tuo progetto open source questo non puoi più dirlo perché? Perché quando realizzi qualcosa specie nell'open source, quella cosa non è più tua, è un'entità che vive da sé.E un esempio è stato San Filippo, Antireds, con Redis.Redis è diventata un'entità a sé stante talmente forte che San Filippo si è ritirato dalla parte operativa di Redis, perché l'unico modo per far vivere Redis probabilmente e far vivere San Filippo dall'altra parte era quella.Quindi secondo me va bene lui può dire tutto quello che ti pare sul fatto che l'Aravel l'ha fatto lui e il suo brand però quanto l'utilizzatore sta rischiando sulle decisioni di un unico uomo.Perché la community di sviluppatori che lavorano sul core di Laravel sono la cerchia strettissima di Taylor il quale prende l'unica immagine il quale ha il diritto di veto su tutto e questo è pericoloso.Quindi sì io ho usato Laravel consapevole di questo no? Il beneficio che mi dava essere subito produttivo era uno.ragionamento voglio chiuderlo con un tweet che ho beccato oggi ho condiviso nel gruppo l'avrai anche visto che è il tweet che racconta l'affermazione che ha fatto Rasmus Lerdorf per chi non lo conoscesse è il fondatore di PHP che ai complimenti sulla versione 8 di PHP lui risponde sì PHP 8 è molto meglio proprio perché non c'è il mio codice.Questo è proprio l'apoteosi del concetto che sto dicendo io, cioè del fatto che il linguaggio, il framework, il tool o il progetto open source arriva a un certo punto che poi deve camminare con le sue gambe.Pericolo che è cosa che in realtà non vedo in Laravel.È cosa che mi spaventa ed è anche la cosa che mi ha portato anche ad allontanarmi da Laravel in quest'ultimo tempo.È condivisibile il tuo punto di vista? Io dico che comunque essendo il codice su GitHub, se qualcuno vuole fare un fork e portare avanti una community edition potrebbe farlo, cosa che non è successa.Quindi per ora questa situazione diciamo è tollerata.Diciamo che anche è vero i rischi ci sono effettivamente se un enterprise, diciamo, un'azienda grossa va a vedere, decide con quale tecnologia usare, sapere che c'è una sola persona con quel tipo di personalità può essere un problema.Non che Laravel smette di funzionare se Taylor non c'è più, magari smette di avere aggiornamenti e le cose possono funzionare, però può essere può essere un fattore di rischio, non lo metto in dubbio.Ci sono appunto situazioni dove non si deve usare, tipo questa, ci sono situazioni dove va bene anche fare così, però secondo me importante è, qualsiasi opinione uno possa avere, sapere che c'è questa situazione, perché le opinioni sono personali, questi sono i fatti, cioè lì c'è una sola persona che può decidere di...può anche levare il codice da GitHub e te ti tieni solo la parte che è scaricato e ci puoi ricreare un altro progetto, però ecco è un rischio.Probabilmente lui non si vuole gestire, non è una persona adatta a gestire una community, perché bisogna essere in grado e non ha voglia magari di affiancarsi a una persona anche di fiducia che possa portare avanti questa cosa.Nonostante tutto, vai a vedere le star su GitHub, è usatissimo, anche se questo è un paragone poco consono, perché mi ricordo ai tempi del liceo un mio amico, facciamo una digressione nel centro a nulla.Gli dicevo "guarda io se ascolta che musica ascolte, faccio sentire gli Iron Maiden" e gli dice "ma cos'è questo?" e gli dicevo "guarda che questi vendono milioni di dischi" e lui mi disse "anche Take That" e lì mi ha detto "ah ok".Il numero preso da sé non conta, bisogna vedere chi ha dato o chi ha dato coi voti.Però ecco diciamo, su Github è normale lettare.Hai ragione e secondo me probabilmente la struttura della community molto è legata proprio al concetto di Laravel.Cioè io voglio usare qualcosa senza sbatti come direbbero i ragazzini.Cioè qualcosa dove non mi devo preoccupare perché qualcuno ha preso delle decisioni per me quindi una roba fortemente opinionata.Quindi probabilmente tutto il discorso che ho fatto 30 secondi fa potrebbe non servire a niente.Questo per dirti che in realtà c'è certe volte c'è bisogno del dittatore per andare a costruire grandi ponti.Esatto per dire ho preso questa decisione si fa.Esatto punto però il problema il problema è che in realtà se per sbaglio shift il contesto ti sposti nel contesto cambia tutto ed è la cosa che più mi spaventa.Stavo cercando tra l'altro giusto per chiudere la parte della community.Ho usato questa metafora nella precedente puntata cioè il fatto dell'uccellino da miniera.Sapevi i minatori portavano un uccellino.Canari.Esatto.Noi usiamo questa metafora anche in ambito "te puoi tu" da DevOps Ingenio in quest'ultimo periodo a maggior ragione.Però secondo me è un indicatore di quanto ci sia il limite che prima ti stavo raccontando e vi stavo raccontando è il fatto che un po' tutti conosciamo Tailwind qua su Gitbar ne parliamo spessissimo di Tailwind perché voi frontendisti siete ma io io non so cosa sono sono un backender sono frontender però Tailwind che è una figata pazzesca io sono super entusiasta di questa roba e tra l'altro Tailwind nasce come costola dell'ecosistema Laravel tanto che Adam Wattan era un stretto collega e collaboratore di Taylor Hortwell e anche grande sostenitore dell'ecosistema Laravel tanto da svilupparci un un un generatore di siti statici jigsaw su Laravel.Guardando in giro però io seguo molto Adam e guardando in giro ho visto che ha portato tutto lo stack su nextjs quindi ha abbandonato gem stack e si è spostato su un'altra tecnologia.Adesso la domanda che mi faccio da utilizzatore di Laravel, perché io ce l'ho in produzione, ma perché l'ha fatto? Per i limiti tecnici, per i limiti di community, per i limiti di parametri di crescita o per le decisioni, per le ultime decisioni tecniche che si sono prese in seno a Laravel? E questa cosa mi accende il campanello e mi porta a parlare con te dell'ultima pietra dello scandalo di Laravel, ma su questo ci è stato detto tantissimo, facciamo una considerazione anche abbastanza breve, quindi di Jetstream che come concetto è molto interessante, ma della sua implementazione con Inezia e Liveware.Intanto che cos'è Jetstream? Jetstream è stato proprio il pomo della discordia perché quello poi ha portato Taylor a cancellarsi da Reddit.Praticamente è un frontend per gestire tutta la parte di autenticazione che Laravel gestisce dal back-end con Spotify per esempio.Cosa permette di fare? Permette di avere, diciamo, senza troppe righe di codice, un pannello dove puoi avere l'autenticazione a due fattori, quindi un pannello utente dove generare token, cancellare token, quindi hai questo pannello già fatto.Io se posso subito dire la mia, ho trovato che questa cosa è un po' esagerata.Allora, vi ho già detto, per me un framework come Laravel, io lo uso proprio come struttura, come fondamenta per poi svilupparci sopra delle cose.Andando a leggere la documentazione, quello che ho percepito io è quasi...come posso spiegarlo? Sembra quasi che hai installato Laravel, bene adesso installa Jetstream perché ti servirà, cosa che io trovo esagerata, cioè trovo non giusta.Non dico che Laravel non funziona senza Jetstream, anzi, Laravel funziona tranquillamente senza Jetstream, ti portano quasi a installarlo subito e a decidere se utilizzare LiveWire o Inertia, che poi ne parliamo.Però ecco, quello che ho percepito è come dire "ok, abbiamo fatto il framework, adesso ci aggiungiamo anche questo, adesso ci aggiungeranno, sembra quasi nel futuro, non che succederà, però come idea, adesso ma sicuramente vorrei creare anche dei post, ma dai post vorrei anche aggiungerci dei commenti".Insomma alla fine ti ritrovi di Wordpress.La mia battuta era quella.Wordpress sta facendo l'inverso, nasce come blog, però adesso c'è WooCommerce, ci fai anche l'e-commerce, cioè fai tutte le cose meno ottimizzate possibili perché Wordpress nasce per fare i blog ed è stato portato a fare tutt'altro.Quindi per tornare al Jetstream, che è questo pannello fatto anche abbastanza bene, però non ne una un'opinione molto molto favorevole perché non l'ho usata fondamentalmente perché magari non ho ancora mai implementato l'autenticazione a due fattori quindi non mi sono mai messo a scrivere lo stesso pannello dieci volte e quindi ma è sicuramente va nella direzione del salva al tempo vuoi usare l'autenticazione utente usa questo pannello in cambio a tcss questa cosa funziona allora io l'ho provato intanto devo fare una premessa quindi l'arabel è un framework full stack ci fai front end e back end insieme.Sul back end ci sono quelle cose che ci siamo detti prima quindi le facade, c'è eloquent però scrivi la persistenza nel database, fai il tuo crude molto rapidamente e quindi turandoti il naso viaggi veloce.Il problema del front end.Qualche tempo fa io ho sviluppato un'applicazione front end e la parte front della mia applicazione con l'aravel e la inizi con blade quindi sono dei file php fondamentalmente in realtà sono punto blade ma vengono parsati.Un template engine.sì ma è molto light come template engine nel senso che ci fichi dentro anche delle parti php e quelle girano su twig di symphony non funziona così o scrivi su twig o non gira però diciamo che un template engine che ti permette di fare delle pagine renderizzate server side e va bene.Oggi però le nostre competenze lato front end stanno crescendo e abbiamo bisogno specie per una richiesta che si evolve di front end un po' un pelino più evoluti.La Ravel deve darci produttività in tutti i livelli dell'applicazione quindi back end e front end per cui cos'è successo? Il primo periodo ha messo l'integrazione direttamente nascondendoci webpack.Primo passaggio mi interessa proprio percorrere e fare il percorso.Primo passaggio.Ci nasconde la complessità di webpack.Perché webpack di per sé è un bordello per chi non lo conosce chi vede per la prima volta questa cosa tira giù il cielo quando lo vede poi quando l'ha capito va bene è tutto più fluido.Quindi semplifichiamo webpack prima operazione mettiamo view il framework frontend con la curva d'apprendimento più bassa.altra scelta di gente credo.qual è il problema? è che in realtà spostarsi di pagina in pagina era sempre deciso dal nostro framework backend.quindi tu cosa facevi? al tuo framework frontend ci passavi questi stringoni in json e view si attivava cosa abbastanza limitata tenete presente che ci sono dei servizi che producono davvero milioni di dollari fatti così nell'ecosistema di laravel vapor no vapor no forge è un altro qual è il problema è che se la tua applicazione la tua frontend si complica come è stato il mio caso a quel punto devi trasformare tutta la tua applicazione in API e iniziare a lavorare giù pesante di Vue.js Qual è il problema? E' che è faticoso.E' che se devi fare sta cosa per il side project o la startup che devi andare a chiedere le limusine dal primo founder della situazione...adesso sto estremizzando però non va bene quindi devi fare qualcosa che abbia già la gestione utente out of the box, i gruppi, la registrazione, la generazione di token per l'API, tutta parte che il back end ti mette a disposizione, l'abbiamo visto prima e lato front end sarebbe bellissimo se tu lanciassi un comando e avessi già il login, la registrazione, la password persa, la creazione dei gruppi di utenti e quant'altro allora Taylor ha detto facciamolo in automatico però non facciamolo portando la complessità dei framework front-end che sono troppo difficili da imparare.Creiamo qualcosa che sia più stupido più più semplice e allora ha buttato dentro questo Jetstream che ti crea praticamente il front-end della tua applicazione una base dalla quale sviluppare il tuo front-end dell'applicazione e la si può fare in due modi il primo modo è con liveware il secondo modo è con inerzia allora livewire è un framework di sviluppo non so nemmeno come chiamarlo che permette di avere componenti all'interno della pagina come facciamo l'esempio come componenti Vue.js però utilizzando solamente PHP e Blade, cioè Laravel e Blade.Come funziona fondamentalmente? Diciamo che noi abbiamo una pagina dove abbiamo un componente con un counter e un bottone per aggiungere un counter.Quindi di questi componenti nella pagina ne possono mettere anche 10.Devono essere tutti indipendenti, quindi se clicco un bottone non è che devono aumentare tutti.Cosa succede? Caleb Porzio, che è lo sviluppatore che ha creato LiveWire, In realtà questo metodo per cui ogni volta che clicchi viene fatta una chiamata Ajax al tuo backend che calcola il nuovo stato di quel componente lì, perché si tiene in memoria tutti gli ID dei componenti e quindi te hai l'effetto visivamente sembra reattivo, però non hai usato una riga di javascript, ho usato pochissime solo per inserire il codice, diciamo lo script che fa girare questo sistema, però te scrivi delle action in PHP in Laravel delle view in blade, quindi sempre PHP, e hai questo sistema qua.Ovviamente la prima cosa che viene in mente è, cioè qualsiasi operazione io faccio una chiamata ad Ajax al mio backend, dove sta la...visto che ci stiamo spostando comunque c'è questo discorso delle progressive web app, cosa succede se io non ho più la connessione? Questi componenti non funzionano più, non esiste.Per cui per me io ne penso per ora tutto il male possibile, ma perché non l'ho mai usato quindi potrei anche cambiare la mia opinione, però non mi sembra un approccio che diciamo le critiche che vengono fatte sono molto su il coupling tra il codice che viene eseguito e il...tra i vari pezzi del codice che viene eseguito.Io non mi piace questo approccio, per cui, visto che Livewire e Blade è uno degli approcci per Jetstream, l'altro è Inertia.Inertia è una specie, ormai si fa anche fatica a definire queste cose perché non sono framework, ma sono librerie, diciamo che è una libreria, è una roba che ti permette di...vediamo se riesco, poi ci inserisci qualcosa a te qua, perché allora ti permette, come se facessi un'accollante tra il backend e il frontend, cioè scrivi dei componenti view e nel controller di Laravel fai i tuoi calcoli, la lista degli utenti, prendi la lista degli utenti dal database e poi invece di ritornare una view blade classica, ritorni una view chiamando la fasata di inertia, cioè di Cinercia renderizza questa vista scritta in view dove l'oggetto che gli passi, l'oggetto PHP che arriva dalla diciamo la lista degli utenti, l'array PHP degli utenti, viene passata come prop al componente view, quindi viene serializzato fondamentalmente, quindi si torna, cioè se si vede si fa sempre le stesse cose, ma perché sì, perché se abbiamo un oggetto in php e lo dobbiamo portare in javascript e da qualche parte la serializzazione va fatta, ok? quindi questa cosa si fa solo che lì sembra che venga fatta tutto, cioè te scrivi questo componente view, sai che gli arriverà la lista degli utenti che avrà le stesse proprietà dell'oggetto php e quindi puoi stampare l'utente, l'email, è chiaro che non ci puoi stampare quanti post ha fatto quell'utente perché a quel punto sei in una vista view e non hai più accesso come su blade all'arabel quindi ok cercano di semplificare le cose ma in realtà io sono più dell'approccio di cui l'arabel permette di fare a queste regole usiamo queste regole ho bisogno di fare solo front end io sono per fare una pagina in view e chiamano ipa in laravel che mi ritornano ci sono la serializzazione la faccio io sull'arabel e tengo separate le cose questo tentare di unire secondo me è sbagliato e porta dei problemi, cioè porta a utilizzare questi tra virgolette, perché sono fatti bene, sono scritti bene, a crocchi per risolvere un non problema.Perché uno dice ok c'è un front end, c'è un back end, li facciamo comunicare con API REST, basta, si usa questa approccia.E a quel punto si usa la tecnologia adeguata per il problema di cui è bisogno.Sì, assolutamente sì.Qua mi dispiace, sono d'accordo con te, però aggiungerei una cosa.LiveWeir, com'è che si chiamava il creatore di questa libreria? Caleb Porzio.Ok, questa cosa, adesso io sarò veramente critico su questo concetto, cioè cercare di portare una chiave inglese trasformarle in un martello è il male anche quando cerchi di semplificare le cose turandoti il naso nel senso che porzio che da questo momento in poi soprannomineremo porzio pilato ti dà questo strumento ma se ne lava le mani perché quando lo metti in produzione questa roba tra cinque anni sarà ancora viva io credo di no sarà ancora vivo server.Esatto esatto quindi già liveware mi sembra un accrocchio per mettere davvero un chiodo con la chiave inglese solo perché non vuoi studiarti tre righe di javascript che già sai perché l'hai usato fino a ieri con jQuery su su Laravel o con Vue se l'hai usato un po più moderno quindi secondo me proprio liveware è da eliminare completamente.Inertia mi sta un po più simpatico.Perché? Perché in realtà fa parte di un'esperienza che ho vissuto, quella che vi stavo raccontando e ti stavo raccontando prima, cioè il fatto di farmi le pagine come componente view, e io l'ho fatto, e passare per ogni pagina i dati usando il router di Laravel per spostarmi da una pagina all'altra.Bello, però nel momento zero tu hai la necessità di creare qualcosa di più articolato e quindi devi liberarti dell'idea del router back end ma succede molto presto questo problema ecco perché la community si è incendiata perché quel break even point che non è un break even quel punto di rottura che hai molto avanti nell'uso del back end e che tu mi dicevi io non l'ho mai toccato nell'uso di front end lo tocchi molto velocemente perché anche un' applicazione abbastanza semplice può avere una interattività utente molto complessa perché oggi la nostra complessità sta là tutto il resto nel 90 per cento delle nostre applicazioni è una maledetta crude ragazzi quindi Inertia cosa fa? Giù c'è i dati e renderizza.Bene peccato che questo problema lo vai a impattare ci vai a impattare subito Qual è il problema? È che la cosa figa di Laravel è lo scaffolding.Cioè un comando e tu avevi già le interfacce belle pronte con login dove dovevi metterci tre righe di CSS e portavi il login senza disegnare neanche un input box già pronto nella tua applicazione.Ed era la cosa che a me piaceva di più fondamentalmente di Laravel.Ed era il motivo per cui usavo Laravel.Se oggi usare questo approccio mi costringe ad usare una di queste due voci e costringe a me che sono per esempio amante di React perché Inertia supporta React ma lo scaffolding di Laravel Jetstream non lo fa.Quindi dico ma ancora senso usare l'Aravel se lo deve usare solo per il back end e forse ci sono delle soluzioni più performanti per esempio un API platform di Symfony che in più mi dà anche una qualità del codice formale migliore? Eh, questa è quello che mi chiedo e là dove, qua è dove mi son fermato.Io sono in una...in questo momento sono in una fase intermedia, nel senso che sto sviluppando un prodotto e ho le mie viste che sono fatte, alcune in blade, alcune in blade con dei componenti più, alcune sono tutte in view.E a questo punto mi dico "non mi piace questo approccio" perché poi vorrei avere una singola soluzione.Ho iniziato in una maniera, ho continuato in un'altra perché a un certo punto ho avuto bisogno di view e sto pensando di spostarmi a fare tutte le viste con view quindi anche il routing quindi una single page application fondamentalmente con l'aravel usato solo come come back end però ecco ora la cosa che potrebbe avvicinarsi è inercia perché comunque l'ho già fatta in view quindi alla fine so scrivere in view quindi mi va bene però sono ancora un po reticente perché secondo me preferirei usare solo view, mi sembra di aggiungere una complessità che non è necessaria.Guarda sai cosa mi piace di Laravel UI? La Laravel UI non l'abbiamo detto, era il modo per fare lo scaffolding prima di tutta sta roba, cioè semplicemente lanciavi un comando e ti creava dei template blade che erano fondamentalmente dei template HTML con qualche for e if e veramente poco altro l'accesso alle variabili che tu da sviluppatore vedevi come una pagina html senza tanti sbattimenti una pagina html come come la conosciamo no? e in più tu potevi svilupparci la tua applicazione react, angular, svelte, framework tipo alpine, js e attaccarcela perché comunque comunque c'era tutta una struttura, dici l'autenticazione ce l'ho in schermate diverse che si aggiornano server side però una volta che io ho la sessione posso fare delle chiamate rest e la mia pagina si era tutto questo era flui mentalmente sopportabile Era un bordello mentalmente sopportabile oggi con questi elementi che magari possono anche velocizzare magari possono anche velocizzare Però secondo me si sta sviluppando, e qua ci avviamo alle conclusioni, secondo me si sta sviluppando un contesto dove diventa necessario imparare degli accrocchi.Per imparare questi accrocchi ci si sobbarca di un carico cognitivo importante, anche solo per capirne la logica di come funzionano, questo carico cognitivo perché lo stai mettendo su una cosa che sei già che un accrocchio che sei già che tra tre anni non se lo cagherà nessuno quando puoi investire questo carico cognitivo per studiarti webpack guardarti bene view e fare una single page application o guardarti bene react e farti una single page application se la quantità di carico cognitivo è la medesima perché veramente oggi è abbastanza facile imparare i rudimenti di un framework front-end, cioè violo impari in quattro ore, tre ore ragazzi.Perché? Mi chiedo il perché.Esatto, io sono dell'idea c'è il front-end c'è il back-end è un filo dove arriva il GSO.Lavoriamo su questo, è un approccio pulito anche perché questa complessità che dici te di Akroki, ce l'hai già sia da una parte che dall'altra, perché se vuoi cominciare ad utilizzare componenti di, diciamo, libreri di più, c'è tutta una complessità, cioè sono due mondi talmente complessi che cercare di unirli insieme e farli dialogare secondo me non porta a niente di buono, soprattutto anche un discorso di separazione.Che succede se l'Aravel non viene più sviluppata e voglio cambiare però sto usando livewire e succede che me la tengo così oppure stessa cosa sul front end io appunto non sono non mi piace la direzione che sta prendendo l'arab e l'ora però è anche vero che non devo seguirla per forza non devo usare jetstream con quella roba magari mi scrivo io delle cose probabilmente può essere anche non abbia bisogno di tutto quello scaffolding perché non lo so ho bisogno solo di un server api ma non è detto nemmeno c'è questo punto poi una domanda si fa non è che io uso Laravel per qualsiasi cosa, io la uso fin quando devo fare qualcosa di full stack perché finora mi permette di avere un sacco di cose anche solo back-end, basta pensare autenticazione, sessioni, middleware, le code, tantissime cose che non voglio stare a riscrivermi o stare a comporre pezzi che mi possono portare a problemi, quella cosa funziona e funziona in una maniera piuttosto standard, io prenderò quella direzione sperando che poi non mi ci vengono...cioè io smetterò quando le prestazioni saranno talmente...come dire...terribili che nemmeno la prima...l'ello word è fruibile.Allora a quel punto forse ci hanno messo troppo dentro e allora però secondo me in quel momento è lontano.In realtà se io mi guardo tra un anno vedo che l'Aravelo oltre a tutti questi problemi ne ha un altro che è pensato con una concezione di un contesto completamente diverso da quello che stiamo vivendo.Tu sei un DevOps Engineer e quindi vivi anche un altro contesto.Poi è vero che l'Aravelo oggi ti dà parecchia produttività.secondo me non ha, se continua in questa linea, non ha vita lunga perché, adesso la butto così ma giusto per fare una battuta, Amplify e Farbase are the new Laravel.Nel senso che oggi quel tipo di collante, quel tipo di complessità, si sta spostando in un contesto cloud dove in realtà le applicazioni sono sviluppate col cloud in mente e quindi è caduto tutto qua scusa quindi cosa succede che in realtà saranno i servizi che andranno a sostituire gli elementi di laravel andremo a scrivere dei microservizi per qualunque cosa io lo sto vedendo già da me per github non ho più installato laravel ma ho 6 o 7 lambda che mi fanno tutto e alla fine secondo me quella è la direzione che non vedo sposata dal contesto Laravel.Sì, posso essere d'accordo perché come abbiamo già parlato molte cose si stanno spostando sull'infrastruttura.Esempio, io uso Cognito per autenticare gli utenti, non ho nemmeno bisogno della tabella user, me la fa Cognito, mi dà un token e ogni tanto chiedo se effettivamente è vero.Quindi potrei elevare tutta l'autenticazione.Un altro esempio, Laravel ha integrato un per fare il throttling delle richieste.Puoi dire "guarda, questa richiesta più di 60 al minuto non le recette, lo imposti su API Gateway, quindi sai già che quando ti arriva è già stata fatta tutta quella parte".Secondo me, diciamo, non necessariamente bisogna seguire il trend di andare sul cloud, perché non tutto sarà sul cloud e non tutto sarà serverless.Cioè, ci sarà sempre qualcuno che vorrà il server con la sua applicazione, non per forza bisogna spostarsi nel cloud.La Ravel può rispondere a questa richiesta, poi vediamo tra un anno quanto sarà la cosa.Difficilmente tutti questi progetti di framework così complessi, diciamo complessi nel senso di quante funzionalità ti danno già out of the box, vediamo quanti sopravvivono, perché alla fine avranno tutti lo stesso problema quando poi le cose che implementano loro sono implementate dal cloud o direttamente da un hardware per dire.Quindi bisogna vedere è un problema che secondo me, vuol dire sono d'accordo ma è un problema generalizzato a tutti i framework per applicazioni web.Sì sì sì sì ma infatti ma infatti là però io dal mio piccolo ti dico questa cosa io adesso devo lanciare una nuova applicazione un nuovo progetto stupido abbastanza semplice guardato AWS ma avrei potuto guardare Google Cloud o Azure Alibaba Cloud però cognito autenticazione.DynamoDB database gestito non devo fare niente nessun pensiero nulla di nulla Upsync API GraphQL in tempo zero con dei collanti se usi poi Amplify è ancora più semplice cioè ma Ma allora tutto quello che è l'obiettivo di Laravel che era quello di semplificare perché ti dava un collante di tanti elementi già pronti quindi gli elementi e il collante veramente con questi servizi rischi e specie quelli particolarmente semplificati far base da una parte amplifai dall'altra che vengono sono figli tutti del della rivoluzione pars io non so qualcuno se lo ricorderà pars come servizio.Ti permetteva di deployare le tue funzioni, ti permetteva di accedere ai dati, ti permetteva di fare l'autenticazione, ti dava tutto per fare.Perché fino a fatto? Loro hanno chiuso e hanno rilasciato pars open source ma perché sono stati mangiati dai grandi.È il discorso che facevi te sul framework.Lui aveva un business appoggiato su Parse, che quando gli è arrivata l'email, perché a me mi è arrivata che ero registrato per mandarle notifiche ma poi non l'ho mai usato, lui dice "guarda tra sei mesi chiudiamo".E come dire, è un problema comune quando usi cose fatte da altri, il che non vuol dire che bisogna scriversele da sola, assolutamente.Io sono contrario a questa cosa.Bisogna essere veloce.veloce e consapevole.Però secondo me ripeto è questa la direzione.Io sto sposando questa direzione sempre in termini di RAD, occhio, sempre in termini di RAD, con i dovuti limiti e quindi credo che in realtà l'Aravel ne parleremo sì ma non per tantissimo.Tra un anno ci rivediamo tanto.Ci diamo appuntamento di nuovo.Tu cosa ne pensi? Allora io come ti ho detto mi sembra una visione coerente con quello che sta succedendo.Non penso che questo abbraccerà tutto l'ecosistema delle applicazioni perché magari potremmo trovare un Laravel as a service da qualche parte o stato sul cloud quindi sarà sviluppato ma magari lo utilizziamo come dire lo utilizziamo direttamente in cloud e secondo me ci sarà come diciamo un'alternativa a un'alternativa diciamo ci sarà sempre la molteplicità di servizi da utilizzare.Credo rimarranno i grandi, cioè rimarrà l'Arabelli, rimarrà Symfony di sicuro perché saranno gli ultimi, ma secondo me avranno ancora del futuro.Non vorrei scoraggiare degli sviluppatori che arrivano adesso e dicono "aspetta no non lo uso perché magari ci si sposta sul caudo".Non lo sappiamo, diciamolo, non lo sappiamo.È una visione ed è sicuramente una visione coerente con quello che sta succedendo.Secondo me abbiamo ancora del tempo.Sì, l'unica cosa che consiglio a chi sta approcciando all'Aravel oggi è proprio in quest'ottica e guardate cosa c'è sotto il cofano perché quei concetti che scoprirete sotto il cofano sull'Aravel, su Symfony, quei problemi che troverete sotto i cofano li troverete poi nelle infrastrutture cloud centriche quando andremo a sviluppare delle applicazioni cloud native.Leonardo la chiacchierata è stata iper piacevole e come sempre Sono stato benissimo chiacchierando con te quindi grazie per essere venuto a trovarci naturalmente tu sai benissimo che adesso ci abbiamo un momento rapido del dei gingilli del giorno No, dove siamo? Questa la tagliamo, sì.Abbiamo il nostro momento adesso del Paese dei Balocchi.E conduco nel Paese dei Balocchi.Ah, il Paese dei Balocchi.Io sono arrivato quasi impreparato, però mi è venuta in mente una cosa che avevi detto all'inizio della puntata, dove parlavi del fatto che certe cose che studi a università poi non le usi mai, perché poi hai dei servizi che già te lo fanno per te.Io sto facendo Advent of Code 2020.Per chi non lo sapesse è un calendario dell'avvento dove ogni giorno ci sono dei problemi.Racconta tutto con uno storytelling particolare.Ci sono dei problemi da risolvere con dei linguaggi di programmazione.Ti dà un input e te devi dargli la risposta.E lì ti rendi conto di come certe cose che te le hai per scontato poi non te le ricordi, non le sai fare utilizzi degli approcci non ottimizzati anche se li hai studiati all'università, cioè li bisogna essere abbastanza skillati sulle strutture dati per risolvere alcuni dei problemi che ti danno.Io sono quasi impari, me ne manca uno che ho una fatica in realtà, basterebbe uno di quei alberi che abbiamo studiato all'università, però non mi ricordo quale, per risolverlo velocemente.Vi suggerisco di farlo perché è un'ottima palestra per il cervello, non finisce al giorno di Natale, continua, cioè uno può anche fare le edizioni passate, ed è un gingillo interessante per balloccarsi un'oretta prima di iniziare a lavorare e mettere il cervello.Quindi Advent of Code 2020.Fantastico, io ci ho buttato un occhio ma quest'anno mi sono tirato indietro, sarebbe mettere troppa carne al fuoco e non ce la faccio, però è bellissimo e soprattutto è un ottimo strumento per far riandare coi piedi per terra, riportare coi piedi per terra alcuni senior che in realtà sono consapevoli di essere senior ma spesso dimenticano delle basi che poi ti rendi conto possono essere importanti.Se non nell'utilizzo di tutti i giorni anche nel rinfrescare quella formamenti se quella rapidità di elaborazione di pensiero che spesso anche per colpa dei framework e del fatto che facciamo tanto crude ci dimentichiamo perché quando dobbiamo andare a fare il calcolo dei percorsi minimi per esempio ci cerchiamo una libreria e su questo su quest'ottica allora aggiungo il mio balocco che forse l'ho già portato non me lo ricordo il libro è un libro intanto si chiama "Groking algorithms" di Manning se non ricordo male dove ci sono una serie di algoritmi illustrati quindi è fantastico.Ne porto anche un altro visto che stavamo parlando di Laravel ed è Bref.Bref è una libreria un ecosistema chiamatelo come vi pare sviluppato dal mio vicino di casa Metio Napoli in realtà abita davvero qua a 500 metri da casa mia che è fighissimo però perché permette di portare l'Aravel sulle lambda di AWS questo vuol dire che adesso la sto buttando con la zappa potete deployare in produzione su un'infrastruttura scalabile super figa la vostra applicazione monolitica l'Aravel senza pagare una lira perché comunque prima di raggiungere le soglie di utilizzo di AWS Lambda per il pagamento ne avete per un po e soprattutto ne si inizia a esplorare anche il mondo serverless giusto per proiettarsi avanti per i prossimi dieci anni.Detto questo io ti ringrazio Leonardo mi ha fatto super piacere chiacchierare con te naturalmente bisseremo questo questo appuntamento con qualche altro argomento no? Volentieri, volentieri mi diverto un sacco a stare da questa parte del microfono.Ormai sarai ospite fisso del nostro podcast.Detto questo io non faccio altro che ricordare i nostri contatti molto velocemente quindi info@gitbar.it o @brainrepo su Twitter.Il nostro gruppo Telegram se non vi siete iscritti mi raccomando fatelo perché trovate un sacco di conversazioni interessanti e tantissime persone carine pronte per scambiare insomma conoscenze fondamentalmente Gitbar è il bar degli sviluppatori quindi nasce con quell'obiettivo detto questo sempre nel gruppo telegram metteremo la data della nostra live di festeggiamento del primo compleanno quindi preparate già la bottiglia di vino e la torta toffieremo le candeline tutti insieme detto questo se l'episodio vi è piaciuto mi raccomando aggiungetelo al vostro client di podcast e se vi è piaciuto davvero tanto lasciate una recensione direttamente sull'itunes store o sull'applicazione podcast questo ci permetterà di raggiungere più persone e quindi aumentare e ingrandire la famiglia di Gitbar.Detto questo Leonardo io ti ringrazio nuovamente e niente ci diamo appuntamento alla prossima settimana.Grazie a te, ciao a tutti! 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 e di strumenti immancabili nella cassetta degli attrezzi dei fullstack dev.[Musica] [Musica]
