Bene e benvenuti su Gitbar.Nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori.Ormai le vacanze natalizie sono giunte al termine anche se io continuo a registrare dalla cantina rustica dei miei genitori qua in Sardegna.Come sapete ho abbandonato la Gallia per passare un po' di tempo con la famiglia ma Gitbar è la mia seconda famiglia quindi non posso mettere da parte la registrazione dei nostri episodi.Registrazione che vede anche oggi un super ospite e anche un amico di Gitbar perché è già venuto nei nostri microfoni.Prima che ci fossimo col video ma oggi abbiamo la fortuna, grazie alla tecnologia perché siamo collegati con l'altra parte dell'oceano, immagino che da lui sia mattina, da noi è ormai quasi ora di cena.Però detto questo, insomma, vi ricordo rapidamente i nostri contati, info@gitver.it, @brainrepo su Twitter, il nostro gruppo Telegram, mi raccomando iscrivetevi, molti di voi non l'hanno ancora fatto ed è il momento giusto per farlo e poi abbiamo il nostro nuovo, nuovissimo canale YouTube, canale YouTube che dovete andare a sbirciare perché in realtà avete i nostri bei faccioni mentre, mentre parliamo.Ok, insomma, il mio non tanto ma almeno quello degli ospiti aggiungono un tocco un pochino più, più completo ecco alla comunicazione.Detto questo io direi che possiamo iniziare.E' già venuto da noi a parlarci di Visual Studio Code, ha deciso di stravolgere nuovamente la sua carriera quindi una nuova sfida, vi rimando all'episodio che abbiamo registrato che racconta un po' come è arrivato fino a questo punto, ma detto questo abbiamo con noi Alessandro Segala, senior software engineer a Microsoft, autore per PACT, ma anche uno dei maintainer di Dappr.Prima di iniziare volevo ricordare che Alessandro ha scritto due bellissimi libri, Svelte 3 up and running ed Essential cryptography for JavaScript developers, se non l'avete ancora letto.Io sono innamorato di quel libro, quindi se non l'avete ancora letto, mi raccomando, recuperatelo.C'è su Amazon, vi metto il link nelle note dell'episodio, buttateci un occhio perché è veramente ben fatto.E non lo dico perché c'è lui davanti, lo può testimoniare, lo possono testimoniare i miei co-host, che insomma gliene ho parlato più di una volta di questo libro.Quindi diamo il benvenuto ad Alessandro qua su Gitbar.Ciao Ciao Alessandro, come va? Ciao Mauro, grazie mille.Io sto molto bene, grazie per le belle parole anche sul libro, molto apprezzate.Come vanno le vacanze natalizie statunitensi? Bene, bene.In questo momento non sono in casa, sono in California con la famiglia di mia moglie.Infatti c'è un bel sole che non avremo a Seattle.Esatto.Esatto, quindi insomma te la godi, te la godi e io ti ho bloccato a casa perché ho detto basta, è da un po' che osservo Dapr, ho detto no no no aspetta, Alessandro è uno di maintainer, lo voglio su Gitbar perché penso che il progetto sia veramente figo, super interessante, specie in un mondo che mangia di microservizi, che vive di microservizi fondamentalmente e voglio introdurre il topic e farti la prima domanda così.Quando tanti anni fa, quando ancora programmavo in PHP, avevo l'ambizione di fare delle applicazioni super mega iper disaccoppiate, avevo l'hexagonal architecture come obiettivo finale, quindi cercare di tenere la business logic più lontana poi dalle specifiche implementative delle varie porte su cui ci connettevamo che potevano essere il database o l'interfaccia utente stessa.Poi però la mia carriera professionale si è evoluta e sono arrivato a fare i microservizi.E i microservizi più o meno micro, anche quello è tutto da vedere, però più o meno micro proprio per il loro essere micro tendono ad accoppiare perché c'è poca business logic, dovrebbe esserce ne poca, per cui non hai tutta l'ansia di disaccoppiare come invece ce l'avresti monoliti.Partendo da questo presupposto, come si pone Dappr proprio in questo contesto di microservizi che tendono ad essere sempre più accoppiati all'infrastruttura che ci sta sotto? Sì, questa è una bella domanda.Guarda, io ho cominciato ad usare Dappr prima di diventare un maintainer, prima di cambiare il mio ruolo e diventare un software engineer lavorando su Dapr.Ero un utente Dapr, l'ho usato per un paio di app che stavo realizzando.In Dapr al momento non abbiamo un team marketing, ma se ce l'avessimo mi direbbero di non dire questo, però io lo dico lo stesso.E cioè che Dapr, se stai creando un'applicazione o una soluzione che usa microservices, Dapr o usi Dapr o sostanzialmente ti ritrovi nella posizione in cui ti reimplementi Dapr per questo momento dà per a circa 8 building block come li chiamiamo così che permettono di fare diverse cose quando stai creando un'applicazione che usa microservices ma anche come qualcuno li chiama macro services cioè comunque magari più di un servizio però un po più un po più quindi non solamente un task solo per ogni servizio.Per esempio, Service Invocation permette di chiamare app A, poi invocare app B, e d'Happer sa come raggiungerlo, quindi non importa qual è la porta, non importa qual è l'IP, non importa dove l'applicazione è in esecuzione, non bisogna fare hard coding degli indirizzi IP o dei hostname, d'Happer sa come raggiunge l'applicazione.Altri esempi sono PubSub, per cui se l'applicazione ha bisogno di ricevere messaggi da un broker PubSub, Dapper astrae, abstract, tutta questa logica dell'implementazione e l'applicazione può già ricevere messaggi.La ragione per cui mi piace molto Dapper è perché ha questo livello di astrazione che funziona un po' dappertutto.In produzione, la maggior parte degli utenti, ma non tutti, ma la maggior parte degli utenti fa andare le app su Kubernetes.Quindi quando sono in produzione, la piattaforma è Kubernetes.Però quando sei in local development, lavorare su Kubernetes a volte rende le cose molto più complicate.Ma il vantaggio di Dapr è che l'applicazione funziona lo stesso, anche se non c'è Kubernetes, e dal punto di vista dell'esperienza della local development experience è esattamente lo stesso.Lo stesso anche per il database, magari in local development uno vuole usare SQLite e in production usa Postgres o qualche altro database, Dapr estrae tutto questo, per cui l'applicazione semplicemente parla con Dapr e poi in base a dove Dapr è in esecuzione, Dapr si preoccupa di parlare col database.Quindi ci sono tanti livelli di astrazione che rendono lo sviluppo di applicazioni che usano Microservices molto più semplice e poi ci sono altri livelli più higher level di cui tu e io parleremo tra poco e niente spoiler per ora.Sì, parlavamo, hai accennato dei livelli di astrazione, io per un attimo ho immaginato, hai parlato di Pub/Sub, hai parlato di database, visto anche che c'è tutto un livello di astrazione per la connessione con dei secret store o con dei configuration store, hai parlato di invocare altri servizi con questi livelli di astrazione, ma per esempio immaginiamo torniamo allo state management, ha una sua complessità il connettersi con uno state manager che può essere un classico database no SQL.Cosa fa Dapr? Riproduce pedosequamente l'API del layer che sta sotto? Cioè mi immagino che ne so un API a Cosmos DB, l'API di Cosmos DB è abbastanza complessa.Se poi ci devo fare un livello di astrazione che mi astrae anche Redis perché una delle cose che hai accennato è che alla fine questo livello di abstrazione rende l'elemento architetturale sotto intercambiabile.Quindi quanto diventano complessi poi questi moduli, questi adapters? Noi abbiamo adapters per, nel caso dei State Store, abbiamo adapters per, non lo so, due dozzine di State Store al momento, che includono cose come Database SQL, da Postgres, MySQL, SQL Server, SQLite.Abbiamo anche NoSQL, come Redis, MongoDB, Cosmos DB, Azure Cosmos DB.Abbiamo servizi cloud e servizi che sono, diciamo, self-hostable, che ognuno si può gestire per colto proprio.Il modo in cui funziona Dapr, il modo in cui cerchiamo di creare ogni building block, è che l'applicazione semplicemente parla con Dapr.Dapr segue il paradigma della sidecar, per cui la tua applicazione, non importa in che linguaggio e programmazione è scritta, è eseguita come un esecutabile, un binary, e poi Dapr è un altro binary, un altro esecutible eseguibile, che sta accanto alla tua applicazione, c'è un'istanza di Dapr per ogni istanza della tua applicazione.e i due parlano fra di loro usando HTTP o gRPC.Abbiamo SDK per quasi tutti i linguaggi di programmazione principali, quindi comunque la maggior parte delle persone non deve preoccuparsi del protocollo usato.Quando c'è da aprire l'esecuzione, la tua applicazione che ci sta accanto, se l'applicazione vuole salvare qualcosa nello State Store, invece di preoccuparsi di collegarsi a Cosmos DB oppure Azure Table Storage, L'applicazione fa una richiesta ad Dapper che dice "salvami questo state" nel tuo State Store, qualunque sia lo State Store che è configurato.Quindi, se c'è uno State Store chiamato Pippo, l'applicazione dice "salvami questo valore" nello State Store Pippo con la chiave "ciao mondo" e Dapper lo scrive.L'applicazione non sa qual è lo State Store, però sa che il dato è stato scritto nello State Store.Abbiamo questo di varie estrazioni per le principali operazioni di CRUD.Crea, leggi, aggiorna e cancella.Create, read, update, delete.E quindi tutto questo è astratto, l'applicazione semplicemente parla con DAPR usando le SDK oppure invocazioni HTTP e JRPG direttamente.Pensavo una cosa.Adesso questo lo tagliamo se in realtà non ne puoi parlare.io la domanda te la faccio lo stesso.In un contesto, uno strumento come Dapper, così proprio ragionando liberamente, mi viene, si pone secondo me come un tool capace di dare quell'elemento di cloud agnostic, non so come si direbbe, no, cioè diventa uno strumento cloud agnostic perché in realtà tu sotto puoi indistintamente passare da un state manager su Azure piuttosto che su AWS, basta che ci sia l'adapter e questa è una grande conquista.è una grande conquista e secondo me è valore aggiunto anche per i cloud provider penso, perché ogni cloud provider ha i suoi servizi punta di diamante e questo permette a un cloud provider di essere scelto non...cioè non ti forza ad abbracciare tutto il cloud provider ma a a scegliere giusto alcuni servizi con dei relativi problemi legati alla rete.Però ecco, mi piace immaginarlo come davvero uno strumento che ti permette di sviluppare in modo agnostico al di là del cloud provider che utilizzi ed è molto figo.Sì, non solo, posso parlarne di questo, però è proprio uno dei value prop dei valori principali Forse avrei dovuto dirlo prima, ma Dapr è stato creato da Microsoft 3-4 anni fa, forse è stato cominciato circa il 2020, se non sbaglio.Però da due anni fa parte della CNCF, della Cloud Native Compute Foundation, e abbiamo un maintainer che lavora per diverse aziende e che si preoccupa di diversi cloud.Io ovviamente il mio salario è pagato da Microsoft, però comunque come maintainer io ho il ruolo, come maintainer da C&C, ho il ruolo di per sé che Dapper funzioni con ogni cloud.Quindi quello che dici è esattamente vero.Uno dei vantaggi di Dapper appunto è che uno non deve preoccuparsi di dov'è l'applicazione.Per cui c'è tanta gente che fa local development usando per esempio SQLite o Redis per state, però poi quando va in produzione magari se è su Azure usa Azure SQL oppure se è su Amazon usa Amazon RDS oppure Aurora o qualcosa del genere e Dapr permette questa seamless portabilità dell'applicazione indipendentemente da dove va ed è uno dei vantaggi principali di Dapr di sicuro.Poi un'altra cosa che ha catturato la mia attenzione prima di passare poi a un paio di cosine che ci piacerebbe approfondire è il fatto che abbia observability proprio cioè che faccia veramente parte profonda di come è pensato Dapp.Io sto lavorando in sistema di microservizi dove ci sono tante decine di microservizi e avere le tracce, le traces di quello che succede è tipo un game changer per cui come da quel punto di vista Dapp gestisce l'observabilità perché io faccio il mio esempio buona parte di microservizi sono node, devi installare OpenTelemetry, manca il patchare, un po' di cose e poi tutto funziona.Come fa, a volte, come fa Dapr a darti questa, l'observability out of the box? No, ottima domanda.In un sistema distribuito l'observability è, se posso imprecare in inglese, è un penne di ass, è una cosa che è difficile da gestire, soprattutto è una cosa che ci vuole tempo.E poi diventa ancora più complessa quando magari un'applicazione è scritta in Node, un'applicazione invece è scritta in Java e una in .NET.A quel punto devi anche integrare tutti questi diversi servizi, diverse osservabilità.Prendiamo il caso più semplice che è quello della Service Invocation, per cui la tua applicazione è scritta in Node, magari invoca un servizio scritto in Java.L'invocazione in questo caso avviene tramite per cui la tua applicazione invoca la Dapper SideCam, quindi il processo di Dapper che sta accanto alla tua app.Questo processo di Dapper va a cercare l'altro Dapper, sa dov'è, quindi fa l'invocazione, poi Dapper invoca la tua app.Siccome tutta l'invocazione avviene tramite Dapper, Dapper A fino a Dapper B, abbiamo noi implementato tutto il discorso del Traces, dell'Observability, e ti diamo il già risultato finale, Per cui abbiamo Metrix, che tu puoi ottenere da Dapper, tipo Prometheus.Metrix, puoi sapere quante invocazioni sono state fatte, fino a che app come target.E abbiamo anche Traces, tracce, penso si dica in italiano.Per cui se hai colleghi con sistemi come Zipkin, OpenTelemetry, Azure Monitors, qualcosa di hostigrafana, hai la possibilità di vedere queste tracce, di vedere tutte le invocazioni.sai che per questa richiesta che viene dall'utente è stato invocato al servizio A e poi è stato invocato al servizio B e B ha invocato C ed è tutto tracciato e per cui puoi ricostruire il percorso dei dati.Questo è molto utile quando stai facendo debugging di sistemi complessi che hanno tanti microservices, per esempio.Sì, veramente è un game changer e lo ripeto perché a me cambia la vita, capire quale microservizio ha rotto cosa in un flow lungo.E allora siccome le nostre applicazioni non sono solo il crudino della chiesa come direbbe qualcuno, "metto dentro e prendo, metto dentro e prendo", ma talvolta le applicazioni sono un pelino più complesse, è uno degli elementi che torna nelle applicazioni dove la business logic si fa vedere sono i workflow, quindi una serie di passi che insomma fanno una serie di azioni per aggiungere il risultato.Io ho visto in realtà la famiglia di componenti, correggimi se sbaglio perché io ad Apple non lo conosco bene, ci ho perso qualche oretta a buttarci un occhio ma non ho approfondito.Ho visto una famiglia workflow, l'elemento Dapper Workflow, che mi ha catturato, che ha catturato la mia attenzione.Cos'è? Come funziona in realtà? >> Ok.Dapper Workflow è una delle due cose di cui ti ho parlato prima, che volevo parlare, che veramente sono le cose più interessanti a questo punto di Dapper, per me personalmente.Sono queste cose più ad alto livello.Ti ho detto prima che Dapper ha circa, sono perso il conto, sono forse otto, quelli che chiamiamo Building Block, Service Invocation, State Management, Pub/Sub.Queste sono più proprio astrazioni dal punto di vista di abstrarre l'infrastruttura sottostante, abstrarre il Cloud provider se qui sta andando, magari l'infrastruttura self-hosted, e offrono un po' come queste API trasparenti.Questo è estremamente utile, e veramente per me è un grande vantaggio, però possiamo fare di più.Una di queste cose sono queste API di livello più alto che stiamo creando in questo momento.Ce ne sono due, Workflow e poi Actor, magari dopo parliamo anche di Actor.Workflow è una cosa relativamente nuova, abbiamo lanciato in Dapper 1.11, è il beta 1.12 e adesso, tra qualche settimana, dopo che questo podcast va live, da 1.13 ci saranno delle migliorie.Ma workflow permette di gestire dei workflow complessi.L'idea di base è quella che viene chiamata la distributed transaction.Ed è questa idea che in molte applicazioni la business logic richiede il coordinamento di diversi sistemi che sono anche sistemi molto disomogene.Per cui per esempio, non so, hai mai lavorato su un'applicazione che deve gestire un...Scusa, mi sa che ti ho perso per un momento, ci sei? Sì sì sì.Anche io ho perso dei chunk ma non ti preoccupare l'applicazione continua a registrare quindi vai sereno.Ok ok.Scusa, dove partiamo? Il discorso del WordPress, molte applicazioni hanno questa business logic che richiede l'interazione con diversi sistemi che sono complessi e anche disomogenei.Per cui un esempio molto tipico, non so, hai mai lavorato sull' applicazione che deve gestire un checkout di un e-commerce per esempio? Sì sì, ho fatto tante volte sistemi di booking quindi...Per esempio, prendiamo il momento in cui l'utente o il cliente decide "premi il pulsante compra" e tutto è definitivo.Quali step deve fare la tua applicazione? Beh, deve ridurre la disponibilità degli oggetti in magazzino, deve creare l'ordine, quindi salvare l'ordine o mettere il flag acquistato al posto di in progress, deve mandare gli email di conferma, fare un pacco di cose.Esatto, il pagamento con la carta di credito, giusto, magari la carta di credito poi fallisce perché non ci sono abbastanza soldi nel conto, non lo so.Tutte queste cose sono un discorso di WordPro.Sono tutte cose che vanno fatte in sequenza e sono tutte cose che non vanno ripetute, perché se fai pagare il cliente due volte il cliente non è contento.Sono tutte cose che possono fallire e quindi vanno riprovate.Magari magari quando fai a caricare la carta di credito l'operazione fallisce perché la connessione con la banca al momento non funziona quindi va riprovata dopo due minuti.Questo è quello che Dapper Workflow ti permette di fare.Quando arriva la richiesta di cominciare un workflow, Dapper ti permette di definire quali sono i vari step per completare questo workflow, per cui come dice l'ITAC, invia la mail al cliente che l'ordine è arrivato, controlla che il magazzino abbia abbastanza disponibilità, blocca un'unità nel magazzino, poi andiamo a inviare la richiesta al fulfillment per effettivamente dire "spedite questo oggetto", andiamo a parlare con la banca per dire "fai pagare la collezione del pagamento" e tutto questo va fatto in sequenza e se qualcosa fallisce vogliamo essere in grado di riprovare per cui per esempio come dicevo prima la banca magari la connessione è giù al momento bisogna riprovare fra due minuti però se invece è un errore permanente bisogna proprio cancellare l'intera transazione e tornare indietro fare il reverse, quindi dire "cancellare l'ordine del magazzino" rimettere la disponibilità dell'unità che avevano tirato fuori dall'inventario.E tutto questo è un discorso di workflow, questo è uno dei vantaggi cui Dappers può aiutare, ed è per metterli a programmare questo numero molto più semplice.Quindi invece di preoccuparsi di gestire tutti gli step, gestire i retries, gestire i rollback, l'utente programmatore crea un metodo nella propria applicazione che dice quando...questo è il codice per cui prendiamo l'unità del magazzino e dice a Dapper dove si trova questo codice, il nome della funzione, e poi Dapper ci pensa a lui ad orchestrare l'invocazione di tutti questi metodi e potenzialmente anche di fare rollback se necessario.Dapper ci pensa anche lui a fare le retries, se qualcosa fallisce con un errore temporaneo, e dà percipese anche a far sì che tutto questo sia fatto in modo consistente per cui non andiamo a prendere due unità da magazzino o non andiamo a far pagarli due volte.E come dicevo prima, questo funziona con qualunque linguaggio di programmazione.Per cui, ipoteticamente, facciamo che il magazzino richiede un'applicazione scritta in Java e invece il pagamento con la banca richiede un'applicazione scritta in .NET non c'è nessun problema, basta che siano definiti, basta che l'applicazione di cadaver doc si trovano ed è possibile fare tutto in un linguaggio completamente disomogeneo.Pensavo una cosa mentre parlavi, forse in qualche modo sviato o incuriosito da come funzionano altre componenti come pub, sub, come i secret store, per un attimo ho pensato workflow come le logic apps o le step di Azure o le step function di AWS.È qualcosa di simile o è quello con un livello d'astrazione? Perché in realtà non riesco a immaginarmeli diversamente.Un'omano molto interessante perché è quasi come se l'architetto che ha disegnato Dapper Workflow fosse lo stesso architetto che ha disegnato Azure Durable Functions e anche Azure Logic Apps.In effetti è lo stesso architetto.Ecco perché.La differenza è che nel caso di Azure Logic Apps, per esempio, quello è un po' più gestito, nel senso ci sono un certo numero di integrazioni preconfigurate, c'è la possibilità di invocare codice custom, però ci sono un certo numero di integrazioni preconfigurate, per esempio l'integrazione con, non lo so, il servizio che manda l'email.Quindi è una cosa più che lo chiamano low code, dove non c'è proprio codice da scrivere in molti casi.Nel caso di Dapper Workflow, qualcuno qui lo chiama "high code", per cui c'è sempre comunque bisogno di un ingegnere, di un programmatore che scriva il codice per eseguire le operazioni, però l'orchestration, l'orchestrazione, quello che gestisce quale funzione è invocata è gestito da Dapper, quindi quello è gestito dalla piattaforma.e solamente il codice e le funzioni che l'utente scrive sono scritte dall'utente.L'altra differenza è che poi in questo caso questa è parte di Dapr, quindi Dapr è qualcosa che l'utente gestisce, l'utente installa il control plane di Dapr, installa l'infrastruttura per far andare Dapr, e quindi c'è pure SmartSite anche dal punto di vista dell'utente.Ovviamente ci sono piattaforme che offrono Dapr gestito come as a service, io lavoro nel team di Azure Container Apps e Azure Container Apps offre Dapr come servizio gestito, quindi il control plane già gestito per l'utente e si occupa di rendere disponibili le sidecar in modo semplice senza dover preoccuparsi della versione del control plane eccetera.Però comunque Dapr permette anche di avere più controllo se uno volesse.Ecco pensavo proprio a questo cioè abbiamo parlato di applicazioni con più linguaggia, abbiamo citato java, script java e quant'altro mettiamoci anche dentro Go e Rust giusto per come dire la sorta.Anche Cobol.Ok, no questo mi incuriosisce.No pensavo per cui alla fine le nostre applicazioni sono dei veri e propri container che fanno girare il nostro codice quindi alla fine container che comunica come dicevi tu no attraverso grpc e http che poi come come ci accennavi prima può essere rastrato con un sdk alla fine questa cosa ci permette di deployare praticamente tutto fondamentalmente penso a una cosa abbiamo detto workflow immagino che sai io vengo dalle dalle dal mondo delle delle delle delle step step function quindi workflow ha anche un sistema di trigger che attivano un certo blocco di codice immagino no? Nel microservizio mi chiedo come scala? Nel senso io ho una function che è deployata su un container e magari sto immaginando, correggimi se sbaglio, attraverso le SDK rimane in ascolto di un certo evento.Questo mi permette di scalare proprio questo tipo di approccio o funziona in modo diverso.No, hai perfettamente ragione.La scalabilità è offerta dal fatto che l'applicazione che contiene il codice per eseguire uno specifico evento, uno specifico task, può essere replicata orizzontalmente su sistemi completamente distribuiti.Tutto quello che facciamo in Dapr è pensato dal punto di vista del sistema distribuito, per cui se hai bisogno di più risorse per gestire il oppure anche solo un task specifico del workflow, può escalare come replicare una specifica applicazione, un specifico microservice.E questo poi permette di avere più risorse ed Appler sa che ci sono repliche e quindi sa come inviare le richieste a ciascuna applicazione in un modo abbastanza load balanced.Sommare sostanzialmente evenly load balanced, abbastanza distribuito e monoliforme.sì quindi mi immagino che Dapper Workflow sia un layer superiore che appoggia le sue basi su altre due componenti che ne so i Pub/Sub Broker e i Triggers mi sbaglio? Cioè sotto il cofano alla fine? O out of the box una configurazione, che ne so, per Kafka se usi Workflow? Al momento Dapper Workflow usa Dapper Actors come backend, di cui parleremo più avanti.Stiamo lavorando a supportare altri backend per collegarsi direttamente a alcuni stores, tipo il prossimo penso sia SQLite e Postgres, però non ci basiamo su Pub/Sub come Kafka o servizi gestiti al momento per workflow.L'utente può sempre usare Kafka come trigger, per cui per esempio arriva l'ordine, l'ordine può essere inserito come Kafka, dopo Kafka manda un messaggio a un'applicazione di Dapr e Dapr fa partire il workflow.Questo perfettamente possibile, però quando comincia il workflow l'orchestrazione al momento usa un'altra primitiva di Dapper chiamata Actors, che è abbastanza stratta dal punto di vista di quale servizio poi usa internamente.Ok, immagino che essendo comunque Dapper abbastanza giovane sia anche una scelta per cercare di deliverare qualcosa di valore senza perdersi con 70 milioni di adapter per ogni possibile componente immagino no? Sì anche perché Dapper Actors richiede solo uno State Store quindi basta solo avere per esempio un database SQL o anche alcuni database non SQL come RDS, Azure Cosmos DB eccetera.Ok allora siccome l'abbiamo parlato, l'abbiamo accennato, cerchiamo di...immergiamoci su Dapper Actors.Io ti dico un feeling, non so cosa faccia, però la parola "actors" mi riporta in mente un pattern chiamato actor model.C'ho colto? >> TIPO C'hai colto al 100% e capisco benissimo che tu mi dica che è un discorso un po' difficile da capire, sinceramente ci ho messo anch'io un bel po' di tempo a entrare nel mind model, nel modello mentale di che cosa è actor e per cosa posso usarlo.Quello che ti posso posso dire è che quando arrivi a questo momento "aha" è una cosa magica, è una cosa che veramente ti permette di creare applicazioni distribuite che scalano e permette di fare tante cose in un modo molto più semplice di quanto potevi fare prima.Prendiamo un esempio.Ci sono diversi esempi per cui uno potrebbe usare Actors senza entrare nel mondo del workflow.Però parliamo di un esempio in cui hai un sito che è un e-commerce e ogni utente ha un carrello per cui stai andando in giro, vedi che vuoi comprare due bottiglie di vino, le aggiungi al carrello.Come gestiresti questo in un'applicazione a Reactor, si.Beh, immagino di avere, che ne so, potrei salvarle su una sessione su Redis, quindi come la metà carrello e salvo su una sessione e lascio la sessione finché non finalizzo l'applicazione.Però sto ragionando in termini monolitici, non immagino un unico servizio in questo caso? E' appunto quello che penso la maggior parte delle persone farebbero, Redis oppure un database di qualche tipo e poi ci sarà un ID che identifica la sessione che viene passata al cliente.Il problema di questo, ci sono due problemi sostanzialmente, il primo è che comunque hai bisogno di un sistema centralizzato, perché tutto questo viene inviato in un database e poi a questo punto il database che sia Redis o che sia Postgres gestisce lo stato e ogni volta che viene una richiesta bisogna andare a parlare con il database e questo aggiunge un single point of failure e anche incrementa il carico nel database.E poi c'è anche il discorso di gestire cose come se il carrello viene abbandonato per due ore vogliamo cancellare questa sessione, cancellare il carrello e magari anche inviare una mail all'utente per dirgli "Ehi, hai abbandonato questo, però mi hai aggiunto queste due cose al carrello.Vuoi continuare a fare il checkout? Se vuoi ti dirò salvato il carrello, clicca qui e puoi ricominciare a comprare quello che stavi comprando".Ovviamente questa è una cosa che il business apprezzerebbe moltissimo.Tutte queste cose sono esempi in cui uno potrebbe usare Actos e il modo più semplice che per me, però personalmente mi ha aiutato a capire Actors, è l'idea di avere un'unità di storage, un'unità di stati, e in cima a questo state ci mettiamo del compute.E tutto questo è single-threaded.Adesso ho detto un sacco di parole e capisco che magari sentire così crea solo più confusione, quindi analizziamolo un po' alla volta.Un'unità di state.In questo caso l'unità di state sarebbe il carrello, cioè la lista degli articoli che l'utente ha inserito nel carrello.Per cui per ogni utente, per ogni sessione che abbiamo, creiamo un actor in cui l'unità di state è gli elementi che sono stati aggiunti al carrello dell'utente.Se l'utente aggiunge qualcosa al carrello, la mia applicazione fa un'invocazione, invoca l'actor, e gli dice aggiungi questo elemento allo state perché l'utente l'ha aggiunto al carrello, oppure rimuovi questo dal carrello perché l'utente non lo vuole più, oppure l'utente invece di...il cliente invece di una unità ne vuole due, quindi incrementa questa unità.Questo ci porta alla seconda parte di Actors, cioè avere il compute creato in cima allo state.Prima tu mi dicevi, ad esempio, che salveresti il carrello su Redis, no? In questo caso è un discorso molto in cui, se vogliamo aggiungere un elemento al carreno, bisogna che l'applicazione vada a chiedere a Redis lo stato.Guardi qual è lo stato, bene per esempio dentro c'è una bottiglia di Zinfander, e gli dice aggiungimi anche una bottiglia di Prosecco, quindi va a aggiornare lo stato e poi lo salva in Redis col valore aggiornato.Nel caso del actor, l'actor ha lo stato ma in cima ci offre dei metodi.Uno di questi metodi potrebbe essere aggiungi elemento al carrello.Quindi l'applicazione, quello che fa, invoca l'attore, l'actor, invoca il metodo aggiungi al carrello, e gli dice aggiungi la bottiglia di valore, quindi potrebbe essere la bottiglia di prosecco, la aggiungiamo, e l'actor sa qual è il carrello in questo momento, però non ha bisogno di inviare lo stato all'applicazione.Gli offre semplicemente un metodo.L'actor avrà anche altri metodi, per esempio, per ritornare a cosa c'è nel carrello al momento, ci sarà un metodo per rimuovere elementi dal carrello, e in cima a quello ci possiamo aggiungere metodi che fanno completamente tutto.Per cui potrebbe esserci un metodo che dice "cancella tutto dal carrello", potrebbe esserci un metodo che dice "salva questo elemento nella lista per il futuro", wish list e cose del genere.Ha senso finora? Sì, sì, stavo pensando, provando a immaginarlo in un ambito distribuito.Quindi alla fine è l'actor che gestisce in qualche modo anche un eventuale lock per dire "no, aspetta, fammi servire questo servizio, fammi fare questa e poi servo te.Esattamente, e questo mi porta alla terza cosa che ho detto all'inizio, ho detto che era state con sopra compute e eseguito in un modo single-threaded.Questa è esattamente l'ultima parte, cioè ogni invocazione all'actor è single-threaded.Se ci sono tre applicazioni che stanno cercando di fare operazioni sull'actor, sullo stesso actor, allo stesso momento sono gestite in una coda.Per cui se il carrello con i d4 riceve tre richieste in parallelo per aggiungere elementi al carrello, vengono eseguite in una coda, quindi non c'è problema di gestire concurrency, non c'è problema di gestire richieste in parallelo che uno invece dovrebbe gestire se noi usassimo Redis per conto nostro, dovremmo gestire per conto nostro.Per cui ad esempio Redis non ha transazioni, però se fosse un carrello gestito su Postgres, quello che uno normalmente farebbe è "baking transaction", comincia la transazione, legge il valore del carrello attuale, lo invia l'applicazione, aggiorna il valore e poi salva il valore aggiornato e fa il "commit" della transazione.Nel caso dell'actor non c'è bisogno di preoccuparsi di questo "concurrent access", l'actor gestisce questo per conto tuo, per cui puoi fare 100 invocazioni in parallelo e non c'è assolutamente nessun problema di concurrency.Ovviamente la concurrency è gestita a livello del specifico actor, per cui se hai quattro carrelli per quattro utenti diversi, ognuno ha la sua coda.Quindi non è che blocchi l'intera applicazione perché un carrello sta venendo modificato.Hai detto che l'actor ha una sua porzione di compute, no? E pensavo, per cui io posso inserire della logica in questo layer di compute? Non se lo puoi, ma è incoraggiato.E se sì? Ci sono un ventaglio di linguaggio o anche quello è mega libero? L'actor è come tutto in Dapper, è implementato che Dapper gestisce il coordinamento ma il codice dell'actor è gestito della tua applicazione.Per cui nel caso di un carrello, per esempio, ci sarà un microservices oppure una parte di un'altra applicazione che gestisce il carrello e offre i vari metodi.Questa applicazione dice io posso gestire actor di tipo carrello e l'actor di tipo carrello offre questi metodi.Offre il metodo aggiungi elemento, offre il metodo rimuovi elemento, offre il metodo cancella tutto nel carrello.L'applicazione informa ad da Dapr di quali sono questi metodi, e poi l'applicazione che vuole gestire il carrello semplicemente fa la richiesta a Dapr e Dapr fa la richiesta al actor.E tutto questo funziona in un modo completamente distribuito, per cui se cominciano ad avere un milione di carrelli e abbiamo bisogno di scalare l'applicazione che gestisce l'actor carrello, possiamo scalare quello e andiamo ad aggiungere più risorse.Il vantaggio è anche che l'actor può mantenere stati in memoria.Per cui, se, nel discorso dell'actor del carrello, se vogliamo aggiungere un elemento, l'actor può rimanere attivo in memoria per un intervallo di tempo configurabile, per lo che possiamo dire 30 minuti.Ogni volta che arriva la richiesta, per cui se il valore è già in memoria, non abbiamo bisogno di leggere dal database o dal state, per system storage, ma possiamo semplicemente restituirlo dalla memoria e questo anche permette di avere operazioni molto più veloci e che non hanno bisogno di incrementare il load nel database, perché il dato è semplicemente letto dalla memoria.Normalmente le persone comunque scrivono i dati anche su un state in modo persistente, perché se per caso l'applicazione dovesse crashare, comunque vogliamo non perdere i dati, però la scrittura può essere data fatta in modo asincrono e tutte le richieste possono comunque essere gestite dalla memoria.Gli actor possono anche gestire altre funzionalità, non solo l'invocazione, ma hanno anche la funzionalità dei reminders, per cui può essere che quando arriva la richiesta di aggiungere il carrello, noi creiamo un reminder che crea un timer e dice "Fra 30 minuti ricordami che non c'è stata nessuna operazione nel carrello per 30 minuti".Se dopo 30 minuti non c'è nessuna operazione, l'actor riceve un reminder da DARPA e gli dice "non c'è stata nessuna operazione per 30 minuti".A questo punto l'actor può decidere di fare cose come rimuovere tutto lo stato dalla memoria, perché a quel punto non c'è più bisogno di tenerlo in memoria, e poi può decidere di scriverlo sul database e poi può anche decidere di inviare una mail al cliente per dirgli "hai abbandonato il carrello, vuoi continuare, vuoi ritornare e vuoi completare il checkout e far sì che non ci perdiamo la vendita.A livello pratico il reminder gira dentro il sidecar per cui a quel punto fa che ne so io mi configuro il sidecar in modo che ci sia un reminder dopo 30 minuti, non lo so, così è quello chiama un endpoint o invoca in qualche modo il mio servizio sottostante devo implementarlo io sotto forma di business logic utilizzando non so che cosa? Sempre Dapper che fa l'orchestrazione di tutto per cui la tua applicazione arriva la richiesta e dice ok fra 30 minuti ricordami Dapper, ricordami che non c'è stata nessuna operazione.Se poi arriva la richiesta dopo un minuto l'applicazione va ad aggiornare il reminder quindi risetta il timer, quando passo di 30 minuti è Dapper che invoca un metodo nell'applicazione dicendogli questo è il tuo reminder che mi hai chiesto di ricordarti fra 30 minuti di inviarti un messaggio.Quindi comunque il reminder è scritto nell'applicazione, l'applicazione espone un metodo e Dapper invoca questo metodo.Ok e come faccio a far sapere a Dapper che deve chiamare proprio quel metodo? L'applicazione quando crea, nel caso di invocazione di un metro, il caller, cioè l'applicazione per esempio che gestisce il front end del sito, sa che l'attore, l'actor offre un metro, aggiunge il carrello e quindi dice invocami l'attore, l'actor scusami, con i d4 e con il metro aggiunge il carrello.Nel caso del reminder è possibile aggiungere un nome di un metro che poi dà per invia all'applicazione quando esegue reminder.Quindi il reminder può avere il metodo timeout, può avere il valore timeout e l'applicazione riceve reminder bene che il valore timeout e sa come gestirlo.Ok quindi ci sono una serie di metodi o di valori che sono di default per cui poi è l'applicazione io quando sto scrivendo l'applicazione so che se un metodo standard viene invocato con un certo valore a quel punto posso fare...cioè mi chiedo se esiste un'API formalizzata per andare a scrivere la logica del mio microservice che funge da actor oppure se, non lo so, la butto là, posso esporre io, che ne so, una serie di API annotate o con delle caratteristiche, uno YAML per dire "ok, quando succede questo invocami quest'altro".La maggior parte degli utenti che usano Actor usano gli SDK e gli SDK offrono un'esperienza anzi molto high level per creare questi Actor.Per esempio, prendiamo il caso di .NET oppure Java uno deve semplicemente definire una classe con i vari metodi e questi metodi vengono automaticamente esposti come Actor Methods per cui se la tua classe contiene un metodo chiamato "aggiungi elemento al carrello" Dapr automaticamente espone questi come metodi per tutti quelli che vogliono invocare l'actor.Immagino che in un qualche momento nel boot il mio microservice parlerà al sidecar e gli dirà "guarda i miei metodi sono questi, agisci così, chiama cosa".Immagini perfettamente, funziona proprio così, ma tutto questo è gestito dalla SDK.Ovviamente è possibile usare Actors anche senza SDK, diventa un po' più magico se uno decide di usare la SDK.È anche più semplice immagino.Ti volevo fare una domanda.Scusa vai vai vai pure.No, solo per commentare sul discorso di Actor.Ho fatto un esempio abbastanza banale però le possibilità sono un po' infinite per cui ho conosciuto utenti che usavano Actor per fare cose più disparate tra cui per esempio rate limiting.Vogliono avere un sistema di rate limiting distribuito, in cui un'applicazione può ricevere un certo numero di richieste per minuto.Usare Actors è un modo semplicissimo, perché lo stato del rate limiting è mantenuto in memoria, quindi non c'è bisogno di nessun database persistent e è una funzione molto veloce.Puoi usare Actors anche per gestire le sessioni degli utenti, per cui non solamente hai il dato salvato dalla sessione dell'utente, cioè per esempio il nome dell'utente o qualcosa, ma puoi anche esporre metodi in cima a quella sessione dell'utente, cose come access control.Invece di doverlo implementare in ogni applicazione, cercare l'ID dell'utente, vedere se questo utente può eseguire l'operazione A, questo viene implementato una volta solo nell'Actor, funziona poi con tutti i linguaggi e le programmazioni che usano questo, e l'applicazione che vuoi richiamare semplicemente chiede ho la sessione con i D4, mi dici qual è il nome di quest'utente, ci sarà un metodo per far questo, ho la sessione con i D4, mi puoi dire se quest'utente può fare un'operazione X e l'actor risponde su questo.Quindi c'è veramente la possibilità di implementare metodi sopra di questo che è molto potente.Dapr, in cima, offre tutte le altre cose di cui vi ho parlato prima, tra cui ho Observability, per cui le tracce, i logs, ma offre anche automaticamente retries, per cui se la richiesta fallisce perché la rete temporaneamente fallisce, Dapr può riprovare in modo automatico.Ed è per questo che penso che veramente mi fa piacere lavorare con Dapr per queste cose di livello più alto, che permettono di creare applicazioni che altrimenti sarebbero molto difficili da creare o molto più complesse.è bellissimo vedere un sistema di building blocks che tu assembli ci metti la tua logica di business e grosso modo tutto funziona magicamente mi chiedo a questo punto dal tuo punto di vista qual è il livello minimo che rende l'adozione di Dapper utile e non over head? immagina il side project perché noi lo sappiamo questi tool alla fine ci avviciniamo o almeno buona parte di noi si avvicinano a questi tool con i POC o i side project.Però anche la specie quando si entra in contatto con Kubernetes, insomma spesso sono anche un po' overkill questo tipo di strumenti quando magari un monolite in .NET o in Ruby on Rails più o meno ti offre una serie di tool che ti permettono di realizzarlo.Quindi secondo te qual è l'esempio di minima applicazione che può vincere il paragone tra benefici e costi? Il costo di Dapp era abbastanza ridotto, sinceramente.Basta avere un altro container.Non serve neanche essere su Kubernetes.Ho detto che la maggior parte degli utenti in produzione usano Kubernetes, ma ne sappiamo tanti che non lo usano.Non è neanche necessario usare container, sinceramente.Se sei capace, nel senso, se la tua piattaforma permette di far partire due processi, uno accanto all'altro, quello allora ti permette di eseguire Dapr.Dal punto di vista su cosa userei Dapr, quando ho cominciato a usarlo io era per un side project.Ci sono diverse situazioni dove penso usare Dapr sia utile, giusto per elencarne due.Una è quando vuoi avere la possibilità di astrarre i servizi che poi vai ad usare.Le ne ho parlato prima.In local development, per esempio, io voglio salvare i dati su SQLite, solamente perché è semplice, mentre in produzione voglio salvarli su Amazon S3.In questo modo posso avere l'esperienza di local development che non richiede nessun cloud service, non richiede nessuna connection string e cose così, mentre in produzione posso usare il mio S3.E non c'è niente da cambiare se non un YAML che configura a cosa Dapr deve connegarsi.Per cui l'unica differenza è questo file.Un altro posto in cui Dapr può essere molto utile è quando ci sono due microservices, oppure macroservices anche, che devono invocare l'uno all'altro.In questo momento tutti parlano di AI.E la maggior parte delle cose che hanno a che fare con AI, per qualche ragione, sono scritte in Python.Python non è il mio linguaggio di programmazione preferito, quindi non scriverai mai un'intera applicazione in Python, un'intera soluzione in Python.Però, se avessi bisogno di offrire AI alla mia applicazione, potrei creare un servizio che è gestito solamente per il discorso dell'AI, quello lì è quello che gestisce, che esegue i modelli o quello che c'è da fare, e poi tutto il resto dell'applicazione la puoi scrivere in qualunque altro linguaggio, ma a quel punto hai il problema di fare l'invocazione da A a B.Questo diventa un non problema se usi Dapr, perché usando Dapr la tua applicazione può semplicemente dire "invocami nel servizio AI" il metodo X e Dapr ci prende cura di fare tutto il resto.E a quel punto non importa se la tua applicazione è nella tua laptop che stai facendo local development, non importa se stai in esecuzione su una virtual machine, non importa se sei in Kubernetes o anche se sei in un servizio PaaS come Azure Container Apps dove il Dapr è offerto come servizio.Pensiamo anche un'altra cosa abbiamo detto sidecar container se io vengo da un'esperienza con Istio che fa una cosa diversa ma il comportamento è quello no? Cioè un sidecar container che poi gestisce il traffico diretto e mi chiedo così come mi chiesi per Istio c'è un overhead e se sì quando dal tuo punto di vista inizia a essere significativo? - Del punto di vista service invocation c'è un minimo overhead, dipende da vari fattori però fai conto che su una service invocation c'è un'aggiunta latenza di un millisecondo, uno o due millisecondi, dipende un po' dallo scenario.Ci sono anche potenzialmente degli di overhead, altri casi di overhead.Una delle cose su cui ho lavorato negli ultimi mesi, che è stato un progetto molto più grande di quello che pensavo fosse inizialmente, scusami, è la possibilità di ottimizzare l'invocazione quando viene usata HTTP per fare l'invocazione.In Dapr 1.12 è stata la prima versione di Dapr che usa streaming, per cui appena un byte arriva su Dapr viene immediatamente inviato all'altro target, l'altra sidecar, e poi viene immediatamente inviato l'applicazione.E questo riduce significativamente il time to first byte, ma anche la possibilità per applicazione target di cominciare a processare il messaggio immediatamente.Quindi c'è un overhead, purtroppo è inevitabile, perché comunque abbiamo aggiunto due hops, però l'idea è che il beneficio dovrebbe essere sostanzialmente maggiore di questo overhead nella maggior parte dei casi.Chiaro, chiarissimo.Sembra una figata, mi hai incuriosito talmente tanto che lo voglio provare nel prossimo side project, quindi sentiti responsabile del macello che farò.no è veramente è veramente figo e mi chiedo se insomma avere l'idea sai di delle famiglie di componenti in questo modo mi fa pensare che sia una roba estensibile quasi infinito, dipende da quanto la comunità la abbraccia.A questo punto ti chiedo che cos'è Dapper sotto il cofano? Cioè che tipo di tecnologia utilizza Dapr per fare quello che fa? Dapr è scritto in Go, perché Go è un po' il linguaggio che viene usato per quasi tutto che è scritto su Kubernetes, quasi tutto quello che è Control+Play su Kubernetes.È un'applicazione scritta in Go e ci sono diversi repository e ci sono anche parecchie linee di codice in mezzo e e abbiamo componenti che permettono di interfacciarsi con, a questo punto, credo, 110 o 120 diversi componenti, tra cui servizi cloud, servizi di ogni cloud e servizi, chiamassero post, per esempio Postgres, che può essere dappertutto.Però il linguaggio in cui è scritto dapper, diciamo, non è importante, a meno che uno non voglia contribuire a dapper per sé.ma l'app che uno scrive, che usa Dapr, può essere scritto in tutto, da Java, .NET, Python, Go, PHP, JavaScript.Abbiamo SDK per i linguaggi di programmazione principali.Se non c'è un SDK, comunque Dapr espone endpoint che sono HTTP o gRPC, per cui uno può direttamente fare l'invocazione dell'endpoint senza usare un SDK.infatti abbiamo una demo di usare dupper con kobold per nessuna ragione specifica tranne per il fatto che sembrava una cosa interessante da fare Perché fanno fondamentalmente no? Allora prossimo con Fortran e ci siamo.No vabbè è chiadissimo super super figata Alessandro.Sulle note dell'episodio lasciamo una serie di riferimenti per chi vuole approfondire, però il tempo vola e io non vorrei rubarti tutta la mattina, quindi io direi che possiamo passare, se sei d'accordo, al Paese dei Balocchi.Quindi il momento nel quale sia i nostri guest che i nostri host condividono con noi un libro, un film, qualunque cosa abbia catturato la loro attenzione e abbiano piacere di condividere con la community di GitLab.Quindi mi chiedo, hai qualcosa da scenare alla nostra community? >> Sì, qualcosa che non ha assolutamente niente a che fare con Dapper, ma è una serie TV che ho guardato molto di recente e mi è piaciuta tantissimo, We Crushed.Almeno qui negli Stati Uniti è su Apple TV+, non so in Italia dove uno può guardarla, però è fatto veramente bene la storia ed è una drammatizzazione della storia di WeWork.L'ho trovata molto interessante perché l'ho trovata come un esempio di una storia, una cautionary tale, una storia che può, la storia come di cauzione, come di educativo, come un po' come una favola, una favola di esopo, di cosa può andare storto in questo mondo della tecnologia, in questo modo in cui ci si muove molto velocemente.E poi anche, devo dire, la performance incredibile degli attori, quindi molto divertente e anche molto educativo in un certo senso.Consiglio We Crushed.LM: Noi stiamo registrando prima di Capodanno, quindi siamo ancora nel 2023.Voi siete già ormai nel 2024, ma io ho ancora, diciamo, il tempo che vada a Capodanno a Epifania per cercarmela e recuperarmela.Quindi grazie anche a nome mio, del tutto a personale, perché mi hai dato un modo per rilassarmi ancora di più durante queste vacanze estive.Anch'io, on balocco, qualche giorno fa i ragazzi di Tailwind CSS hanno annunciato una nuova component lib open source sulle orme di headless UI e fondamentalmente quello che stanno andando a fare è creare appunto una serie di componenti basati su Tailwind pronti e riutilizzabili, una sorta di UI kit pronta all'uso.Io tempo fa acquistai delle licenze di Tailwind UI perché le reputavo molto fighe però era palloso il dover convertire quei chunk di codice in componenti React.Avere una UI kit già out of the box, bella pronta da utilizzare facendo solo un npm install è molto comodo per persone come me che in realtà hanno 70.000 idee al minuto e devono realizzare dei POC limitando l'effort.POC che in realtà possiamo come ci diceva Alessandro anche iniziare a creare utilizzando Dapp per cui sappi che i servizi cloud della mia nuova idea proverò a farli proprio utilizzando Dapp.Io vi ringrazio infinitamente per esserci venuto a trovare è stata, come sempre, una chiacchierata fighissima.Ti faccio una domanda però prima di lasciarci.Nel futuro come vedi l'evoluzione di Dapr? Nel futuro penso che Dapr continuerà ad espandersi offrendo cose più high level.A questo punto abbiamo una solida base con l'abstraction layers per, come parlavamo prima, State Store, Pub/Sub, diversi tipi di binding, service invocation, Actors, che lo considero una metafora high level e low level, penso che vedrai molte più cose costruite in cima, Adapter che offrono le possibilità di questo mondo di high code, in cui c'è sempre codice da scrivere, perché non sarà mai qualcosa di completamente gestito, però in cui ci sarà meno codice da scrivere e il codice più importante sarà un discorso di implementare la business logic e non implementare il plumbing, non implementare il gestire l'infrastruttura, ma solamente scrivere l'applicazione in cima.E questo magari possiamo anche dirci è anche un modo per rendere il nostro lavoro più AI-proof, giusto? perché quando ci preoccupiamo dell'infrastruttura magari siamo più a rischio.Non lo so, non l'hai sentito da me.No, no, io non ho sentito niente.No, vabbè, questo tipo di approccio si sposa secondo me anche con tutto il nuovo trend del platform engineering, quindi il fatto di avere un tool che si preoccupa di una serie di cose ci permettono di concentrarci sulla business logic o su quale cose che sono le foundational che noi prendiamo e muoviamo e quindi magari ci scriviamo.Non so se si può scrivere un adapter particolare per Dapr come plugin, me l'immagino, no? Certamente.La creazione dell'adapter.Certamente, se c'è un un altro servizio che ho pure prodotto che non è al momento disponibile su Dapr, accettiamo contribuzioni dagli utenti.In questo caso deve essere implementato in Go, perché non è molto semplice in Go integrare nello stesso binario codice scritto in un altro linguaggio, però poi accettiamo pull request, i repository sono github.com/dapr e lì abbiamo due repository principali, dapr/dapr è quello che abbiamo run time, quindi è più il discorso dell'orchestrazione, e poi abbiamo dapr/components-contrib e lì abbiamo il codice che implementa supporto per i vari componenti, quindi se ci manca un nuovo database o un nuovo Pub/Sub broker e qualcuno volesse contribuire è tutto open source e accettiamo contribuzioni con molta gioia.È detto questo, io ringrazio nuovamente Alessandro, nelle note dell'episodio trovate tutti i suoi contatti, anche i link ai libri che ha scritto e appunto ringraziandolo do appuntamento alla prossima settimana.Grazie mille, un piacere parlare con te a volte.Grazie, il piacere è tutto mio.Ciao ciao! Grazie.
